Há uma frase que toda a equipa técnica diz, mais cedo ou mais tarde: "vamos reescrever isto do zero".
É quase sempre má ideia.
A frase que matou produtos
Em 2000, Joel Spolsky publicou um ensaio que continua a ser leitura obrigatória mais de 25 anos depois: "Things You Should Never Do, Part I". O argumento central: reescrever uma codebase do zero é o pior erro estratégico que uma empresa de software pode cometer.
A tese envelheceu surpreendentemente bem.
Muitos produtos morreram, ou ficaram seriamente atrasados, depois da decisão de "reescrever". Netscape Navigator. Macromedia Authorware. Inúmeros produtos enterprise menos conhecidos. Quando se procura post-mortems de produtos falhados, "the rewrite" aparece com frequência desconfortável.
Para PMEs, o padrão repete-se em escala menor. Tem-se um produto que funciona mas a tecnologia está velha, há legacy, há decisões antigas que parecem maus. Decide-se reescrever. Para o desenvolvimento de features. Equipa concentra-se na reescrita durante 18 a 24 meses. Concorrência continua a lançar features. O mercado muda. Quando a reescrita finalmente chega, já não corresponde ao que se queria.
Refactoring vs Rewrite
A distinção entre os dois é importante.
Refactoring: melhorar o código existente em pequenos passos, mantendo comportamento, com testes. Ferramenta diária, contínua, integrada ao desenvolvimento normal.
Rewrite: substituir uma parte significativa do código por uma nova implementação, frequentemente com paragem temporária de novas features.
Refactoring é saudável e necessário. Rewrite é, em quase todos os casos, um erro estratégico.
Por que parece sempre boa ideia
O instinto de reescrever é compreensível. O código antigo é sempre mais difícil de ler do que código que se escreve. Tem comentários estranhos. Tem decisões que parecem maus. Tem trechos que parecem ineficientes.
O que costuma faltar perceber: aquele código contém milhares de pequenas decisões testadas em produção, durante anos. Cada if estranho corresponde a um caso real. Cada validação supérflua existe porque alguém uma vez submeteu algo inesperado. Cada workaround existe porque um sistema externo respondeu de forma estranha em 2019.
Reescrever significa esquecer tudo isto. E rapidamente descobrir que aquelas decisões estranhas eram necessárias, agora a ter de ser reaprendidas em produção, com clientes a sentir os bugs.
Quando rewrite faz sentido
Há casos onde rewrite genuíno é justificável. Não são muitos.
Tecnologia subjacente descontinuada sem caminho de migração. Por exemplo, se o sistema dependesse de Flash em 2020, era preciso reescrever.
Mudança fundamental de modelo de negócio que exige arquitectura diferente. Se uma empresa B2B passa a ser B2C com escala 1000x, modelo de dados pode precisar de mudança radical.
Decisões iniciais incompatíveis com a escala actual. Sistema construído como protótipo a aguentar 10 utilizadores não vai responder a milhão.
Equipa actual não consegue manter, e contratar quem consiga é impossível ou desproporcionalmente caro.
Mesmo nestes casos, a abordagem inteligente raramente é "parar tudo e reescrever". É faseada.
Estratégias para reescrever sem parar
Para casos onde rewrite é mesmo necessário, há padrões que reduzem o risco.
Strangler Fig (Martin Fowler). Construir o novo sistema gradualmente em volta do antigo. Para cada parte funcional, redireccionar tráfego para o novo. O antigo encolhe à medida que o novo cresce. Eventualmente, o antigo é removido.
Branch by Abstraction. Introduzir abstracções no código actual que permitam ter as duas implementações em paralelo, e migrar gradualmente.
Feature freeze controlado. Em casos em que se decide pausar features para reescrever, definir tempo máximo curto (semanas, não meses), com critério claro de quando parar.
Incremental delivery. Mesmo dentro do rewrite, entregar valor em iterações curtas. Nunca ter 6 meses entre commits a produção.
O custo invisível de refactoring contínuo (que se evita)
A alternativa ao rewrite é refactoring contínuo. Que tem custo.
Custa tempo de cada sprint. Custa discussões sobre prioridades. Custa explicar a stakeholders que parte do tempo de desenvolvimento vai para coisas que não geram features visíveis.
Por isso muitas equipas adiam. Resultado: dívida técnica acumula. Eventualmente alguém propõe rewrite. O ciclo recomeça.
A disciplina de refactorar enquanto se entrega features é difícil, mas pagar-se em previsibilidade ao longo dos anos. Equipas que mantêm esta disciplina raramente precisam de rewrite.
Sinais de aviso
Frases que tipicamente precedem rewrites mal pensados:
"O código actual está impossível de manter." Quase nunca é verdade. Costuma significar "não temos disciplina para manter".
"Vamos usar a tecnologia X que é melhor." Mudança de tecnologia raramente justifica rewrite por si só.
"Em 6 meses lançamos a v2 e fica tudo melhor." Os 6 meses costumam virar 18.
"Os developers actuais saem se não reescrevermos." Pode ser sinal de problema de equipa, não de código.
Alguma destas frases vale a pena questionar antes de comprometer a empresa com um projecto de 18 meses sem novas features.
Conclusão
Refactoring contínuo é a higiene saudável. Rewrite é a operação invasiva que se evita.
A tentação de "começar de novo" é forte porque o código antigo é desconfortável de ler. Mas o que está naquele código é o conhecimento acumulado de anos a resolver casos reais.
Deitar fora esse conhecimento, em troca de promessa de "tudo melhor", costuma ser mau negócio.
Quase sempre, a resposta é melhorar incrementalmente. Doloroso, lento, mas eficaz.
E quase nunca, mesmo em 2026, fizeram-se rewrites totais de produtos vivos sem se arrepender.
Fontes verificadas
Fontes consultadas em 30 de maio de 2026:
- Joel Spolsky, "Things You Should Never Do, Part I": https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/
- Martin Fowler, "StranglerFigApplication": https://martinfowler.com/bliki/StranglerFigApplication.html
- Martin Fowler, "BranchByAbstraction": https://martinfowler.com/bliki/BranchByAbstraction.html
- ThoughtWorks Technology Radar: https://www.thoughtworks.com/radar
Recursos gratuitos
Se este artigo te foi útil, começa também pelos recursos gratuitos
É a forma mais simples de passar da leitura à experimentação: descarregas um recurso, testas no teu contexto e decides depois se queres aprofundar com o ebook.