Antes de reescrever um sistema legado do zero, tente estrangular um módulo
Peguei um sistema legado mês passado pra mexer: sem teste, uma função de mil linhas no meio do fluxo de pedido, e o impulso clássico de apagar tudo e recomeçar. Resisti. Reescrever do zero quase sempre vira dois sistemas rodando em paralelo por meses, mais a volta de bugs que já tinham sido resolvidos.
O caminho que funcionou foi o strangler fig: trocar um módulo de cada vez, com o sistema no ar.
O passo que quase todo mundo pula é escrever um teste de caracterização ANTES de tocar no código. Ele não valida o "certo" — só congela o comportamento atual (inclusive os defeitos), pra você saber se quebrou alguma coisa na troca.
// congela o comportamento atual do módulo antes de reescrever
test('roteirização: saída atual do pedido 4821', () => {
const out = roteirizar(pedido4821)
expect(out).toMatchSnapshot()
})
Com o comportamento travado, dá pra:
- Extrair o módulo atrás de uma interface estável (ex.:
calcularRota(pedido)). - Escrever a nova implementação por trás dessa mesma interface.
- Rodar as duas em paralelo (shadow) e logar divergência antes de desligar a antiga.
# roda a nova em shadow e loga onde ela diverge da velha
DIFF_ROUTING=shadow npm start
Quando as saídas batem por alguns dias, você remove a implementação velha. Sem grande dia de virada, sem freeze de meses.
Reescrita completa às vezes é necessária de verdade — arquitetura que não aguenta o modelo, banco errado na raiz. Mas "a base tá feia", sozinho, quase nunca justifica jogar fora anos de regra de negócio que ninguém documentou.
Versão completa no blog: https://revin.com.br/pt/blog/por-que-quase-nunca-aprovo-reescrever-um-sistema-do-zero