Desde o meu primeiro dia na carreira de desenvolvedor, sempre ouvi falar com desdém a palavra "legado".
Na minha vida, nunca passei por um lugar onde não houvesse o tal "legado". Isso me levou a um questionamento inevitável: será que em nenhum lugar deste planeta existe um software legado bom?
Era realmente inquietante para mim ouvir a palavra "legado" e perceber os arrepios das pessoas ao redor.
A resposta para isso veio com o tempo.
Primeiramente, devemos entender que um software é composto por código e que o código, assim que vai para produção, se torna "legado". Não existem meias-palavras para isso, o código de hoje pode se tornar uma porcaria amanhã.
Devemos entender também que não necessariamente o código que pode se tornar uma porcaria amanhã significa apenas um software com bugs. Existem outras possibilidades, como performance ruim, manutenção difícil, requisitos que mudaram com o tempo ou até mesmo envelhecimento causado pelo uso de tecnologias e bibliotecas descontinuadas.
Existem sim softwares legados de alta qualidade que enfrentam minimamente os problemas que mencionei.
Esses sistemas bem-sucedidos têm um segredo muito simples: a refatoração!
Softwares que atingem sua completude e entram na fase de manutenção devem ser constantemente melhorados. E manter um software não significa apenas realizar monitoramentos e medir a satisfação dos usuários (recomendo fortemente que façam).
De tempos em tempos, um software legado precisa ser analisado pelos programadores, devido a insatisfações, apontamentos feitos pelo monitoramento, requisitos que mudaram ou até mesmo novas funcionalidades que devem ser adicionadas.
E é nesse momento que o segredo para possuir um legado de alta qualidade entra em jogo: a regra do escoteiro.
Sempre deixe o código melhor do que quando você o encontrou.
Não acumule dívidas técnicas, resolva-as na próxima sprint ou no menor tempo possível, ou melhor ainda, não as crie. Acumular muitas dívidas pode inviabilizar a manutenção e resultar na catástrofe de refazer um sistema.
Reflicta sempre sobre o quanto é fácil trabalhar naquele projeto. As complexidades devem ser, em sua maioria, apenas do negócio e não da tecnologia. A tecnologia deve ser a solução, não o problema.
Não exponha a seu time de negócio ou ao Product Owner as refatorações que você precisa fazer. O programador deve sempre ter a autoridade técnica. Portanto, apenas estime aquilo que deve ser estimado e negocie prazos com a área de negócios, incluindo sempre aquilo que deve ser feito, inclusive as refatorações desejadas.
Isso permitirá que você tenha a possibilidade de resolver as dificuldades daquele código problemático de determinada feature.
É claro que, se o programador deixar as dívidas técnicas se acumularem, será preciso em algum momento negociar atividades de refatoração extensas com a equipe de negócios. É por esse motivo que se deve evitar o acúmulo de dívidas no código.
É necessário entender que refatoração não significa refazer o software, mas sim melhorar parcialmente o que já existe sem quebrar o sistema.
Podemos concluir que se o legado é ruim, é porque o programador o construiu assim. Não surgiram milhares de linhas de código mal escritas da noite para o dia no projeto.
Programadores que herdam legados problemáticos devem ter o profissionalismo de expor a situação juntamente com um plano de ação para o time de negócios e gestão, para que juntos definam cronogramas e atividades para resolver os problemas. Pode ser que nesse momento seja necessária a decisão de refazer um sistema, dependendo da quantidade de dívidas e do investimento necessário para resolvê-las.
Podemos perceber que não existe um bom software legado que não tenha uma atenção técnica mínima de tempos em tempos, ou seja, mantê-lo corretamente.
Aqui vai um recado para os programadores presenteados com softwares legados problemáticos: não existe um caminho saudável para resolver os problemas sem uma boa cobertura de testes automatizados, sejam eles de unidade ou integração (tenha ambos, preferencialmente).
Ter certeza de que suas mudanças não quebram o sistema é vital para qualquer software em qualquer momento do seu ciclo de vida, não apenas para legados.
Por fim, não caia na falácia de que um software concluído só precisa de manutenção quando algo dá errado ou que, se está funcionando, não precisa mexer. Mantenha seu software corretamente, com monitoramentos, testes automatizados e não deixe o código envelhecer. Sempre pratique a refatoração quando necessário.
Top comments (0)