Refatoração segura passo a passo: mudar o código sem quebrar o que funciona

Há uma frase que quase todo desenvolvedor já disse ou ouviu diante de um trecho de código intimidador: "isso aqui precisa ser refatorado". Na maioria das vezes, o que vem depois não é refatoração — é uma reescrita apressada que muda comportamento junto com a estrutura, quebra três coisas que ninguém sabia que dependiam daquele trecho, e termina num commit gigante que ninguém consegue revisar. Refatoração de verdade é o oposto disso: uma disciplina cuidadosa de mudar a forma do código sem mudar o que ele faz, em passos tão pequenos que quebrar algo se torna quase impossível.

A distinção não é preciosismo de vocabulário. Ela define se você pode melhorar um sistema em produção com segurança ou se cada limpeza é uma aposta. O código limpo é o destino; a refatoração segura é o caminho — e é justamente o caminho que costuma ser negligenciado. Muita gente sabe reconhecer código ruim e ainda assim não sabe transformá-lo sem risco, porque nunca aprendeu o processo. Este artigo trata do processo: a rede de segurança que vem antes, os passos pequenos e reversíveis, o catálogo de transformações que resolve a maioria dos casos, e por que "jogar tudo fora e reescrever" quase nunca é a resposta que parece ser.

Refatorar é mudar a forma, não o comportamento#

A definição consagrada por Martin Fowler é precisa e vale gravar: refatoração é uma alteração na estrutura interna do software que o torna mais fácil de entender e mais barato de modificar, sem alterar seu comportamento observável. A última parte é o coração de tudo. Se o comportamento muda, não é refatoração — é outra coisa, com outro nível de risco.

Refatorar e adicionar funcionalidade são atividades separadas. Fowler usa a imagem de dois chapéus: o de refatorar e o de programar novas funções. Você usa um de cada vez. Enquanto refatora, não adiciona comportamento; enquanto adiciona comportamento, não refatora. Misturar os dois no mesmo passo é a receita para não saber o que quebrou: se um teste falha depois de uma mudança que mexeu na estrutura e na lógica, você não tem como isolar a causa.

O que refatoração não é. Não é reescrever do zero, não é corrigir um bug, não é otimizar performance, não é trocar de biblioteca. Cada uma dessas atividades muda comportamento observável — o resultado, o desempenho medível, a dependência externa — e por isso carrega riscos que a refatoração pura, por definição, não tem. Chamar tudo de "refatorar" apaga essa fronteira e faz uma mudança arriscada parecer segura. Nomear corretamente já é metade da proteção.

Antes de tocar em nada: a rede de segurança#

A pergunta que torna a refatoração segura é: como você sabe que não mudou o comportamento? A resposta honesta é que você não sabe — a menos que tenha uma forma automática de verificar. Essa forma é a suíte de testes, e ela vem antes de qualquer mudança.

Testes são o que transforma refatoração em ciência. Com uma boa cobertura, cada passo da refatoração termina rodando os testes: se continuam verdes, o comportamento se manteve; se algum fica vermelho, você quebrou algo e sabe exatamente qual foi o passo culpado, porque acabou de dá-lo. Sem testes, refatorar é mexer no escuro e torcer. Os testes não são um acessório do processo — são o que permite ao processo existir.

Código legado sem testes exige testes de caracterização primeiro. E se o código que você precisa refatorar não tem teste nenhum? Aí a primeira tarefa não é refatorar, é escrever testes que capturem o comportamento atual, mesmo que ele esteja errado. Esses testes de caracterização não julgam se o código está certo; eles documentam o que ele faz hoje, para que a refatoração não altere isso sem querer. Você observa a saída para uma entrada, escreve um teste que espera exatamente essa saída, e agora tem uma rede onde antes não havia nenhuma. Só então é seguro começar.

Passos pequenos e reversíveis#

Uma vez com a rede armada, o segredo é o tamanho do passo. A intuição diz para fazer a grande transformação de uma vez; a experiência diz o contrário.

Micro-passos tornam o erro barato. Cada transformação deve ser pequena o bastante para ser óbvia e para ser desfeita sem dor. Renomear uma variável. Extrair três linhas para uma função. Mover um método. Depois de cada um, rode os testes. Se ficarem verdes, siga; se um ficar vermelho, você tem no máximo uma mudança minúscula para desfazer ou entender, não uma reforma inteira para rastrear. O paradoxo é que dar passos menores faz você chegar mais rápido, porque você nunca perde tempo caçando o que quebrou em uma montanha de alterações.

Commit a cada passo verde. O controle de versão é a segunda rede, embaixo da primeira. Fazer um commit pequeno a cada passo que passou nos testes cria uma série de pontos de retorno seguros. Se três passos adiante você perceber que tomou o caminho errado, volta um ou dois commits e recomeça, sem perder o trabalho bom. Um único commit gigante no fim de uma refatoração longa joga fora essa segurança: quando algo dá errado, o único retorno possível é para antes de tudo.

O catálogo que resolve 80% dos casos#

A refatoração tem um vocabulário de transformações nomeadas, mas um punhado delas cobre a esmagadora maioria das situações do dia a dia. Vale conhecê-las pelo nome porque cada uma é um passo pequeno e testável.

