O sistema legado come mais tempo a cada trimestre, o time reclama da base de código, e alguém propõe reescrever do zero. A tentação desaparece quando você abre o histórico de estimativa das duas últimas reescritas que acompanhou: fechou entre três e cinco vezes o número inicial.
Quatro dados antes de convocar a reunião
- Cobertura de teste. Com teste confiável, refatorar é mudança controlada. Sem teste, cada alteração é aposta, e aposta não entra em produção de sistema de pagamento.
- Acoplamento externo. Sistema com muita integração, banco e serviço de terceiro é caro de reescrever: cada integração é superfície de erro que precisa ser reimplementada e validada.
- Quem construiu o sistema. Se ninguém que o criou continua na empresa, o conhecimento tácito saiu junto. Reescrever sem ele produz o mesmo sistema com os mesmos erros escritos de outra forma.
- Pressão de negócio. Reescrever entra na conta quando a arquitetura bloqueia mudança que o negócio precisa. Se o bloqueio é gente faltando, contratação resolve antes.
Quando reescrever compensa
A tecnologia-base ficou sem comunidade ou sem suporte. A arquitetura contradiz o produto de hoje: monólito de 2014 contra a fila de eventos de que a operação precisa. Ou o custo de manter o sistema existente já passou o custo de construir outro.
Nesses casos, reescreva por dentro com o padrão Strangler Fig de Martin Fowler ("StranglerFigApplication", martinfowler.com, 2004): você envolve o sistema antigo com camada nova, migra funcionalidade por funcionalidade e mantém o sistema de pé durante a troca.
O time redescobre o que ninguém documentou
Você gasta semanas em três frentes: decisão de design sem registro, edge case guardado na memória de uma pessoa, integração que mudou enquanto o time construía o novo. Cada um desses itens é semana de trabalho que aparece a meio do caminho.
Martin Fowler publicou Refactoring (Addison-Wesley, 2ª ed., 2018) sobre mudar estrutura sem mudar comportamento, caminho de menor risco. Joel Spolsky abriu o caso do Netscape em "Things You Should Never Do, Part I" (2000) e mostrou o preço da reescrita total.
Comece pela restrição desta semana
Escreva o que bloqueia o negócio esta semana e a menor mudança que resolve. Costuma sair: refactor de um módulo, troca de uma dependência, feature que o sistema já suporta e ninguém habilitou. A reescrita entra depois, se os quatro dados continuarem apontando para ela.
Reunir o time para discutir refatorar ou reescrever sem esses quatro dados produz opinião. Com eles, a conversa dura vinte minutos e tem dono.
