Sistema legado: reescrever do zero ou refatorar por partes?

Na maioria dos casos, substitua por partes. A reescrita do zero só se justifica quando a plataforma base está sem suporte de segurança ou quando o modelo de dados original impede o negócio de crescer. Fora isso, você vai gastar dois anos para reconstruir funcionalidades que já funcionavam.

O pedido chega sempre com a mesma frase: “esse sistema é uma bagunça, é melhor refazer do zero”. Às vezes é verdade. Na maioria das vezes é a reação natural de quem está lidando com código que não escreveu, e a reescrita completa é a decisão mais cara que se pode tomar sobre um sistema em produção.

O que a reescrita realmente custa

O orçamento sempre considera reconstruir o que se vê. Nunca considera os cinco anos de correções invisíveis embutidas no sistema atual.

Aquele if esquisito no cálculo do frete não é código ruim. É a exceção do contrato com aquele cliente grande, resolvida numa sexta-feira de 2019. O sistema novo, limpo e bem arquitetado, não vai ter esse if. Vai ter o mesmo problema que aquele cliente reclamou em 2019.

E tem o detalhe que mata o cronograma: durante a reescrita, o sistema antigo não pode parar de evoluir. O negócio continua pedindo coisas. Ou você congela o produto por dois anos, o que nenhuma empresa aguenta, ou implementa tudo duas vezes.

Quando a reescrita realmente se justifica

Existem casos legítimos, e eles são reconhecíveis:

• A plataforma perdeu suporte de segurança. Uma versão de linguagem ou framework sem correções de vulnerabilidade não é dívida técnica. É risco jurídico e operacional.
• O modelo de dados impede o negócio. O sistema foi feito para uma empresa e uma moeda, e agora são cinco filiais em três países. Se toda nova exigência esbarra na mesma limitação estrutural, o problema é a fundação.
• Ninguém consegue mais mexer. Não porque é feio, mas porque não existe quem conheça a tecnologia no mercado e não existe teste algum que dê segurança para alterar.

Repare que “o código é feio” e “não gostamos dessa linguagem” não estão na lista.

A alternativa: estrangular o legado aos poucos

A abordagem que funciona é conhecida como strangler fig, em referência à figueira que cresce em volta da árvore hospedeira até substituí-la por completo. Na prática:

1. Coloque um roteador na frente do sistema antigo. Tudo continua funcionando como antes.
2. Escolha uma funcionalidade com fronteira clara e valor alto. Reconstrua só ela, no ambiente novo.
3. Desvie no roteador as requisições dessa funcionalidade para o sistema novo. Se der problema, desvie de volta em um minuto.
4. Repita. A cada ciclo, o legado encolhe.

A vantagem aqui nem é técnica, é política. O projeto entrega valor visível todo mês em vez de pedir dois anos de fé. Isso muda como a diretoria enxerga o investimento e, na prática, é o que faz o projeto chegar ao fim.

Antes de escolher qualquer caminho, coloque o legado sob rede

Independentemente da decisão, faça isto primeiro, porque serve para as duas estratégias:

• Backup restaurado com sucesso. Não “backup configurado”. Restaurado, em outro ambiente, com data documentada.
• Testes nos fluxos que geram dinheiro. Não busque cobertura ampla. Cubra os cinco caminhos que não podem quebrar.
• Registro e monitoramento. Você precisa saber o que o sistema está fazendo antes de mudá-lo. Muita gente descobre nessa fase que metade das telas nunca é usada, o que reduz o escopo da reescrita pela metade.
• Ambiente de testes que seja cópia fiel. Sem isso, toda alteração é aposta.

Esse trabalho leva de três a seis semanas e com frequência muda a conclusão. Já vi vários sistemas que “precisavam ser refeitos” virarem sistemas perfeitamente aceitáveis depois de ganharem monitoramento, índices e a remoção do que ninguém usava.

A pergunta que decide

É uma só: o sistema atual impede a empresa de fazer algo que ela precisa fazer para crescer?

Se a resposta é não, ele é chato, é lento, é feio, mas o negócio funciona, então o caminho é melhorar por partes. Se a resposta é sim e você consegue nomear exatamente o que está bloqueado, existe uma justificativa concreta. E mesmo assim, substituir por partes costuma chegar lá antes.