Não é um assunto necessariamente recente, porém restam controvérsias e, sem dúvidas, ainda cabe uma opinião.

Legados não são ruins. Ruins são as gambiarras, a ausência de testes e de boas práticas de desenvolvimento. Colocar a mesma equipe que desastrosamente sustenta um legado para criar uma nova API fresquinha, com o último framework da moda é potencializar as chances de criação de código ruim, frequentemente chamado de legado.

Também incorro no erro de chamar de construção de novos legados quando vejo códigos escritos de qualquer forma. Mas é força do hábito. Muitas vezes pensei que a solução para melhorar um software era reescrevê-lo, não por convicção própria, pois muitas vezes o CTO da empresa ou o arquiteto induziram a equipe a pensar desta forma. Fato é que essa abordagem nunca resolveu o problema inicial. Meses após o início das migrações sempre parece haver um "novo legado".

E o que acontece ao tentar escrever um novo software com os mesmos vícios de programação? Temos dois softwares ruins para manter, com a mesma equipe que já não aguenta manter o legado. Óbvio que é tentador explorar novos frameworks e linguagens. E o ganho de velocidade realmente surpreende nas primeiras Sprints pois, obviamente, ainda não está uma bagunça completa: ela vem com o tempo. A situação ainda é agravada com os microsserviços e com a criação de novas APIs de forma desenfreada e sem qualidade.

O problema é colocado sobre o sistema, mas na verdade deveria ser sobre a sua forma de manutenção. Não há uma atenção especial à qualidade e melhoria contínua, haja vista que o foco é criar os entregáveis e fazer as peças funcionarem a todo custo. Há uma pressão clara de entrega e isso faz parte do negócio, mas os desenvolvedores devem contrapor isso com seus pontos técnicos ao longo das Sprints.

A equipe de desenvolvimento deve continuamente levantar débitos, ajustar desvios e executar pequenas refatorações. Estas não deveriam exigir um Sprint dedicado apenas a débitos técnicos de tempos em tempos, mas sim pequenas tarefas dentro de cada Estória, melhorando continuamente o código e a arquitetura. Olhar com a visão de escoteiro, melhorando pouco a pouco cada classe alterada irá dar uma sustentabilidade muito maior ao sistema, deixando mais fácil adicionar novas features.

E se o framework ficar defasado? Inseguro? Precisar ser escalado? Bem, se o software foi bem cuidado pode ser planejada uma estratégia de migração ou fracionamento. As classes de negócio poderão ser reaproveitadas, se mantida a linguagem, mas as demais provavelmente terão de ser reescritas. Será doloroso, contudo a migração será mais curta e garante foco total em apenas uma aplicação, sem legados.

Originalmente postado em meu blog: https://blog.lptn.com.br/posts/codigo/criando-sistemas-legados-com-o-framework-da-moda/
Photo by Jon Tyson: https://unsplash.com/@jontyson