Diga não à reescrita

Todo engenheiro uma hora fica diante de uma base de código e sente o chamado. É velha, é inconsistente, ninguém entende o terço do meio, e o pensamento se forma com clareza: a gente devia reescrever isso. Já senti isso muitas vezes. Em mais de 600 projetos, vi a reescrita ser proposta, aprovada, iniciada e, na maioria dos casos, abandonada em silêncio ou entregue tão tarde que resolveu um problema que o negócio já não tinha.

Este é o argumento para dizer não. Não sempre. Mas por padrão, e com o ônus da prova do lado da reescrita.

O que a reescrita promete e o que entrega

A reescrita promete um começo limpo. O que ela entrega é um segundo sistema que precisa alcançar paridade de funcionalidades com o primeiro antes que alguém possa usá-lo, enquanto o primeiro continua mudando porque o negócio não para. Você persegue um alvo em movimento com um time que agora está dividido entre manter o velho e construir o novo.

A parte que ninguém coloca na conta é o conhecimento preso no código antigo. Aquele condicional estranho no módulo de cobrança não é um erro. É uma regra que alguém aprendeu com a reclamação de um cliente em 2019 e ninguém anotou. A reescrita apaga. Seis meses depois do lançamento, a reclamação volta.

As perguntas que faço antes de aprovar uma

Quando um time me traz uma proposta de reescrita, peço que respondam a estas por escrito.

• O que, especificamente, não dá para fazer no sistema atual? Não "é difícil de manter". Qual mudança, pedida por quem, está travada?
• Vocês tentaram corrigir essa coisa específica no lugar, e o que aconteceu?
• Qual é o plano para o período em que os dois sistemas coexistem? Quem é dono do velho?
• Se a reescrita parasse em 60%, o que vocês teriam?
• O que vocês vão fazer diferente para que o sistema novo não vire o velho daqui a cinco anos?

A maioria das propostas não sobrevive à primeira pergunta. A resposta honesta costuma ser "nada está travado, a gente só não gosta". Isso é um custo real, mas não é um custo do tamanho de uma reescrita.

O que fazer no lugar

A alternativa não é "conviver com isso". É tratar a base de código como uma cidade, não como um prédio. Você não demole uma cidade porque um bairro está degradado. Você conserta o bairro.

Encontre o módulo que mais dói. Coloque uma fronteira em volta dele: uma interface clara, testes na borda, um contrato pelo qual o resto do sistema conversa. Então substitua o que está dentro da fronteira, e só isso. Quando funcionar, escolha o próximo módulo. É mais lento por módulo e mais rápido no total, porque o sistema continua rodando e o negócio continua entregando o tempo todo.

A outra coisa a fazer é registrar o conhecimento antes que ele se perca. Todo condicional estranho ganha um comentário explicando a reclamação de cliente por trás dele. Toda regra não documentada passa a ser documentada. Só isso já reduz o chamado da reescrita, porque metade desse chamado é medo do que você não entende.

Quando a resposta é sim

Há reescritas que aprovei. A plataforma estava sendo descontinuada. A linguagem não tinha mais runtime mantido. O modelo de dados estava errado na raiz e cada funcionalidade era uma gambiarra em cima da mesma premissa errada. Nesses casos, a resposta para "o que não dá para fazer" é específica e grave, e a reescrita não é preferência, é prazo.

Mesmo assim, insisto na abordagem por fronteiras. O sistema novo assume uma responsabilidade de cada vez. O velho é aposentado módulo a módulo, não num dia de lançamento.

A parte de carreira

Dizer não à reescrita é impopular. O time quer. O engenheiro novo quer. A reescrita é empolgante e o conserto é chato. Mas os engenheiros em quem mais confio são os que conseguem olhar para um sistema feio e funcional e dizer: isso é feio, funciona, e aqui está a menor mudança que deixa menos feio sem parar de funcionar. Essa frase, repetida por anos, é como se constrói a reputação de ser a pessoa que entrega.