Oi Meu nome é Ivan Melnichuk, sou chefe do departamento de desenvolvimento de uma empresa de TI ucraniana. Na publicação, quero compartilhar minhas abordagens profissionais pessoais em relação à solução do problema do código legado no contexto do rápido desenvolvimento do projeto e contar sobre as técnicas que nossa equipe utiliza nos casos "quando os recursos precisam ser entregues" para ontem ".
Lidamos com o projeto
A fim de mostrar o quão preciso, cuidadoso e meticuloso trabalho deve ser com o legado, darei uma analogia com um baralho de cartas.
É assim que o código legado se parece. Se decidirmos remover ou substituir pelo menos uma carta deste edifício, corremos o risco de sobrecarregar a casa inteira e nivelar seus restos no chão.
O legado se comporta aproximadamente da mesma maneira. Portanto, o trabalho de um programador que assumiu a tarefa de modernizar e "dar uma segunda vida" ao projeto deve ser, em certa medida, jóias. A maioria dos programadores tenta evitar e geralmente “pula o assunto” da dívida técnica. Até compilou uma parada de sucessos das citações mais comuns que precisavam ser ouvidas por programadores apanhados em condições legadas:
- Criamos um site "simples", e agora você deseja obter um novo "coque", e precisamos reescrever tudo isso, pois temos um legado ...
- Ninguém sabe como isso funciona ..
- Para adicionar um módulo, você precisa verificar o site inteiro - a única maneira de entendermos o que e onde ele pode sair ...
- Eu não vou lá de jeito nenhum, tudo já está ruim lá ...
Mas a experiência em programação mostra que existe vida após o legado. Não há problemas com a programação. Existem apenas tarefas que precisam ser abordadas. E antes de elaborar um plano de ação "para superar o código de herança", você precisa entender como as coisas estão ruins no projeto como um todo. No curso da prática, ele identificou 6 etapas do problema do projeto:
- Nenhuma documentação técnica. O limite mais baixo de problemas, porque você pode testar e chegar a suposições preliminares sobre como isso deve funcionar.
- Nenhuma documentação comercial. Se toda a documentação (técnica e comercial) estiver faltando, surgirá involuntariamente a sensação de "parece que estamos presos na história". De fato, mesmo uma empresa não se lembra como deve funcionar, o que significa que a equipe, pelo menos, não tem entendimento sobre o resultado esperado.
- Não há ninguém que projetou isso. Se, além da falta de documentação, também não há um desenvolvedor que possa explicar como o projeto deve funcionar, ele já está com um cheiro frito.
- Não sabemos o que o usuário deve obter no final das contas. Uma coisa é quando as perguntas surgem apenas em torno do back-end, mas se ainda não temos absolutamente nenhuma idéia do que deve ser exibido na frente, então isso já está próximo do estado "é mais provável que o paciente esteja morto do que vivo".
- 200 + uso de cada função e eles são chamados getA . Quinto nível de dificuldade: quando você entra no Legacy, vê o uso das funções A e 200 e ninguém sabe por que ele é ...
- Não há programadores que gostariam / poderiam desenvolver. Nenhum comentário.
Compreender os negócios
Os negócios contam dinheiro. As empresas não desejam gastar recursos financeiros adicionais simplesmente refazendo o que já funciona. Uma empresa nunca comprará a idéia: "Farei isso de uma maneira nova porque não gosto". Portanto, sempre ofereça mais.
Muitas vezes, os desenvolvedores levam os negócios a idéias inúteis. Nesta ocasião, existe um “fundo de cotações douradas” separado.
- Estamos contratando uma nova equipe para "serrar" o código de alta qualidade. Ou seja, precisamos de uma equipe de especialistas que faça o projeto em paralelo com a equipe existente. Não é o fato de que o resultado será diferente, mas o negócio já deve conter dois projetos.
- Paramos de adicionar recursos, agora apenas refatorando! Oficialmente, você declara para os negócios: tabu absoluto nos recursos, só é possível "colocar as coisas em ordem" sob o capô. Extra-oficialmente, você disse que não haverá melhorias em larga escala no projeto, apenas as "corrigirá" localmente.
- Eu já tenho tudo o que preciso no WP, só preciso migrar o banco de dados. Este é um "sintoma" de um iniciante. A música favorita de June: é um site tão simples que funciona apenas por uma hora ou duas ...
Para negociar com a empresa sobre a reencarnação de um código desatualizado, que é servido sob o molho de novos recursos lucrativos, é necessário, a partir da posição de abrir novos horizontes de negócios. No entanto, antes das negociações, as seguintes perguntas devem ser respondidas:
- O negócio está pronto para crescer? Você precisa entender: a empresa tem uma solicitação para aumentar o padrão financeiro ou apenas precisa que o serviço funcione com mais competência.
- Estágio de protótipo? Freqüentemente, uma empresa solicita um protótipo simples, com o qual deseja “sondar” o mercado no momento da relevância do produto. E somente se ele começar a ganhar dinheiro, a empresa estará pronta para desenvolver o recurso em um projeto mais avançado e completo.
- Desenvolvimento concluído e agora apenas suporte? É importante entender toda a gama de tarefas.
- Existe fogo suficiente em nossos olhos e ele não se apaga? O projeto deve inspirar, não desmotivar. É muito importante que sua equipe queira se envolver na reencarnação do Legacy, caso contrário, as pessoas se espalharão gradualmente em projetos mais interessantes para eles.
- Existe um arquiteto? Essa é a pergunta mais importante - você tem uma pessoa que pode fazer a arquitetura correta e começar a escrever um bom código? Não faz sentido nem tentar começar se não houver arquiteto. Caso contrário, em uma semana você será quem criou o legado do problema.
Quando você vender ideias para negócios, concentre-se nas mensagens "novo, crie, adicione" ... A empresa responde muito bem às ofertas da série: "Criaremos um novo recurso e o projeto X será mais rápido ..." e "Para aumentar a conversão, adicione um novo ... "
P - Planejamento
Para trabalhar de forma rápida e eficiente com dívidas técnicas, você precisa de um plano.
1.
Definição de tarefas sobre as quais iremos parasitar. Por que parasitar? Muitas vezes acontece: vendemos um recurso e, com ele, nos referimos parcialmente à refatoração.
2.
Definição de requisitos de alto nível. É necessário registrar uma solicitação comercial clara para um "alto padrão", a fim de elaborar a documentação correta.
3.
Definição dos principais módulos do sistema, imposição de módulos. Antes de iniciar a refatoração, você precisa entender os principais módulos do sistema: onde, como, o que e com o que pode interagir e delimitar o código em seções.
4.
Definição de integração. Ao criar um módulo específico, precisamos pensar com antecedência sobre a capacidade de montá-lo em um legado vizinho.
5.
Definição da equipe. Um no campo da refatoração não é um guerreiro. A equipe é um elemento muito importante para um resultado bem-sucedido. Fervor, motivação da equipe e excelente interação entre os participantes do processo deve ter.
6.
Como vamos testar? Se você pretende fazer um projeto de alta qualidade, precisa pensar no futuro e nas opções de teste do produto.
Junto com o exposto, também é importante determinar qual deve ser o resultado final desejado, elaborar um plano de dimensionamento e registrar os gargalos do projeto. Por exemplo, no caso de redimensionamento de código, é importante entender onde os problemas podem surgir sob condições de carga alta (pode ser um banco de dados, consultas pesadas, grade ou outro link intermediário que pode "cair").
É igualmente importante determinar os limites do projeto, onde havia o código antigo e onde haverá um novo nível de "obra-prima". Você também deve considerar abordagens para microsserviços, ou DDD, ou, talvez, você precise de mais “nanomagia”.
Técnicas do Legado Ninja
Após o "trabalho preparatório", chegamos às técnicas que facilitam o processo de economia da dívida técnica. Não existe uma receita universal e uma panacéia para todos os males do Legacy, mas no decorrer do trabalho em projetos de alta carga, fiz uma lista de ingredientes com os quais você pode preparar um código realmente "saboroso".
1.
Não reinvente a roda. Para mim, este é o principal truque da vida para escrever código. Tudo foi inventado antes de você, não recorra à dança com pandeiros e outros experimentos para resolver problemas com o código legado.
2.
O código é padrão. Sem um único padrão, cada desenvolvedor escreverá à sua maneira. O "estilo do autor" contribuirá para o caos e aumentará ainda mais o lixo de código.
3.
Revisão de código. Não é apenas uma presença do código padrão. Também é necessário que a equipe tenha sido responsável por verificá-lo. Caso contrário, tudo voltará ao normal, ou seja, ao nível do código antigo.
4.
Analisadores de código estático, detector de bagagens PHP etc. (em vez de mil livros) . Essas e outras técnicas automáticas serão necessárias para acelerar o processo, em particular com o mesmo código de revisão.
5.
Tentamos microsserviços. Separadamente, também pode haver módulos ou bibliotecas. Por que microsserviços? A vantagem deles é isolar a lógica o máximo possível e limitá-la a uma API específica. A vantagem deste último é que a API é uma entidade mais monolítica em comparação com o "adaptador no código que pode ser corrigido". No entanto, a API tem uma desvantagem na forma de custos de rede adicionais.
6.
Arquitetura de banco de dados, fontes de dados. É o banco de dados que considero o primeiro gargalo de qualquer Legado. Mas todos projetam como ele deseja, e mesmo no SQL, você pode encontrar falhas sem foco. Aqui estão algumas dicas para trabalhar com o novo banco de dados:
- Não estrague nada, sede por tudo. Se você deseja alterar a estrutura de dados incorreta antiga para um novo formato de dados, mais rápido e produtivo, você pode seguir de duas maneiras. O primeiro é colocar uma nova base, removendo completamente a antiga e o que quer que aconteça. O segundo - no caso de um legado difícil, introduza um novo formato em paralelo. Figurativamente falando, plantar um novo perto de uma árvore velha. Por que o segundo caminho é justificado e mais promissor? Como tudo que é novo funcionará de maneira eficiente, e se surgirem problemas durante a implantação ou no estágio de integração, você pode simplesmente reverter o código e não há necessidade de reverter todas as migrações complexas de bancos de dados.
- Um novo banco de dados é criado na estrutura correta. Ao criar um novo recurso, é importante controlar os locais em que escrevemos a nova estrutura. Paralelamente, é necessário criar suporte para a estrutura antiga, pois é impraticável se livrar dela completamente. Ou seja, continuamos a escrever novo material e, ao mesmo tempo, apoiamos o modelo antigo, no qual traduzimos tudo novo e, assim, permitimos que o antigo funcione também - como se fosse do jeito antigo, mas apoiando a nova estrutura.
- Nós controlamos toda a gravação. Não perdemos os detalhes do campo de atenção para garantir o suporte do banco de dados.
7.
Mas SQL? Se, do ponto de vista arquitetônico, você pode operar com entidades - opere. O conceito de algo definido e finito ajudará você a não criar relações duplicadas e desnecessárias.
8.
Decoradores, adaptadores, escolhas ... Esses padrões são um dos principais para integrar o novo código no antigo legado.
9.
Plano B, ou plano de reversão para integração. Muitos cometem o erro de esquecê-lo. É vital na situação "quando algo der errado" ao despejar material novo. Ou seja, assim que começarmos a construir a arquitetura, já nesse estágio devemos entender como a reverteremos no caso de um bug.
10.
Um novo código sem testes (docas) se torna um legado em uma semana. Não importa o quão bonito seja o seu código, sem a documentação em uma semana ele estará no status "legado" - devido à sua incompreensibilidade.
11.
Teste. Se os testes de unidade são muito caros, usamos testes de fumaça, funcionais e de integração. Quão realista é vender testes de unidade para uma empresa com molho "para fazer um trabalho bonito?" Em nossas realidades, isso é mais uma raridade do que um padrão. Se, por algum motivo, não funcionar com "unidades", passamos a testes de fumaça, funcionais ou de integração e também não esquecemos que podemos delegar a tarefa, por exemplo, a um testador manual.
Em vez de um epílogo
O mais importante nesta história é fazer o trabalho e não deixar para trás o legado de seis estágios problemáticos (listados em ordem do mais simples ao mais complexo):
- Nenhuma documentação técnica
- Nenhuma documentação comercial
- Não há ninguém que desenvolveu isso
- Não sabemos o que o usuário deve receber.
- 200 + uso de cada função e eles são chamados getA ()
- Não há ninguém que gostaria / poderia desenvolver isso.