Mexer em código legado é uma necessidade comum, mas é um trabalho que a maioria dos desenvolvedores não gosta de fazer.
Do ponto de vista do desenvolvedor, código legado é difícil de manter devido à alta complexidade, falta de uma boa arquitetura, nomes esquisitos, e a perda da ideia arquitetural original ao longo do tempo.
Sistemas legados geralmente possuem pouco conhecimento documentado na equipe, pois os desenvolvedores originais que fizeram as "gambiarra" (hacks) justificáveis não estão mais presentes para explicar as intenções.
É comum que o código legado utilize tecnologias mais antigas (versões de frameworks ou linguagens) ou estilos de programação que mudaram significativamente com o tempo, dificultando a compreensão por devs menos experientes.
O maior problema do código legado é a falta de testes ou a presença de testes quebrados, não rodados ou que não testam nada (e.g., sem asserts), o que torna a manutenção difícil.
Do ponto de vista da empresa, o software legado é muito importante e sustenta grande parte do faturamento, sendo a materialização do Retorno do Investimento (ROI) inicial.
Um software legado geralmente já cobriu seu custo de investimento e agora gera apenas retorno, com custos de manutenção menores do que o faturamento gerado.
Por gerar alto faturamento, o legado tem criticidade muito alta, e qualquer quebra gera estresse e transtorno para a empresa.
Na maioria das carreiras longas em tecnologia, o desenvolvedor passará muito mais tempo mantendo software legado do que criando software novo do zero.
Três erros que deixam o Dev surtado no legado
- A pressa de arrumar o código
O Erro: Sentir a urgência e o desespero de alterar o código imediatamente ao notar algo esquisito, mesmo que com boa intenção.
O software não fica ruim da noite para o dia, mas sim através de uma sequência de decisões ruins ao longo de muito tempo; melhorar também é um processo demorado.
Fazer alterações na pressa invariavelmente leva a dois problemas:
- Quebrar o que não devia, mesmo tendo a melhor intenção.
- Deixar o código mais complexo do que já estava, muitas vezes criando patterns ou lógicas que o próprio dev não entenderá em uma semana.
Como evitar (Regra de Ouro):
Tenha paciência com consciência: Não significa ser conivente com os problemas, mas sim não tentar arrumar tudo de uma vez.
Melhorar não é reescrever tudo do zero, o que é caro e gera bugs; melhore as coisas aos poucos (refatorar e melhorar sempre, mas em pequenas doses).
Avalie o risco de alteração: O benefício de mexer deve ser maior do que o risco de quebrar algo crítico, e isso exige conhecimento do contexto do software.
Lembre-se que um é melhor do que zero (1 > 0); pequenas alterações geram valor e são um exercício de paciência.
- Refatorar sem testes
O Erro: Alterar o código sem ter um gabarito de testes para garantir que o comportamento original não foi modificado.
Refatorar é mudar o código sem mudar o comportamento original. Se você muda o comportamento original do código, você não está refatorando, você está alterando.
Misturar alteração (mudança de comportamento) e refatoração (mudança de estrutura) sem testes é a "receita da treta" e gera grandes estragos.
O teste é o gabarito que diz o que é certo e o que é errado para o código, sendo impossível saber se algo quebrou sem ele.
Como Evitar:
Pare de testar debugando: Debugar é para diagnosticar um erro específico; não é uma rotina de teste consistente.
Faça Teste Unitário: Escrever código que testa o código é o melhor jeito, pois automatiza e versiona o gabarito. Teste é um investimento, não um custo.
Se for Teste Manual, Escreva-o: Documente os passos do teste (e.g., "preencher campo X e clicar Y, deve aparecer mensagem Z") para garantir consistência e evitar testes viciados.
Adote o Loop: Alterou e Testou: Ao refatorar, faça uma pequena alteração e execute os testes, repetindo o ciclo para garantir que o comportamento original seja mantido.
- Refatorar sem um propósito
O Erro: Refatorar por incômodo pessoal (código feio ou ruim) e não por uma necessidade de negócio que justifique a alteração.
Código quebrado incomoda muito mais do que código ruim; era melhor deixar o código ruim funcionando do que quebrá-lo com uma alteração sem propósito.
Se você altera o código sem motivo e ele quebra, é difícil de explicar o problema ao gestor, gerando a percepção de um perfeccionismo inútil e arranhando sua imagem.
Boa intenção não é motivo suficiente para alterar o código; é necessário um processo que apoie a mudança.
Como Evitar:
- Limite a refatoração ao escopo do seu trabalho: Só refatore aquilo que você vai mexer por uma demanda de negócio. Se não tem a ver com sua alteração, deixe quieto.
- Anote em vez de Alterar: Se você vir um ponto esquisito fora do seu escopo, anote o problema (em um comentário no código, post-it ou caderno). Isso permite que o próximo desenvolvedor que passar por ali faça a refatoração.
- Pegue carona nas demandas: Use demandas de negócio que passem por um ponto problemático para realizar a refatoração. Isso diminui o risco, pois o teste da sua alteração cobrirá o código refatorado.
Considerações finais
A melhoria do software legado é uma construção constante e demorada; o processo deve ser sem pressa, mas sem pausa.
O tempo da empresa (que pode ter 40 ou 50 anos) é diferente do seu tempo; não julgue a urgência de resolver todos os problemas em um dia.
Aproveite o legado para aprender: Mexer em código legado é uma excelente oportunidade para aprender sobre a parte técnica (refatoração, testes) e, principalmente, sobre o negócio da empresa, absorvendo conhecimento durante o trabalho.
Feito!
