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:
- Coloque um roteador na frente do sistema antigo. Tudo continua funcionando como antes.
- Escolha uma funcionalidade com fronteira clara e valor alto. Reconstrua só ela, no ambiente novo.
- Desvie no roteador as requisições dessa funcionalidade para o sistema novo. Se der problema, desvie de volta em um minuto.
- 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.
A DCODER faz auditoria de sistemas legados e modernização incremental, com o engenheiro responsável avaliando o código antes de qualquer recomendação. Fale com o estúdio em dcoder.io.