Reescrever ou manter: como decidir

Todo sistema com alguns anos de vida provoca a mesma reação em quem chega: isto aqui precisa ser reescrito.

Às vezes precisa mesmo. Mas a reescrita tem uma armadilha conhecida: o sistema antigo, por pior que pareça, contém anos de regra de negócio que ninguém documentou. Cada condição estranha no meio do código costuma ser a cicatriz de um problema real que apareceu uma vez e nunca mais, justamente porque alguém colocou aquela condição ali.

A reescrita começa limpa e vai reencontrando essas regras uma a uma — em produção, com o cliente reclamando. É o que faz o prazo de seis meses virar dois anos.

Antes de decidir, algumas perguntas separam o incômodo do problema:

• O que exatamente dói? Custa caro mudar, quebra com frequência, é lento, ou apenas usa uma tecnologia que ninguém gosta mais?
• Com que frequência esse sistema muda? Software que quase não é alterado tem pouco a ganhar com reescrita, por mais feio que esteja por dentro.
• Existe teste automatizado? Sem isso, tanto manter quanto reescrever são apostas — só que a reescrita aposta tudo de uma vez.
• A regra de negócio está documentada em algum lugar além do código?
• Quem mantém hoje? Se o conhecimento está em uma pessoa só, esse é o risco urgente, e ele não se resolve com tecnologia nova.

Há um caminho intermediário que costuma ser ignorado porque não é empolgante: isolar. Em vez de reescrever tudo, cerca-se o sistema antigo, coloca-se uma camada na frente e substitui-se um pedaço de cada vez, com o sistema em pé o tempo inteiro. É mais lento no papel e mais rápido na prática, porque cada etapa entrega valor e pode ser revertida sozinha.

O que geralmente justifica reescrever de fato:

• A tecnologia não recebe mais atualização de segurança e não há caminho de migração.
• O modelo de dados impede uma mudança que o negócio precisa fazer agora, não daqui a três anos.
• O custo de manter, medido em horas reais, já supera o de substituir.
• Não existe mais ninguém no mercado, nem na empresa, capaz de dar manutenção naquilo.

O que geralmente não justifica: a linguagem estar fora de moda, o código ser feio, ou a equipe atual não ter escrito aquilo. Nenhum desses três aparece na conta do cliente.

Vale dizer que reescrever não é errado — é caro. A pergunta certa não é se o sistema merece ser reescrito, mas se aquele é o melhor uso do orçamento de engenharia neste momento, comparado a tudo que também está esperando.

Quando a resposta honesta for manter, mantenha bem: teste, documentação e reorganização gradual valem mais do que uma reescrita adiada indefinidamente e discutida em toda reunião.