Em algum momento da vida de todo sistema que deu certo, alguém diz numa reunião que não tem mais salvação e que o melhor é começar do zero.
A ideia costuma ganhar força com quem ainda não viveu todas as exceções daquele sistema. Muitas vezes está errada. Às vezes é a única decisão responsável. A diferença entre os dois casos vale muito dinheiro.
Por que reescrever seduz
O sistema atual é conhecido em todos os seus defeitos. O sistema novo ainda não tem nenhum. A comparação é entre uma coisa real e uma imaginada, e a imaginada ganha todas as vezes.
Há também um erro de leitura muito comum. Código feio não é prova suficiente de incompetência. Boa parte daquelas condições estranhas, exceções e remendos pode ser o registro sedimentado de casos reais que apareceram na operação ao longo dos anos: o cliente que tem dois CNPJs, o mês em que a regra fiscal mudou, o relatório que precisa fechar de um jeito específico porque o contador exige. Quando ninguém documentou essas decisões, o código pode ser o último lugar onde elas ainda existem.
Reescrever do zero é jogar fora esse registro e apostar que você vai redescobrir tudo, em produção, com o cliente reclamando.
E há o custo que ninguém coloca na conta: durante a reescrita você opera dois sistemas. O antigo não pode parar de evoluir, porque o negócio não para. Cada nova regra precisa ser feita duas vezes. É por isso que reescritas atrasam de forma tão característica: elas perseguem um alvo que se move.
Os sinais que realmente justificam reescrever
São poucos, e nenhum deles é "o código é ruim".
O modelo de dados está errado na raiz. Código se refatora aos poucos; modelo de dados errado contamina tudo o que encosta nele. Se a estrutura fundamental representa mal o negócio, cada funcionalidade nova custa mais que a anterior, e nenhuma limpeza de código resolve. É o caso da entidade que deveria existir e não existe, ou de duas coisas diferentes que foram fundidas numa só.
A plataforma chegou ao fim. Linguagem ou framework sem atualização de segurança, dependência central abandonada, servidor que ninguém mais consegue reproduzir. Aqui não é uma escolha de engenharia, é prazo de validade.
O custo de mudança continua subindo. Este é um dos sinais mais objetivos: pegue uma mesma classe de alteração, dessas que aparecem toda hora, e compare esforço, risco e quantidade de áreas afetadas ao longo dos últimos meses. Num sistema saudável, o time aprende e torna mudanças recorrentes mais previsíveis. Quando alterações equivalentes ficam mais caras mesmo para quem conhece o sistema, existe um problema estrutural a investigar.
Ninguém consegue rodar o sistema fora de produção. Se não existe um ambiente onde dá para errar, não existe conserto seguro. Ou você cria esse ambiente, ou está tudo bem em admitir que não vai dar.
Os sinais que dizem para estabilizar
Também são reconhecíveis. O sistema não tem testes, mas o modelo de dados faz sentido. É lento, mas está correto. Dá medo mexer, e esse medo se concentra em duas ou três áreas conhecidas, não no sistema inteiro. A documentação não existe, mas ainda há alguém que sabe.
Em todos esses casos o problema é de confiança, não de fundação. E confiança se reconstrói numa ordem específica.
A ordem certa de estabilizar
Quase todo resgate malfeito começa mexendo no código. A ordem que funciona é outra.
Primeiro, enxergar. Registro de erros, métricas, alertas. Antes de qualquer mudança, é preciso saber o que está acontecendo hoje, inclusive os problemas que já existem e ninguém reporta. Sem isso, você não vai saber se a sua alteração melhorou ou piorou as coisas.
Segundo, poder voltar atrás. Publicação automatizada e reversão em minutos. Um sistema em que subir uma alteração é um evento arriscado é um sistema em que ninguém vai querer arriscar, e ele congela por medo.
Terceiro, cercar antes de mexer. Testes só ao redor da parte que você vai alterar, não no sistema inteiro. Cobertura total de um sistema legado é um projeto que nunca termina; cobertura da vizinhança de uma mudança é trabalho de dias e devolve a coragem de mexer.
Só então, alterar. Nessa altura, o que parecia um sistema condenado costuma parecer apenas um sistema mal cuidado.
O terceiro caminho, que é o mais honesto
Na maior parte dos casos difíceis, a resposta certa não é nenhuma das duas.
Você constrói o novo em volta do antigo e vai migrando por função. A primeira funcionalidade nova nasce fora do sistema velho, conversando com ele. Depois a segunda. Aos poucos o antigo vai perdendo responsabilidades até virar uma casca, e um dia ele é desligado sem cerimônia.
É mais lento de anunciar e mais rápido de entregar valor, porque cada etapa vai para produção sozinha. Não tem o dia do grande lançamento, que é justamente o dia em que as reescritas fracassam. E preserva a opção de parar no meio: se depois de três funções migradas o resto do sistema antigo estiver funcionando bem, está tudo bem deixá-lo lá.
Como a gente aborda isso
Quando um produto existente chega até nós, o primeiro passo não é propor uma reescrita. É entender por que ele parou de evoluir, onde está o custo de mudança e o que vale preservar.
Às vezes a melhor recomendação é estabilizar antes de construir algo novo. É bem mais barato descobrir isso no começo do que no meio de uma reescrita longa.