Extrair função. O movimento mais comum de todos. Um bloco de código que faz algo identificável — e que muitas vezes você comentaria para explicar — vira uma função com um nome que diz o que ela faz. O comentário some porque o nome o substitui, e o trecho de origem fica mais curto e mais legível. Funções longas encolhem em uma sequência de chamadas que se leem como um resumo.

```javascript // Antes: um bloco que pede um comentário const total = itens.reduce((s, i) => s + i.preco i.qtd, 0); const desconto = total > 500 ? total 0.1 : 0; const frete = total > 300 ? 0 : 25;

// Depois: cada intenção vira um nome const total = calcularSubtotal(itens); const desconto = calcularDesconto(total); const frete = calcularFrete(total); ```

Renomear. Trocar um nome vago por um que revela a intenção é uma das refatorações de maior retorno e menor risco — desde que feita com apoio de ferramenta, que atualiza todas as referências de uma vez. Um d que vira diasDesdeUltimoAcesso elimina a necessidade de decifrar o código toda vez que ele é lido.

Introduzir variável explicativa. Uma expressão complexa dentro de uma condição — várias comparações encadeadas — fica opaca. Extrair partes dela para variáveis com nomes significativos transforma uma linha ilegível em algo que se lê quase como texto, sem mudar o resultado.

Substituir condicional por polimorfismo. Quando o mesmo switch ou cadeia de if sobre um tipo aparece em vários lugares, cada novo caso obriga a caçar e alterar todos eles. Mover cada ramo para um método de uma subclasse (ou para uma estratégia) faz o comportamento seguir o objeto, e adicionar um novo caso passa a ser criar uma nova classe, sem tocar no código existente.

Extrair classe. Quando uma classe acumulou responsabilidades demais — um sinal é ter grupos de campos e métodos que só conversam entre si —, separar esse grupo coeso em uma classe própria melhora a coesão dos dois lados. Cada classe volta a ter um motivo único para mudar.

Code smells: quando o código pede refatoração#

Refatorar sem critério é perder tempo; o gatilho certo é o atrito real. Os "maus cheiros" de código são sinais de que a estrutura está atrapalhando, e eles indicam onde investir a refatoração.

• Função longa demais. Se você precisa rolar a tela ou não consegue segurar a função inteira na cabeça, ela provavelmente esconde várias responsabilidades pedindo para serem extraídas.
• Código duplicado. A mesma lógica em três lugares vai divergir: alguém corrige um e esquece os outros. Duplicação é o convite mais claro para extrair e reusar.
• Nomes que mentem ou não dizem nada. Quando você precisa ler o corpo para entender o que uma variável guarda, o nome falhou.
• Lista de parâmetros enorme. Muitos argumentos costumam significar que eles deveriam viajar juntos em um objeto, ou que a função faz coisas demais.
• Medo de mexer. O cheiro mais revelador de todos: quando uma parte do sistema dá calafrio e todo mundo evita tocá-la, ela concentra dívida e é candidata prioritária — depois de ganhar testes.

O ponto é que refatoração não deveria ser um evento agendado, e sim uma resposta contínua a esses sinais, feita no fluxo do trabalho, na área que você já está mexendo.

Refatorar não é reescrever#

Chegamos ao mito mais caro do ofício. Diante de um sistema confuso, a tentação é declarar bancarrota e reescrever tudo do zero — dessa vez do jeito certo. Essa decisão quase sempre custa mais do que promete.

A reescrita joga fora conhecimento invisível. Aquele código feio acumulou anos de correções para casos extremos que ninguém documentou: o cliente estranho, a regra fiscal específica, o workaround para um bug de um sistema externo. Cada uma dessas esquisitices é um aprendizado pago com um incidente de produção. Reescrever do zero significa reencontrar todos esses casos um a um, na marra, reintroduzindo bugs que já tinham sido resolvidos. O código antigo é feio porque o mundo real é feio.

A reescrita para o mundo enquanto acontece. Enquanto o time refaz o que já existia, o sistema atual não ganha funcionalidade, e o novo passa meses sem entregar valor — durante os quais o antigo ainda precisa ser mantido. Refatoração incremental, ao contrário, melhora o sistema em produção, um passo verde de cada vez, sem nunca deixá-lo fora do ar. Você chega ao mesmo destino, mas por uma estrada que nunca fecha. Reescrita do zero é justificável em casos raros — uma tecnologia base morta, uma mudança de domínio radical —, mas deve ser a exceção examinada com desconfiança, não o reflexo diante de código que dá trabalho de entender.

Fechando#

Refatoração segura é menos sobre saber o que é código bonito e mais sobre dominar o processo que chega lá sem quebrar nada. Comece pela rede: sem testes, não há refatoração, só aposta. Dê passos minúsculos e reversíveis, rode os testes a cada um e faça commit no verde, para que o erro seja sempre barato de desfazer. Use o catálogo — extrair função, renomear, variável explicativa, polimorfismo, extrair classe — como um conjunto de movimentos pequenos e confiáveis, disparados pelos maus cheiros reais do código, não por gosto estético. E resista à sedução da reescrita, que promete um recomeço limpo e cobra em bugs reencontrados e meses parados. O código melhora do mesmo jeito que piorou: uma pequena decisão de cada vez — só que, dessa vez, na direção certa e com a rede armada.