Como viver e se desenvolver em projetos com história. O que dá ao desenvolvedor a experiência de trabalhar com uma grande base de código e por que não há necessidade de se esforçar para reescrever tudo do zero, mesmo se você realmente quiser.
Conteúdo
- Para quem é este texto
- O que você pode aprender com um projeto de história
- Que perguntas fazer em uma entrevista
- Dicas para quem acabou de começar a trabalhar com um projeto legado
- Resumidamente
Chamo-me Pavel Novikov e estou envolvido no desenvolvimento de aplicações móveis "MyOffice Documents" e "MyOffice Mail". Este é um aplicativo para colaboração com documentos e um cliente de email, que começou a ser criado em 2013, para que possam ser chamados de projetos com uma grande base de código, onde existe um local incluindo legado.
A experiência descrita aqui não se aplica apenas ao trabalho em aplicativos móveis e escala para o desenvolvimento de aplicativos em geral.
Isenção de responsabilidade para os mais pequenos
Neste artigo, coletei reflexões sobre meu trabalho com base na experiência que tenho até hoje. Todos os artigos desse tipo são sempre altamente subjetivos. Tenho certeza de que existem pessoas com experiências que contradizem minhas observações. Eu ficaria feliz em discutir essas discrepâncias nos comentários.
Para quem é este texto
O texto é direcionado tanto para quem se considera no nível Júnior quanto para quem se enquadra na categoria Médio / Sênior.
Há muito o que aprender trabalhando com projetos de longa duração em qualquer nível de desenvolvimento. Para estar na mesma sintonia na compreensão dos níveis, leia as postagens do Vastrika: Login vite e K-Team . Gosto de sua categorização das camadas de desenvolvedor e irei mantê-la no futuro.
No próximo bloco, analisaremos brevemente qual é o uso de cada um dos níveis em projetos longos.
Júnior
A tarefa dos desenvolvedores juniores é maximizar o desenvolvimento de habilidades técnicas. Tudo é usado: linguagens, frameworks, bibliotecas, abordagens de desenvolvimento, etc. Em qualquer projeto com uma equipe forte, você pode aprender a resolver diversos problemas.
Mas em projetos maduros, em primeiro lugar, você terá a oportunidade de mergulhar mais fundo em qualquer área e, em segundo lugar, poderá estudar exemplos de decisões bem e malsucedidas. Aprender com os erros de outras pessoas é caro. Especialmente se houver colegas mais experientes por perto que possam explicar em detalhes o significado desses erros e como evitá-los.
Meio
A tarefa do Desenvolvedor Médio é aumentar sua autonomia. Você deve se tornar um membro da equipe em quem possa confiar quase todas as tarefas do projeto. Isso significa que quanto mais tarefas variadas um projeto possui, mais áreas de crescimento potencial você tem.
Senior
O trabalho do Desenvolvedor Sênior é entender completamente que você não é pago pelo código, mas para resolver problemas. Às vezes (ainda mais frequentemente até agora) através da escrita de código, às vezes através do gerenciamento de outros desenvolvedores, às vezes através da comunicação com não desenvolvedores. Projetos maduros são apenas um depósito de tarefas que podem e devem ser resolvidas.
A seguir, irei entrar em mais detalhes sobre algumas das coisas que você pode aprender com os projetos existentes.
E aqui Legado?
Primeiro você precisa entender a terminologia. O conceito de "legado" adquiriu uma conotação negativa há muito tempo, mas para que serve exatamente o código legado?
Michael Feathers, fundador da R7K Research & Conveyance, argumenta que código legado é código não coberto por testes. A vantagem dessa abordagem é que, à primeira vista, ela afirma ser objetiva. Mas, na realidade, pode haver dois cenários:
- Existem testes, mas são mal escritos: confusos, frágeis, não obviamente estruturados.
- Sem testes, mas o código é muito bem desenhado. Isso torna possível alterá-lo com relativa segurança e, nesse caso, permitirá que você escreva testes para ele rapidamente no futuro.
Outra visão sobre o que é legado do desenvolvedor Dro Helper (Dror Helper): Não mais projetado - continuamente corrigido e hackeado ...
O desenvolvedor da Web Nicolas Carlo acredita que código legado é um código desconfortável de se trabalhar.
De tudo isso, podemos concluir que legado é antes uma característica subjetiva do código. O código em si pode ou não funcionar, mas se tornará legado quando um desenvolvedor aparecer e não puder modificá-lo efetivamente.
Outra característica relativamente objetiva para avaliar o Legacy é a resposta à pergunta "existem dependências não suportadas no projeto." O código só pode ser construído por algumas versões específicas do compilador obsoleto. Ou os próprios autores corrigiram alguma biblioteca externa, e agora ela se tornou parte do projeto principal. Nesse caso, de fato, o projeto torna-se específico e esforços adicionais são necessários para apoiá-lo.
Em geral, se o projeto tiver mais de seis meses, é provável que haja legado nele.
O que você pode aprender com um projeto de história?
Então, você tomou uma decisão e conseguiu um emprego em uma empresa onde o código já havia sido escrito antes de você e muitas outras coisas estavam acontecendo. Acrescentarei que você não precisa ir para um novo lugar para atualizar seus perfis. O legado é mais provável em todo projeto, você só precisa saber como avaliá-lo. E o que estou falando pode certamente ser aplicado às coisas nas quais você está trabalhando agora.
Em que áreas o bombeamento será igualmente útil para você e para o projeto? Aqui você precisa entender que a situação quando você desenvolve onde o projeto dói é um ambiente ideal para o crescimento mútuo. Porque se você se desenvolver trabalhando em algumas coisas de esquerda, isso pode ser uma vantagem para você pessoalmente, mas ao mesmo tempo será difícil explicar por que a empresa deveria ajudá-lo nisso.
Analise o projeto
A primeira coisa que você pode aprender com um projeto de patrimônio é analisá-lo. Digamos que você chegou a um projeto em que há lacunas na documentação, ou não há nenhuma. Neste caso, você terá apenas o código-fonte do projeto, por isso é fundamental poder analisá-lo e entender rapidamente sua estrutura e essência. Isso é importante porque quanto mais cedo você aprender a navegar, mais cedo começará a beneficiar o projeto.
A coisa mais importante que posso recomendar para aprofundar o tópico de análise de projetos é ler o livro "Trabalho eficaz com código legado", de Michael Feathers. Ela é velha e famosa. Ele descreve um grande número de práticas para trabalhar com código legado.
Outra dica é visitar o site Understand Legacy Code .... Este é um blog dedicado a um tópico - trabalhar com legado. É importante que você possa se inscrever no boletim informativo lá. Tenho certeza de que muitos desenvolvedores Android conhecem as correspondências do Android Weekly e do Kotlin Weekly. O boletim informativo ULC também é muito útil. Não é intrusivo, com artigos de instruções sobre refatoração e codificação.
Refatorar
Projetos legados são um ótimo lugar para praticar suas habilidades de refatoração. Você chega a um projeto que provavelmente tem problemas e precisa não apenas alterá-lo, mas também melhorar, expandir e ver novos recursos. O quão bem e eficientemente você pode refatorar (rapidamente e com poucas regressões) irá determinar o quão útil e bom desenvolvedor você é.
Em um projeto maduro com uma cultura de engenharia saudável, a refatoração deve ser uma parte contínua do desenvolvimento.
Você deve gostar do produto no qual está trabalhando. Perfeito se você mesmo pode usar. Neste caso, você terá motivação interna para trabalhar na melhoria de sua qualidade por muito tempo.
Projetar e construir arquitetura
Este ponto decorre do anterior - você inevitavelmente precisará aprimorar o design e a arquitetura do software. Com a cultura de desenvolvimento certa, você não terá que tomar grandes decisões arquitetônicas em prazos apertados. Você terá tempo para projetar a arquitetura e será sua responsabilidade fazê-lo bem. O que eu sempre recomendo aqui? Leia livros.
Acho que os livros são tão importantes quanto outras fontes de informação. Quanto mais experiência você ganha com os livros, mais e mais rápido você entenderá como resolver problemas comuns. Sempre há soluções típicas para problemas típicos / típicos que podem ser encontrados em livros. Trabalhar com qualquer tipo de legado também envolve resolver problemas típicos.
(Robert C Martin). « », « »
(Martin Fowler). «. »
UML — .
PlantUML (PUML) — , UML-. git, , .
Quando você está trabalhando com um produto que não compreende totalmente, de alguma forma precisará aprender a avaliar o trabalho a ser feito. E você sempre terá algo que não conhece, algumas armadilhas.
A capacidade de quebrar uma tarefa grande e complexa em um conjunto de peças pequenas e interconectadas é uma habilidade muito valiosa. Uma maneira de desenvolvê-lo é trabalhar continuamente retrospectivamente em erros de decomposição e estimativa. No processo de análise, você pode criar uma lista de verificação a partir dos erros encontrados com frequência. No futuro, ele poderá ajudá-lo a evitar esses erros novamente.
Automatizar e ser capaz de aplicar CI / CD
Você precisa entender o que acontece com o seu código desde o momento em que você o escreve até o momento em que ele chega ao dispositivo do usuário. E você terá a capacidade de automatizar e fazer CI / CD para personalizar, manter e melhorar. Em empresas onde não há uma equipe de infraestrutura dedicada, essas operações podem e devem (estou convencido disso) ser decididas pelos membros da equipe de desenvolvimento central. As ferramentas modernas (nuvem CI, Docker) não são incrivelmente complexas, mas simplificam muito a vida de uma equipe. Você será capaz de fazer muito com ela se dominar essas habilidades.
Comunicar
Quanto mais responsabilidade você tiver, mais pessoas terá para se comunicar. O desenvolvimento de software há muito deixou de ser um destino individual: quase todos os grandes projetos são feitos por equipes. Novamente, quanto mais efetivamente você aprender a interagir com as pessoas ao seu redor, mais benefícios poderá trazer.
Você terá que se comunicar com pessoas mais inteligentes e experientes do que você. Em grandes projetos, sempre há “veteranos” com quem você pode aprender muito. Além disso, você encontrará pessoas mais burras do que você. A boa notícia é que provavelmente você está errado sobre sua capacidade mental - é muito útil ser capaz de corrigir esses erros de percepção.
Acredito que o desenvolvimento de habilidades de comunicação pode ser reduzido ao desenvolvimento de um senso de empatia. Quanto melhor você aprender a entender as motivações e os objetivos das pessoas ao seu redor, mais rápido poderá se tornar útil para elas. Por exemplo, ao explicar a uma empresa os benefícios de refatorar e trabalhar com dívidas técnicas, você deve usar termos de negócios, não termos de programador. Idéia aparentemente óbvia, mas tenho visto repetidamente como algumas pessoas inteligentes se comunicam com outras pessoas inteligentes e não conseguem se entender.
Que perguntas fazer em uma entrevista
Aqui, começarei com as perguntas que faria antes de trabalhar em um projeto sobre o qual não conheço muito.
Como funciona o fluxo de trabalho e por que exatamente
Normalmente agora eles trabalham em sistemas Scrum ou Kanban. Mas, ao mesmo tempo, muitas vezes adaptam-se a si próprios: “pegaram o melhor, jogaram fora o desnecessário”. A questão é: o que exatamente eles jogaram fora e o que deixaram? Porque o guia Scrum, com base no qual o processo de desenvolvimento é construído, tem algumas práticas muito interessantes e úteis.
Eles fazem sentido quando aplicados, em primeiro lugar, conscientemente e, em segundo lugar, todos são aplicados. Porque constituem um sistema que se auto-controla e permite melhorar de forma iterativa não só o projeto, mas também os seus próprios processos.
Por exemplo, se a equipe está trabalhando no Scrum, eu perguntaria o que foi discutido na última retrospectiva. Quão ativa é a equipe nesta reunião? As questões levantadas estão sendo tratadas?
Outra questão interessante para mim sobre processos internos: como é feita a revisão de código na equipe? Existem regras internas para a realização de uma revisão que podem ajudar a reduzir o seu tempo? Existe uma base de conhecimento comum na qual os resultados dos holívares são inseridos, de modo a não atendê-los todas as vezes?
Como funciona o planejamento, quem está envolvido e quão ativa é a equipe
Esta é uma pergunta que eu faria para ver o quão forte é a cultura da engenharia dentro da equipe. Existe uma opção quando apenas o líder da equipe está planejando e a equipe está do seu lado.
Outra opção é quando toda a equipe participa do planejamento. E quando uma tarefa chega, é assumida por alguém que tem experiência suficiente no assunto. E então todos discutem e tomam uma decisão. Isso torna a equipe mais auto-organizada e o fluxo de trabalho mais agradável.
Quantas pessoas na equipe têm a imagem completa
Dois extremos são possíveis aqui. O primeiro extremo é quando você chega a uma equipe que está trabalhando em um produto nos últimos 2 a 4 anos. Se ao mesmo tempo a equipe não mudou muito, apenas se expandiu, então isso é muito bom, porque você sempre terá pessoas a quem recorrer para obter ajuda. Eles poderão sugerir algo, explicar o motivo, contar a história do projeto. Saber o contexto e por que tudo funciona assim e não de outra forma é muito importante.
O segundo extremo é quando você chega a um time que não tem nenhum dos que estavam na largada. Por exemplo, o projeto foi congelado, foi descongelado e uma grande base de código permaneceu. Você não pode reescrever do zero. Portanto, é necessário restaurar o desenvolvimento. Ou seja, você obtém um projeto em que precisará desenterrar tudo novamente.
Com base nessas informações, você poderá tomar uma decisão mais informada sobre se deseja ir ou não, e talvez superestimar alguns de seus requisitos para as propostas que precisará responder.
Como é mantida a carteira de dívida técnica
Existem problemas em qualquer projeto e é importante entender como a equipe trabalha com eles. Escrevi muito bem sobre como trabalhar com dívida técnicaalexanderlebedevno artigo “Lannisters Sempre Pagam Suas Dívidas! (e técnico também) " .
Se a equipe conhece os problemas, mas não sabe como lidar com eles de forma sistemática, isso é um mau sinal. Mas você pode ver isso como uma oportunidade de se tornar a pessoa que o ajudará a resolver esses problemas.
Dicas para quem acabou de começar a trabalhar com um projeto legado
Resista à tentação de se apressar em reescrever tudo do zero
Uma situação comum: você começa a trabalhar em um aplicativo existente e vê que tudo está feito "errado". E com esse "não muito" você precisa trabalhar mais. É um desejo bastante natural neste caso - pegar e reescrever tudo de novo. Esta é uma reação normal.
Acho que se baseia na falta de vontade de responder pelos erros dos outros. Afinal, se depois de suas modificações surgirem novos defeitos, você terá que descobrir. É melhor então reescrevê-lo completamente e tudo ficará bem.
Se você perceber que está tendo esses pensamentos, pergunte-se algumas perguntas:
Definitivamente, existem problemas suficientes no código ou você simplesmente não o entendeu ainda?
Tem certeza de que entende exatamente todos os pontos de integração do código reescrito?
Você conhece o projeto bem o suficiente para prever corretamente o próximo tempo de trabalho?
Embora eu esteja convencido de que a intenção de imediatamente reescrever tudo do zero é uma má ideia. As melhorias devem ser iterativas e gerenciáveis.
Uma vez eu testemunhei quando a equipe disse que "É tudo besteira, vamos reescrever", eles reescreveram por seis meses e não reescreveram. Como resultado, surgiu uma situação bastante interessante quando o projeto teve que ser conduzido do zero novamente, para recrutar uma nova equipe, porque a equipe anterior havia caído. Tente extinguir esse desejo completamente natural de refazer tudo do zero.
Prever mudanças no projeto
Você precisa aprender a ser um pouco oráculo. Trabalhando com um projeto há muito tempo, você aprenderá a entender seu componente de produto, aprenderá a entender o negócio, como esse projeto ganha, como vive. Isso fornecerá uma oportunidade de avaliar a perspectiva de longo prazo das decisões que você toma.
Esta é uma habilidade muito útil, porque é uma situação ruim quando o product owner vem até você e pede que você faça algo simples do ponto de vista dele. Por exemplo, adicione um novo critério para classificar a lista. E da sua parte, isso significa que você precisa reescrever todo o componente. Isso não teria acontecido se você tivesse pensado com antecedência que as diferentes maneiras de classificar essa lista são uma função perfeitamente lógica. Embora ela não tenha sido solicitada a fazer em primeiro lugar.
Só não vá a extremos e tente sempre tomar as decisões mais universais. Este é um caminho direto para o alongamento do tempo e problemas com suporte adicional para tais soluções. O objetivo dessa habilidade é precisamente encontrar o equilíbrio.
Fazer pesquisas
Quando você está trabalhando em um projeto longo, o quanto a empresa confia na equipe é importante. Antes de desenvolver qualquer recurso importante, definitivamente conduzimos uma pesquisa completa da área de assunto. Pode soar como a capitania de um capitão, mas conheço casos em que as pessoas imediatamente correram para o redemoinho com suas cabeças e tarefas aparentemente simples se transformaram em longas refatorações que poderiam ter sido evitadas simplesmente fazendo pesquisa antes do desenvolvimento.
Tire um tempo para documentar
Documente o que você negocia, documente processos, documente a arquitetura. Aqui, tento aderir à abordagem de que, se eles não escreveram, então não concordaram. Porque em projetos que levam mais de meio ano, torna-se fundamental aprender a não perder informações.
Quando você toma uma decisão arquitetônica, parece óbvio para você. Por que explicar de alguma forma? Seis meses ou um ano depois, surgem problemas nessa solução arquitetônica. E você pensa: “Por que eu aceitei? Qual era o contexto? " Aprender como escrever essas decisões arquitetônicas é um grande investimento e fará o seu favor no futuro.
Uma das maneiras de manter esses registros são os Registros de Decisão de Arquitetura... Sua ideia principal é que para cada solução arquitetônica não trivial, você precisa criar um arquivo com vários elementos: título, data, contexto, descrição da solução, consequências pretendidas. Este arquivo é armazenado com o código e não muda depois de criado. Seu principal valor é que, quando chegar a hora de mudar essa solução arquitetônica, será muito mais fácil entender a motivação que a levou a isso.
Resumidamente
- Um projeto com um histórico é um bom lugar para um desenvolvedor crescer se ele se interessar não apenas por escrever código, mas também por tarefas que o ajudarão a se desenvolver não apenas como programador.
- Em projetos com background, não é o código que cria o problema, mas as pessoas, ou seja, esse gerenciamento quando exigem de você algo muito rápido e constante, como no desenvolvimento de jogos, por exemplo.
- . , , , .
GDG.