Refatorar ou reescrever sistema: o que cada caminho significa na prática
Refatorar é mudar a estrutura interna do código sem mudar o que o sistema faz para o usuário. Você reorganiza, separa responsabilidades, troca bibliotecas e cria testes, tudo com o sistema em produção. A refatoração de código legado acontece em passos pequenos, e cada passo pode ir ao ar.
Reescrever é construir um sistema novo ao lado do antigo e trocar um pelo outro no fim. Existe um dia da virada, e até lá o investimento não gera nada que o usuário veja.
Essa diferença muda o perfil de risco. Na refatoração, o erro aparece cedo e é pequeno. Na reescrita completa, o erro tende a aparecer na virada, quando já se gastou quase todo o orçamento.
Vale dizer que trocar a linguagem não obriga a reescrever. Dá para mudar framework, arquitetura e interface mantendo a linguagem e boa parte da lógica. Muita discussão de reescrever termina quando se separa o que está ruim (a estrutura) do que está bom (as regras que a empresa levou anos para acertar).
Por que a reescrita total costuma dar errado
O primeiro risco é perder regras de negócio escondidas no código. Um sistema com dez anos de uso carrega centenas de decisões que ninguém documentou: o desconto que não vale para tal cliente, o arredondamento que o financeiro exige, o caso especial que um contrato antigo criou. Ninguém lembra delas até o sistema novo errar.
O segundo é congelar o produto. Enquanto o time constrói a versão nova, o sistema antigo continua precisando de correções e melhorias. Ou você mantém dois times, ou para de evoluir o produto por meses. O negócio não espera, então as mudanças acabam sendo feitas duas vezes, no antigo e no novo.
O terceiro é a estimativa errada. É fácil estimar o que se vê (telas, relatórios, cadastros) e difícil estimar o que não se vê: integrações, migração de dados sujos, permissões, rotinas noturnas. O erro mais comum que vemos é orçar a parte visível e descobrir o resto no meio do caminho.
Há ainda um quarto risco, mais sutil: o efeito do sistema novo. O time acha que vai fazer tudo certo desta vez, e o escopo cresce. A reescrita vira a chance de incluir tudo o que ficou de fora, e o projeto deixa de ser uma troca para virar um produto novo, com prazo e custo de produto novo.
Quando reescrever software do zero faz sentido de verdade
Defendemos a reescrita completa em poucos casos, e todos têm critério verificável.
Mesmo nesses casos, recomendamos reduzir o escopo ao que o negócio usa hoje. Reescrever tudo que o sistema antigo fazia, inclusive o que ninguém usa mais, é a forma mais cara de começar.
- A tecnologia não tem mais suporte e não há caminho de atualização: linguagem ou plataforma sem correções de segurança, sem profissionais no mercado ou sem compatibilidade com o que a empresa precisa usar.
- A arquitetura impede o negócio: por exemplo, um sistema desenhado para um único cliente que precisa virar multiempresa, ou um desenho que não aceita integração com nada e trava qualquer parceria.
- O sistema é pequeno: se refazer leva poucas semanas e as regras cabem na cabeça de quem o usa, o custo de entender o código velho pode ser maior que o de escrever de novo.
- O sistema já não é usado como foi desenhado: o processo da empresa mudou tanto que o que existe resolve um problema que acabou.
Quando refatorar é a melhor escolha
Refatorar é melhor quando o sistema funciona, os usuários dependem dele e o problema real é que mexer nele ficou caro ou assustador. Esse é o quadro mais comum: o código roda, mas cada mudança leva o triplo do tempo e quebra algo longe dali.
Nesses casos, o ganho está em atacar os pontos que doem: a parte que muda toda semana, a que quebra sempre, a que só uma pessoa entende. Não é preciso consertar tudo. Um módulo bem organizado, com testes, já reduz o custo de mudança naquela área.
Outro sinal a favor da refatoração é o conhecimento de negócio estar no código e em mais lugar nenhum. Se a documentação não existe e o time que construiu saiu, o código é a única fonte de verdade. Jogá-lo fora é jogar fora essa memória.
Se você quer o panorama completo de como esse trabalho se organiza, o nosso guia sobre modernização de sistemas legados cobre as opções de ponta a ponta.
A alternativa do meio: migração incremental e o padrão strangler
Entre refatorar por dentro e reescrever tudo existe um terceiro caminho, e é o que mais recomendamos para sistemas médios e grandes: a migração incremental. O padrão mais conhecido se chama strangler, ou figueira-estranguladora, em referência a uma planta que cresce em volta da árvore até substituí-la.
Na prática, você coloca uma camada na frente do sistema antigo, que decide para onde cada requisição vai. Pega um módulo, reconstrói na tecnologia nova, e desvia só esse tráfego. O resto continua no sistema velho. Repete, módulo a módulo, até o antigo não receber mais nada e poder ser desligado.
As vantagens são concretas: cada módulo vai para produção sozinho, o erro fica contido, dá para voltar atrás desviando o tráfego de volta, e o produto continua evoluindo. Você também aprende com os primeiros módulos e ajusta a estimativa dos seguintes com dados reais.
O ponto de atenção é o banco de dados. Se o sistema novo e o antigo escrevem nas mesmas tabelas sem cuidado, os dois se atrapalham. Defina quem é dono de cada dado em cada etapa e planeje a sincronização. Detalhamos esse tipo de cuidado em como migrar um sistema PHP antigo sem parar a operação.
É esse o formato que seguimos na nossa área de modernização de sistemas legados: etapas pequenas, sistema no ar o tempo todo e manutenção contínua depois.
Perguntas para decidir entre refatorar e reescrever
Antes de escolher, responda com honestidade a estas perguntas. Se várias respostas forem vagas, o problema é falta de informação, e o primeiro passo é um diagnóstico, não uma decisão.
- A tecnologia atual ainda recebe correções de segurança e tem profissionais disponíveis no mercado?
- Sabemos listar as regras de negócio que o sistema aplica, ou elas só existem no código?
- Existem testes automatizados? Sem eles, qualquer mudança, refatorar ou reescrever, é feita às cegas.
- O que impede o negócio hoje: o custo de cada mudança, a instabilidade, a falta de integração ou um limite de arquitetura?
- Conseguimos manter o produto evoluindo por meses sem entregar nada novo? Se não, a reescrita total está descartada.
- Quantos módulos o sistema tem e quais são independentes? Quanto mais separáveis, mais viável a migração incremental.
- Quem entende o sistema ainda está na empresa? Se essa pessoa sair no meio do projeto, o que acontece?
- Qual o custo de errar? Um sistema que para a operação e um relatório interno pedem apetites de risco diferentes.
Roteiro de decisão em seis passos
Este é o roteiro que usamos para chegar a uma decisão que se sustenta diante da diretoria.
O passo seis é o que mais evita arrependimento. Uma amostra pequena e real mostra, com dados do seu sistema, quanto custa extrair uma regra, migrar um dado e testar o resultado. Isso vale mais que qualquer estimativa feita só olhando a tela. Se quiser ver como isso fica antes de se comprometer, você pode pedir um protótipo grátis. E para ter uma ordem de grandeza de investimento, veja do que depende quanto custa modernizar um sistema legado.
- Passo 1: defina o problema de negócio em uma frase (por exemplo, lançar uma funcionalidade leva meses por causa do código), não o problema técnico.
- Passo 2: faça o inventário: módulos, integrações, bancos de dados, rotinas agendadas e quem usa cada parte.
- Passo 3: verifique os critérios de reescrita: tecnologia sem suporte, arquitetura que bloqueia o negócio, sistema pequeno. Se nenhum se aplica, descarte a reescrita completa.
- Passo 4: levante as regras de negócio, conversando com os usuários e lendo o código das áreas críticas, e transforme-as em testes.
- Passo 5: ordene os módulos por dor e por independência. Comece pelo que dói e pode ser separado.
- Passo 6: faça um piloto em um módulo pequeno, meça esforço e risco, e só então decida o formato e o orçamento do restante.
Erros comuns ao decidir
O erro mais comum que vemos é decidir pela tecnologia e não pelo problema. Alguém quer usar a ferramenta da moda e a reescrita vira justificativa. O segundo é subestimar a migração de dados, que costuma ser a parte mais lenta e a que mais surpreende.
Também é frequente tratar a decisão como binária. Refatorar um módulo, reescrever outro que é pequeno e estrangular o resto é uma combinação perfeitamente legítima. E, por fim, planejar a modernização sem prever manutenção depois: o sistema novo envelhece igual ao antigo se ninguém cuidar dele.
Da nossa experiência
Na SKAD, refatoramos com apoio de IA os sistemas SyncStop, 4Car, KaraokeApp, The Bee App e DEM (inspeção de equipamentos). Todos eram PHP puro com jQuery e Bootstrap, e os aplicativos usavam Cordova.
Hoje eles rodam em PHP 8.3 com Slim 4 na API, React com Vite na web e React Native com Expo no app. Mantivemos a linguagem PHP e mudamos o framework e a arquitetura, sem partir de uma página em branco.
Depois da refatoração, a manutenção desses sistemas ficou mais leve. É por isso que, quando o sistema funciona e o problema é a estrutura, a nossa inclinação é refatorar e migrar por etapas, e não começar tudo de novo.
Perguntas frequentes
Reescrever um sistema do zero é sempre uma má ideia?
Não. Faz sentido quando a tecnologia não tem mais suporte, a arquitetura impede o negócio ou o sistema é pequeno. Fora desses casos, o risco costuma ser maior que o benefício.
Quanto tempo leva refatorar ou reescrever um sistema?
Depende do tamanho, do número de integrações, da qualidade dos dados e da existência de testes. Por isso desconfie de qualquer prazo dado sem olhar o sistema; um piloto em um módulo dá uma base real.
O que é o padrão strangler?
É uma forma de migração em que uma camada na frente do sistema antigo desvia, módulo a módulo, o tráfego para a versão nova. O sistema velho vai sendo esvaziado até poder ser desligado.
Dá para refatorar um sistema sem testes automatizados?
Dá, mas com mais risco. O melhor é criar testes para as regras críticas antes de mexer, assim você sabe se a mudança preservou o comportamento.
Refatorar ou reescrever: qual sai mais barato?
No curto prazo a reescrita parece mais simples, mas o custo real costuma aparecer em regras esquecidas, migração de dados e tempo sem evoluir o produto. A refatoração incremental distribui o gasto e permite parar ou ajustar o rumo.
Conclusão
Antes de aprovar uma reescrita ou uma refatoração, peça um diagnóstico do sistema atual: inventário de módulos, regras críticas, estado dos testes e um piloto em um pedaço pequeno. Com isso na mão, a decisão deixa de ser uma aposta. Se quiser, nosso time faz esse diagnóstico com você: chame a gente no WhatsApp pelo botão abaixo e conte o que o seu sistema legado faz hoje e onde ele trava.