"Melhor não mexer, está funcionando." Essa frase, dita com a melhor das intenções, é o atestado de óbito da evolução de um sistema. O código que ninguém ousa tocar não está estável: está refém. E a distância entre "melhor não mexer" e "precisamos reescrever tudo" é menor do que parece.

Refatoração é a alternativa adulta aos dois extremos. E ela tem uma definição precisa, popularizada por Martin Fowler no livro clássico do tema: melhorar a estrutura interna do código sem alterar seu comportamento observável (refactoring.com). A segunda metade da frase é o que separa refatorar de "mexer e torcer".

O medo é racional (e tem cura)

O medo de refatorar vem de uma pergunta sem resposta: "como eu sei que não quebrei nada?". Enquanto a resposta for "testando na mão e rezando", o medo está certo e deve ser respeitado.

A cura, portanto, não é coragem: é rede de proteção. E aqui entra a técnica para código legado descrita por Michael Feathers em Working Effectively with Legacy Code: antes de mudar qualquer coisa, escreva testes de caracterização, testes que capturam o que o código faz hoje (mesmo os comportamentos estranhos), não o que deveria fazer. Eles são a fotografia do estado atual: se a refatoração mudar qualquer comportamento, a fotografia acusa.

O método dos passos pequenos

O ciclo que remove o drama:

1. Garanta a rede: testes cobrindo o comportamento do trecho (os de caracterização, se for legado).
2. Um passo pequeno e nomeado: extrair função, renomear variável, mover responsabilidade. Um passo, não uma reforma.
3. Verde de novo: os testes passam? O comportamento se preservou.
4. Commit. Ponto de salvamento. Deu errado no próximo passo? Volta-se em segundos.
5. Repita. Vinte ciclos desses transformam um monstro em código legível, sem nunca ter ficado quebrado no meio do caminho.

A diferença psicológica é enorme: em vez de uma cirurgia de duas semanas com o sistema aberto na mesa, são dezenas de micro-operações, cada uma reversível, cada uma entregável. A refatoração convive com a esteira normal de entregas, sem branch eterno.

Para mudanças grandes: a estratégia da figueira

Quando a melhoria é estrutural (trocar um módulo inteiro, migrar um padrão), o passo pequeno ganha escala com o padrão Strangler Fig, descrito por Fowler: constrói-se o novo ao redor do velho, redirecionando fluxo aos poucos, como a figueira que envolve a árvore hospedeira (StranglerFigApplication).

Na prática: a rota nova atende primeiro 5% do tráfego, depois 20%, depois tudo, e só então o código velho morre, sem big bang, com rollback trivial a cada etapa. É o mesmo princípio de extrair serviços com evidência.

Quando refatorar (e quando não)

Refatore quando o código está no caminho do trabalho: antes de adicionar a feature naquele módulo, limpe o terreno (a regra de pagar a dívida onde se trabalha). A sequência de Kent Beck resume: "make the change easy, then make the easy change": primeiro torne a mudança fácil, depois faça a mudança fácil.

Não refatore:

• Código estável que ninguém toca e nenhuma roadmap alcança. Estética sem retorno.
• No meio de uma feature atrasada. Refatoração de pânico mistura mudança de estrutura com mudança de comportamento, o pecado capital do ofício.
• Sem rede de testes, "rapidinho". É exatamente assim que "melhorar o código" vira incidente.

A regra de ouro: nunca misture

Um commit refatora ou muda comportamento, nunca os dois. Quando a revisão olha um diff que mistura renomeações com lógica nova, ela não consegue verificar nada. Separado, cada parte é trivial de revisar, e o PR flui.

Do "melhor não mexer" ao código que evolui

Instalar essa mecânica num time (redes de caracterização, ciclos curtos, strangler para as grandes) é o coração do nosso serviço de Manutenção e Evolução: o sistema melhora todo mês, sem parar de entregar, sem sustos.

Qual módulo do seu sistema é o "melhor não mexer"? Conte para a IA da Rabelo Digital, aqui no canto da tela, e ela sugere a primeira rede de proteção. Sem formulário, sem espera.

---

Leia também

• Reescrever ou evoluir? Como decidir
• Débito técnico: como medir e quando pagar