Para consultores ou engenheiros de software, eles passam muito tempo trabalhando com código legado, seja aprimorando-o para novos casos de uso de negócios ou refatorando o código original para torná-lo adequado para novos usos. Existem algumas coisas que são projetos maravilhosamente novos, onde você pode escrever um sistema inteiro do zero.
Analisando o ambiente de software
Assim como você avalia os requisitos para uma nova tarefa, esta análise específica precisa examinar todo o sistema. Isso significa a base de código, seus testes, implantação do código e quaisquer serviços downstream que dependam da base de código em que você está trabalhando. Algumas boas perguntas iniciais são:
O que esse código deve fazer? O que isso realmente faz? Quão bem o código atinge seus objetivos?
Quão bem documentada e testada está a base de código atual?
Com que frequência a base de código é atualizada?
Essas perguntas o levarão aos problemas mais urgentes. Por exemplo, se o código for atualizado com frequência porque é um monorepo ou serviço principal, qual é o processo de implantação? É provável que haja melhorias fáceis nesta área para alcançar uma entrega mais rápida e de maior qualidade.
Existem muitas ferramentas que podem ajudar na análise de código e na identificação de cobertura/cheiros de código para ter uma ideia mais sólida da qualidade e complexidade do código com o qual você está lidando. Essas ferramentas devem ser usadas com engenheiros que trabalham na base de código, bem como com as partes interessadas, para entender onde a equipe está sendo retida, qual deve ser a lógica de negócios e onde está o foco de negócios para o serviço específico que você está revisando.
Melhorar a capacidade de manutenção e a legibilidade da sua base de código é ótimo, mas não se afetar negativamente o desempenho do seu sistema. Portanto, fique sempre atento aos indicadores que medem o sistema, como: tempo de resposta, volume de cadastro de usuários, tempo para aquisição de novos usuários, etc.
Desenvolva um plano de ação
Depois de analisar a base de código e obter informações suficientes, é hora de desenvolver um plano de ação. O que você fará com esta base de código? Quais são as principais áreas de melhoria?
Dependendo do escopo e do orçamento do projeto, vários métodos e abordagens podem ser utilizados. Duas abordagens comuns são criar uma camada de fachada na frente do código legado para simplificar a interação com o código legado e expor apenas as principais funcionalidades. A camada de fachada será construída do zero, para que você possa seguir um padrão de design simples para manter as coisas escaláveis e fáceis de manter.
Outra abordagem comum é substituir gradualmente partes do código legado por novos serviços, mantendo o código antigo consistente com o novo até que seja completamente substituído. Novos serviços serão sua oportunidade de arquitetar um bom software e construí-lo do zero, usando padrões de design, se você decidir fazê-lo.
Escolhendo um Padrão de Projeto
Os padrões de projeto são soluções típicas para problemas que surgem frequentemente no projeto de software. Eles são como projetos pré-fabricados que você pode personalizar para resolver problemas recorrentes de design em seu código.
Se for adequado ao seu caso de uso ou se seu objetivo for simplesmente melhorar a base de código herdada atual, escolha um padrão de design de software que atenda aos seus requisitos. Uma boa diretriz para escolher um padrão de projeto é tornar o sistema mais fácil de testar.
Existem muitos padrões de design por aí, portanto, considerar fatores como compensações, linguagem/estrutura de programação usada e nível de abstração ajudará na sua decisão.
Testar, validar e revisar
A última coisa que você precisa é testar, validar e revisar as alterações feitas. Você precisa ter certeza de que o software criado é adequado e funciona da maneira que você imagina. Além dos testes de unidade, adicionar vários testes de integração e regressão em torno de seus serviços e base de código ajudará a garantir que nenhum bug seja introduzido em outras partes do sistema que você não tenha tocado, além de verificar se as coisas ainda estão funcionando suavemente.
Documentar seu código e suas alterações é fundamental para fornecer visibilidade à sua base de código sem exigir que alguém leia cada linha do código para entender seu sistema. Depois de chegar a esse estágio, é uma boa hora voltar e revisar as alterações feitas e se elas precisam ser reiteradas para melhorar o sistema e a base de código.
Conclusão e implicações
Como você provavelmente sabe, não existe uma abordagem "tamanho único" para lidar com código legado. As principais lições que quero oferecer são:
Atenda ao seu caso de uso. Por meio do mapeamento sistemático, encontrar seus pontos problemáticos específicos pode não apenas ajudar outros engenheiros, mas também ajudar os gerentes de projeto a aceitarem os métodos que você propõe.
Certifique-se de ter uma maneira de medir o desempenho do sistema e refatorar as principais métricas de negócios.
Mantenha a manutenção em primeiro plano em sua mente. Você provavelmente descobrirá que algumas partes do sistema não estão documentadas; nesse caso, criar um README ou runbook para esse serviço/componente ajudará outros engenheiros na manutenção ou futuras modificações de código.
Algo que sempre deve ser considerado é estar ciente do aumento de escopo. Tornar um sistema facilmente extensível é ótimo, mas isso introduz tempo e complexidade extras sem planos de realmente usar seu código extensível em um futuro próximo.