Existe um momento previsível na vida de todo sistema com alguns anos: alguém — geralmente um desenvolvedor bom e sincero — diz que seria mais rápido reescrever tudo do zero.
Essa pessoa está sendo honesta. Ela está sofrendo com aquele código de verdade. E ainda assim, na maior parte das vezes, está errada.
Por que a reescrita parece sempre a melhor ideia
Há uma assimetria cognitiva conhecida em engenharia de software: ler código é mais difícil que escrever código.
Quando você lê código alheio, cada decisão estranha parece burrice. Quando você escreve, cada decisão faz sentido — porque você tem o contexto na cabeça.
Isso cria uma ilusão sistemática: o código existente parece pior do que é, e o código futuro que você imagina parece melhor do que será. A reescrita se apresenta como troca de algo ruim e conhecido por algo bom e imaginado.
Só que aquele código feio contém algo que o código imaginado não contém: anos de correções que ninguém documentou.
Aquela condicional aparentemente sem sentido cobre um caso de cliente de 2021. O campo duplicado na tabela existe porque um sistema externo exige o formato antigo. Cada esquisitice é uma cicatriz, e cicatriz é conhecimento.
O que costuma acontecer numa reescrita completa
O padrão se repete tanto que dá para prever:
Mês 1–2. Velocidade alta. Sem legado, sem regra de exceção. O time está animado e a diretoria também.
Mês 3–4. Começam a aparecer os casos que ninguém lembrava. Cada um vira uma investigação no sistema antigo. A velocidade cai.
Mês 5–6. O negócio precisa de mudanças no sistema antigo — ele continua sendo o que gera receita. Agora existem duas bases para manter e o time se divide.
Mês 7–9. O sistema novo cobre a maior parte, mas não os detalhes. E são os detalhes que impedem o desligamento do antigo.
Mês 10. Alguém pergunta quanto já foi gasto e o que foi entregue ao negócio. A resposta desconfortável costuma ser: muito, e nada.
Nem todo projeto de reescrita termina assim. Mas quando termina, termina assim.
Um critério de decisão
Antes de escolher, responda quatro perguntas com honestidade:
1. Quanto tempo levaria para reconstruir só o que está em uso?
Não o sistema inteiro — só as funcionalidades que alguém usou nos últimos 90 dias. É comum descobrir que metade do sistema é código morto. Se a resposta for menos de três meses, reescrita entra na mesa. Se for mais de seis, o risco cresce muito rápido.
2. A tecnologia original ainda tem caminho de saída?
PHP 5 pode ser migrado para PHP 8 em passos. CodeIgniter pode conviver com Laravel durante uma transição. Já uma tecnologia sem suporte, sem profissionais disponíveis e sem caminho de upgrade é um caso legítimo de reescrita.
3. O problema é a arquitetura ou é a bagunça?
São coisas diferentes. Código bagunçado com arquitetura razoável é refatorável de forma incremental. Arquitetura fundamentalmente errada — por exemplo, um modelo de dados que não representa mais o negócio — é mais difícil de corrigir por dentro. Mas mesmo aí, a substituição módulo a módulo geralmente é possível.
4. Existe suíte de testes?
Sem testes, refatorar é arriscado. Mas a conclusão correta não é “então vamos reescrever” — é “então vamos escrever testes de caracterização primeiro”. Testes que capturam o comportamento atual, inclusive as esquisitices, são o que torna a refatoração verificável.
A terceira opção que quase ninguém considera
O debate costuma ser apresentado como binário: reescrever tudo ou conviver com o legado. Existe um caminho do meio, e ele é quase sempre o melhor.
Strangler Fig: substituir por dentro
O nome vem da figueira-mata-pau, que cresce em volta da árvore hospedeira até substituí-la por completo.
Aplicado a software:
- Coloque uma camada na frente. Todo tráfego passa a atravessar um roteador — um proxy reverso ou uma camada de aplicação. Nada muda para o usuário.
- Escolha o módulo mais dolorido. O que consome mais manutenção ou trava mais o negócio. Reescreva só ele, na arquitetura nova.
- Roteie aquele pedaço. A camada passa a mandar aquelas requisições para o código novo. Se der problema, você reverte a rota em segundos.
- Repita. Módulo a módulo, sempre em produção.
- Desligue o antigo quando o último módulo migrar.
Por que isso é melhor
Cada etapa entrega valor sozinha. Se o orçamento acabar no quarto módulo, você tem quatro módulos modernos em produção — não meio sistema novo inutilizável.
O risco é reversível. Um problema afeta um módulo, não o sistema inteiro, e a reversão é uma mudança de rota.
O negócio nunca para. Funcionalidades novas continuam sendo entregues durante toda a modernização, na arquitetura nova.
O conhecimento migra junto. Ao reescrever um módulo por vez, com o antigo do lado como referência viva, as regras não documentadas aparecem — em vez de sumirem.
Como apresentar isso para a diretoria
Argumento técnico não vence essa discussão. Risco e fluxo de caixa vencem:
“Reescrita completa: 8 a 12 meses sem entrega nova para o negócio, mantendo dois sistemas, com data de conclusão historicamente otimista. Modernização incremental: melhoria mensurável no primeiro ciclo de 6 semanas, entregas contínuas, e possibilidade de parar a qualquer momento sem perder o que já foi investido.”
Colocado assim, a decisão costuma se resolver sozinha.
Quando a reescrita é a resposta certa
Para ser justo com o outro lado — há casos legítimos:
- A base é pequena, com poucos meses de reconstrução
- A tecnologia perdeu suporte e não existe caminho de migração
- O modelo de negócio mudou tanto que o domínio antigo não representa mais a realidade
- O sistema é um protótipo que virou produção por acidente e nunca teve arquitetura
Nesses casos, reescreva. Mas reescreva sabendo que é uma reescrita — com prazo realista, com o sistema antigo mantido e com a decisão tomada por análise, não por frustração com o código.
Se você está nessa encruzilhada agora, a auditoria técnica é feita exatamente para responder isso com dados: o que dá para aproveitar, o que precisa ser refeito e quanto custa cada caminho.