Reescrever do zero ou refatorar o que já existe: como decidir sem se enganar

Três sintomas e uma pergunta que pula o diagnóstico

A ligação costuma trazer três sintomas na mesma frase: o sistema demora a responder, uma alteração pequena quebra uma tela sem relação aparente e ninguém na equipe atual sabe explicar por que determinada rotina existe. Em seguida vem a pergunta, já com a resposta embutida na formulação: dá para reescrever tudo do zero?

Reescrita completa é a decisão mais cara desse cardápio e a que menos gente examina antes de tomar. Os três sintomas descritos são compatíveis com código mal escrito e igualmente compatíveis com um banco sem o índice correto, com um serviço externo instável ou com uma decisão de infraestrutura tomada anos atrás e nunca revisada. Distinguir esses casos custa duas ou três semanas de auditoria. Confundi-los custa um projeto inteiro, e o dinheiro só volta como aprendizado.

O que uma auditoria de código cobre em duas a três semanas

Quatro frentes sustentam uma auditoria útil. A leitura do código estabelece o que o sistema faz de fato, que nem sempre coincide com o que a documentação descreve nos casos em que ela existe. O mapa de dependências relaciona módulos internos e serviços externos, expondo o que quebra junto quando alguma coisa quebra. O levantamento de risco de segurança, no mesmo escopo da frente de Cibersegurança, identifica biblioteca sem atualização, credencial gravada em código e caminho de acesso desprotegido. O custo de infraestrutura, tratado na frente de Infraestrutura & Cloud, fecha o quadro, porque parte da insatisfação com sistema legado tem origem no que ele custa para rodar, questão independente da qualidade do código que roda nele.

Num sistema de porte médio, esse trabalho leva de duas a três semanas e termina num relatório que separa o que se aproveita, o que precisa ser reescrito e em que ordem fazer isso sem interromper a operação do cliente. A ordem proposta importa mais que o veredito. Um sistema com dez módulos raramente comporta uma decisão binária entre tudo novo e tudo antigo: três ou quatro módulos concentram a maior parte do risco e do custo de manutenção, e são eles que justificam prioridade, enquanto o restante segue em operação por bastante tempo sem alteração nenhuma.

Fim de ciclo de suporte e conhecimento de negócio perdido

Entre os sinais que uma auditoria levanta, um pesa mais que os demais. Quando ninguém na equipe atual entende a regra de negócio embutida no sistema e a tecnologia usada para escrevê-lo está perto do fim do ciclo de suporte, o custo de manter alguém treinado nela sobe ano a ano até ultrapassar o custo de reconstruir. Framework sem correção de segurança publicada há anos, linguagem que já não aparece em formação técnica e fornecedor original que encerrou as atividades são indícios verificáveis desse ponto de virada, e costumam aparecer juntos.

O custo de manter dois sistemas em paralelo

Reescrever tem apelo evidente: código novo, arquitetura atual, débito técnico zerado no primeiro dia. A despesa aparece no intervalo entre a decisão e o corte. Enquanto o sistema novo não entra em operação, alguém mantém o antigo funcionando, o que significa duas equipes ou uma equipe dividida, e cada funcionalidade da versão antiga vira item de uma lista de paridade que precisa ser replicada antes da virada.

Há um custo menos visível nesse período. Correção de bug precisa ser aplicada duas vezes, uma em cada versão, multiplicando o trabalho de manutenção exatamente na fase em que a equipe está sob pressão para entregar a versão nova no prazo prometido. Projeto de virada única que estoura prazo estoura orçamento na mesma proporção, e a causa raramente é técnica: está na dificuldade de estimar quanto tempo leva reconstruir um comportamento que ninguém documentou quando o construiu pela primeira vez.

Refatoração incremental e o risco da indecisão

Refatorar em produção funciona quando existe cobertura de teste suficiente para permitir mudança incremental sem alterar comportamento, ou quando é possível isolar um módulo por vez e substituí-lo sem tocar no resto. O resultado demora mais a ficar visível, já que não existe lançamento único para anunciar, e em troca a operação do cliente não fica parada durante meses seguidos.

O erro mais caro nessa decisão é a indecisão. Equipe que começa a reescrever e continua refatorando o sistema antigo, sem prazo definido para a transição, trava dos dois lados e consome orçamento nos dois. Existe ainda o caso em que a própria auditoria não se paga: quando o sistema já tem data de desligamento definida e o cliente precisa apenas mantê-lo vivo até a substituição, o dinheiro rende mais em suporte mínimo do que em mapear um código que será desligado de qualquer forma.

Um ERP em que a resposta estava na infraestrutura

O case de migração de ERP legado para AWS trata de um ERP de financeiro, fiscal e folha que rodava havia anos num único servidor dentro da rede local, num cliente do setor de estacionamentos. O sintoma relatado tinha cara de problema de aplicação. O risco concreto era outro e mais grave: aquela máquina era ponto único de falha, e se ela parasse, o financeiro parava junto, sem plano alternativo.

A auditoria concluiu que o sistema aplicativo não precisava ser reescrito. O ambiente foi migrado para AWS EC2, preservando a integração com o diretório corporativo e as rotinas fiscais existentes, com a conexão entre a rede corporativa e o novo ambiente garantida por VPN Site-to-Site. A virada aconteceu em janela de manutenção planejada, sem perda de dado fiscal e sem que nenhuma linha de código de negócio fosse alterada.

O ganho veio inteiro da infraestrutura, o que só ficou evidente depois que a auditoria separou o sintoma, que se manifestava na aplicação, da causa, que estava na topologia de rede. Uma reescrita teria consumido meses de equipe para resolver o problema errado, e o ponto único de falha continuaria exatamente onde estava.