Refatoração ou reescrita? Como lidar com legado

Dizem que a gente aprende a programar em projetos verdes. Só que o dinheiro da empresa, e a maior parte da experiência real, está em sistemas que já nasceram, cresceram e envelheceram antes da gente chegar.

Meu carro velho

Passei um pouco mais de um ano trabalhando com GeneXus. Para quem não conhece, é uma plataforma low-code que promete gerar aplicação a partir de modelos. Na prática, é como um carro velho: funciona, leva você de um ponto a outro, mas sempre precisa de um ajuste aqui e uma gambiarra ali para não morrer no meio do caminho.

A IDE parece ter vindo de outra década. A arquitetura é antiga, limitada em memória, e o primeiro rebuild do dia costuma ser longo o suficiente para dar tempo de fazer um café. Em um time com cerca de quinze estagiários, eu vi praticamente todo tipo de solução possível: boas, medianas e algumas que me fizeram querer largar tudo e ir vender arte na praia.

Mas aprendi uma coisa importante ali: legado não é coisa de gente preguiçosa. Legado é o que sobra depois que anos de pressão, troca de pessoas, prazos apertados e decisões do momento empilham uma sobre a outra. E, na maioria das empresas, é exatamente ali que você vai passar a maior parte do tempo.

A PBI que parecia simples

Em um dia qualquer, peguei uma tarefa que parecia inofensiva: refatorar as mensagens de erro do sistema. Era para ser só um ajuste de texto. Mas quanto mais eu mexia, mais eu enxergava o mesmo problema se repetindo em várias partes do código: cada erro era tratado de um jeito, ninguém sabia qual mensagem ia aparecer para o usuário, e depurar um problema simples virava uma caça ao tesouro.

Resolvi ir além. Em vez de só trocar textos, criei um módulo nativo para padronizar o tratamento de erros HTTP com base em domínios pré-programados. O objetivo era simples: o desenvolvedor registra o domínio, e o sistema responde de forma consistente quando algo dá errado. Por baixo, implementei um registro de erros inspirado na RFC 7807 (Problem Details) e no padrão Result que existe no ecossistema C#. Só que tudo dentro do universo GeneXus.

Funcionou. A mensagem ficou previsível, o log ficou claro, e a manutenção de bugs do tipo parou de ser uma expedição. Documentei tudo. Publiquei a proposta de padrão. E aí veio a parte que ninguém me avisou: quase ninguém aderiu.

A frase que eu mais ouvi

Quando você propõe um padrão novo em um ambiente acostumado a improvisar, a resposta mais comum é alguma variação de: “dá mais trabalho do que só não mexer”. O que é um argumento curioso, porque qualquer bug mínimo naquele mesmo código acabava virando uma PBI de valor treze — a de maior duração prevista na metodologia. Ou seja, não mexer só parecia mais barato na hora.

A verdade é que mudar hábitos de um time é mais difícil do que mudar código. Código a gente compila e testa. Pessoas precisam de tempo, confiança e ver o benefício acontecendo de verdade. Eu aprendi na marra que uma solução técnica boa não se sustenta sozinha: ela precisa de evangelização, de exemplos pequenos, de vitorias fáceis de copiar.

"Código a gente compila e testa. Pessoas precisam de tempo, confiança e ver o benefício acontecendo de verdade."

O livro que me fez sentir menos sozinho

Nessa época eu comecei a ler Working Effectively with Legacy Code, do Michael Feathers. Ele é praticamente o manual para quem trabalha com código que não nasceu ontem. A ideia central é simples: você não precisa reescrever tudo para melhorar. O que você precisa é introduzir mudanças pequenas, seguras e testáveis, até que o sistema fique mais maleável aos poucos.

Feathers fala sobre o medo de mexer no legado. Como ele mesmo descreve, desenvolvedores evitam alterar certas partes do sistema porque não sabem o que vai quebrar. A solução não é coragem cega. É criar janelas de segurança: testes, abstrações, interfaces que isolam o velho do novo. Ou seja, você não precisa matar o monstro. Você só precisa iluminar a sala onde ele vive.

Li esse livro e pensei: se ele tivesse passado um mês no meu lugar, provavelmente teria entendido exatamente o que eu sentia. Refatorar devagar exige paciência, política e uma resistência emocional que nenhum curso de arquitetura ensina.

Endoidar ou assumir a loucura?

Eu passei meses dividido entre dois mundos. De dia, GeneXus. De noite, Go, Python e outras linguagens que me mostravam como o desenvolvimento poderia ser quando você tem boas ferramentas, comunidade e padrões. A distância entre os dois mundos era frustrante.

Com o tempo, entendi que o desenvolvedor que lida com legado tem duas saídas. A primeira é deixar o ambiente te consumir. A segunda é assumir a loucura com consciência: aceitar que o sistema não vai mudar da noite para o dia, mas continuar tentando melhorar pequenas partes, um módulo de cada vez, um padrão de cada vez.

A empresa não ter um padrão de desenvolvimento não é culpa sua. Mas você ainda pode ser a pessoa que planta uma semente. Não adianta culpar o passado. O que importa é o que você entrega hoje, e se o próximo dev que abrir aquele arquivo vai achar um pouco menos sofrimento do que você achou.

Reescrita ou refatoração?

Ainda hoje eu vejo times empolgados com a ideia de reescrever tudo. “Vamos fazer do zero, dessa vez a gente faz direito.” Só que reescrever é raramente a resposta. Você troca código velho e conhecido por código novo e desconhecido, perde histórico de decisões, e geralmente descobre que os problemas antigos reaparecem em novos formatos.

Refatoração, feita com cuidado, é mais barata, menos arriscada e mais sustentável. Ela não é glamurosa. Não gera post de LinkedIn comemorando um deploy. Mas é a forma honesta de cuidar de um sistema que precisa continuar vivo enquanto você o melhora.

Se você também trabalha com legado e às vezes se sente no limite, recomendo fortemente a leitura de Working Effectively with Legacy Code. E, se quiser trocar ideia sobre como fazer refatorações sem quebrar o que já funciona, é só me chamar no WhatsApp.