Refatorar ou reescrever: como decidir sem apostar errado
Critérios objetivos para decidir entre refatorar e reescrever um sistema, por que reescrita costuma custar o dobro do previsto e qual o caminho seguro.
Resposta rápida
A decisão entre refatorar e reescrever não depende da idade do código nem da tecnologia usada, e sim de três coisas: se o sistema ainda atende o negócio, se existe quem entenda as regras que ele implementa, e se dá para entregar valor em partes. Reescrita completa é a opção mais arriscada que existe em software, porque durante meses você paga por duas coisas e não entrega nenhuma novidade — e porque a regra de negócio que ninguém documentou mora no código antigo.
Neste artigo
“Esse sistema é antigo demais, vamos refazer do zero.”
É a frase mais cara da área, e quase sempre dita com convicção. Às vezes ela está certa. Na maioria das vezes, não — e a diferença entre os dois casos pode ser avaliada antes de gastar.
O que não deve decidir
A idade do código. Sistema de doze anos que atende o negócio e recebe manutenção é um ativo, não um problema.
A tecnologia parecer antiga. Isso vira problema quando a plataforma deixa de receber correção de segurança, quando não se encontra mais quem queira trabalhar nela, ou quando ela impede algo que o negócio precisa fazer. Fora desses casos, é incômodo estético.
A opinião de quem acabou de chegar. Todo desenvolvedor que assume código alheio acha que seria melhor refazer. É quase uma lei da natureza, e quase sempre subestima o que o código antigo já resolve.
As três perguntas que decidem
1. O sistema ainda atende o negócio?
Separe duas coisas: funciona mal e não faz o que precisa.
Sistema que faz o certo de forma feia é candidato a refatoração. Sistema que não consegue fazer o que o negócio hoje exige — e não consegue nem com esforço — é candidato a substituição.
2. Existe quem entenda as regras?
Aqui mora o risco principal da reescrita. O sistema antigo contém regras adicionadas ao longo de anos para resolver casos reais: o cliente que tem condição especial, o cálculo que muda em dezembro, a exceção criada depois de um problema com a Receita.
Nada disso está documentado. Está no código.
Se ninguém na empresa sabe enunciar essas regras, a reescrita vai descobri-las uma a uma, em produção, cada vez que um usuário reclamar de algo que antes funcionava. É assim que projetos de reescrita dobram de prazo.
3. Dá para entregar em partes?
Se você consegue trocar um módulo sem derrubar o resto, dá para fazer gradual. Se tudo está amarrado em tudo, a troca por partes fica difícil — e aí o projeto tem risco maior, qualquer que seja o caminho.
O teste prático: escolha a parte mais problemática do sistema e pergunte quanto do resto precisaria mudar junto. Se a resposta for “quase tudo”, você também descobriu por que o sistema é difícil de manter.
Por que reescrita completa é a opção mais arriscada
Durante a reescrita, a empresa paga por dois sistemas e não ganha nenhuma funcionalidade nova. O antigo continua precisando de manutenção, porque está em produção.
Esse período costuma durar mais que o previsto, e é quando a pressão aparece: o negócio pede uma mudança urgente, e ela precisa ser feita nos dois lugares — ou é feita só no antigo, aumentando a distância.
E há o risco silencioso: o sistema novo entra em produção e funciona pior nas bordas, nos casos de exceção que o antigo tratava sem ninguém saber.
O caminho que costuma funcionar
Trocar por partes, com os dois convivendo:
- Escolha a parte de maior dor e menor acoplamento. Normalmente uma tela ou um fluxo específico.
- Construa essa parte na base nova, lendo e gravando nos mesmos dados.
- Direcione o uso para a parte nova e mantenha o resto no antigo.
- Repita, uma parte por vez.
As vantagens são concretas: entrega valor desde o primeiro ciclo, cada etapa é validada em produção com volume real, e dá para parar no meio se a prioridade da empresa mudar — algo impossível numa reescrita completa.
Foi assim na modernização que fiz na Edusense, migrando front-end antigo em etapas, com a plataforma em produção durante toda a transição.
Quando reescrever é a resposta certa
Existem casos. Seja honesto se for o seu:
- A plataforma não recebe mais correção de segurança e há dado sensível envolvido.
- O sistema depende de algo que deixou de existir e não há substituto.
- O custo de manter já supera o de refazer, com números na mesa.
- O negócio mudou tanto que o sistema resolve um problema que a empresa não tem mais.
Mesmo nesses casos, documente as regras antes de começar. Levantar o que o sistema atual faz, incluindo as exceções, é a atividade que mais reduz risco de reescrita — e a que mais se pula.
Como começar
Antes de decidir, responda:
- O que especificamente o sistema impede o negócio de fazer hoje?
- Quem sabe enunciar as regras que ele implementa?
- Qual a parte de maior dor e menor acoplamento?
Se a primeira pergunta não tiver resposta concreta, provavelmente a resposta é refatorar — ou simplesmente conviver.
Os sinais de alerta estão em sinais de que sua empresa precisa refatorar o sistema legado. Se o problema for falta de acesso e não de código, comece por o desenvolvedor sumiu.
Quer uma avaliação do seu caso? Me chame.
Perguntas frequentes
Como sei se dá para refatorar em vez de reescrever?
Se você consegue listar as partes do sistema e trocar uma delas sem derrubar o resto, dá para refatorar. O teste prático é escolher a tela ou o módulo mais problemático e perguntar quanto do sistema precisaria mudar junto. Se a resposta for quase tudo, a refatoração será mais difícil.
Por que reescrita costuma estourar o orçamento?
Porque o sistema antigo contém regras que ninguém lembra que existem. Elas foram adicionadas ao longo de anos para resolver casos reais e não estão escritas em lugar nenhum. A reescrita descobre essas regras uma a uma, em produção, quando o usuário reclama de algo que antes funcionava.
Trocar de tecnologia é motivo suficiente para reescrever?
Sozinho, não. Tecnologia antiga é problema quando deixa de receber correção de segurança, quando ninguém mais quer trabalhar nela ou quando impede algo que o negócio precisa. Se nada disso é verdade, o sistema estar em tecnologia antiga é um incômodo, não uma emergência.
Existe caminho intermediário?
Existe, e costuma ser o melhor: trocar por partes, mantendo os dois sistemas convivendo. Uma funcionalidade por vez é migrada para a base nova, enquanto o resto continua no antigo. Entrega valor desde cedo e permite parar no meio se a prioridade mudar.
Quem escreve
Thainan Prado
Desenvolvedor full stack sênior com mais de 8 anos de experiência, responsável por sistemas em produção para empresas como OXXO, Ambev e Shell Select. Desenvolve sistemas sob medida, automações e integrações para PMEs e empresas médias de todo o Brasil.