Refatoração: melhore o código sem mudar o que ele faz

Refatoração é a prática de reestruturar código existente para que ele fique mais fácil de ler, mudar e testar, sem mudar o que o software faz para os usuários. Você faz isso em passos pequenos, com uma rede de segurança, enquanto o produto continua rodando.

Sou um engenheiro brasileiro que passou sete anos, desde 2019, construindo e mantendo produtos web e mobile em uso, e o padrão que mais vejo é este: ou o time nunca refatora até tudo ficar doloroso, ou tenta consertar tudo de uma vez e quebra coisas. Este guia trata do caminho do meio.

O que é refatoração?

O termo foi popularizado pelo livro Refactoring, de Martin Fowler. A ideia central é simples: uma refatoração é uma pequena transformação que preserva o comportamento observável. Renomear uma variável. Extrair um bloco de código para uma função. Mover uma função para o módulo ao qual ela pertence. Trocar uma condicional aninhada por uma lógica mais clara.

Cada uma dessas mudanças deixa o produto fazendo exatamente o que fazia antes. Um cliente navegando pelo app não nota diferença. O próximo desenvolvedor nota.

O que refatoração não é

• Não é correção de bug. Corrigir um bug muda o comportamento, de propósito.
• Não é funcionalidade nova. Pelo mesmo motivo.
• Não é projeto de performance. Otimizar pode mudar tempos e uso de recursos, então trate isso como uma tarefa à parte.
• Não é atualização de dependência nem migração de framework. Essas mudanças muitas vezes exigem refatoração antes, mas são mudanças separadas.

Qual a diferença entre refatorar e reescrever?

A refatoração mantém o sistema existente e o melhora em passos pequenos e publicáveis. A reescrita constrói um sistema novo e faz a troca depois. Ambas podem consertar uma base de código bagunçada, mas os perfis de risco são muito diferentes.

A linha do comportamento oculto é a parte que os fundadores subestimam. Código antigo costuma guardar anos de decisões silenciosas: um caso de borda para um cliente, uma regra de pagamento adicionada depois de um incidente. Uma reescrita precisa redescobrir tudo isso. A refatoração mantém tudo intacto enquanto você limpa ao redor.

Quando o problema é maior que a estrutura do código, como uma stack em fim de vida, só refatorar não basta. Aí o caminho mais seguro costuma ser uma migração incremental, em que você coloca um switch na frente do sistema antigo e move o tráfego peça por peça, em vez de uma reescrita big-bang. Foi assim que conduzi a migração de uma plataforma de candidaturas a vagas, em produção, de uma stack legada para uma nova, enquanto as pessoas continuavam usando o sistema todos os dias.

Quando a refatoração vale o tempo e quando não vale?

Refatoração é um investimento e, como qualquer investimento, só se paga se você usar o resultado. Minha regra prática: refatore o código que você vai mexer de novo em breve.

Geralmente vale a pena quando

• Você está prestes a adicionar uma funcionalidade numa área difícil de entender. Limpe primeiro, depois construa.
• A mesma parte do código gera bug atrás de bug.
• Mudanças simples demoram muito mais do que deveriam por causa de lógica emaranhada.
• Desenvolvedores novos sempre empacam nos mesmos arquivos.
• Você quer adicionar testes a um código que hoje é impossível de testar.

Geralmente não vale a pena quando

• O código é feio, mas estável, e ninguém precisa mudá-lo. Deixe como está.
• A funcionalidade está prestes a ser removida ou substituída.
• Você não tem como verificar o comportamento nem tempo para montar essa rede de segurança. Refatorar às cegas é aposta.
• O objetivo é puramente estético, como seguir uma preferência de estilo.

A pergunta que eu faço é: o que vai ficar mais fácil no mês que vem por causa dessa mudança? Se não consigo responder em uma frase, eu pulo.

O que torna a refatoração segura: testes, passos pequenos e reviews?

Refatoração segura se apoia em três hábitos. Eles funcionam juntos, e abrir mão de um enfraquece os outros.

1. Testes que fixam o comportamento atual

Você precisa de um jeito de saber que o comportamento não mudou. Se o código já tem bons testes automatizados, rode-os depois de cada passo. Se não tem, escreva primeiro testes de caracterização: testes que registram o que o código faz hoje, mesmo que esse comportamento seja estranho. Eles não dizem o que é correto. Eles são um alarme.

Priorize os fluxos de dinheiro: checkout, cobrança, cadastro, qualquer coisa em que uma mudança silenciosa custe dinheiro ou confiança de verdade. Como trabalhei no time de carrinho e checkout da Total Wine & More, sempre começo por aí. Se testes automatizados ainda não são realistas, um checklist manual curto para esses fluxos é melhor do que nada.

2. Passos pequenos, cada um publicável

Faça uma mudança, rode as verificações, faça o commit. Depois a próxima. Um bom passo de refatoração é pequeno o bastante para ser descrito em uma linha e, se algo quebrar, você consegue reverter sem perder um dia de trabalho.

Para mudanças maiores, coloque o novo caminho atrás de uma feature flag ou mantenha a função antiga ao lado da nova até confiar nela. Assim você volta atrás rápido em vez de depurar sob pressão.

3. Review que separa estrutura de comportamento

Mantenha commits e pull requests de refatoração separados do trabalho de funcionalidades. Assim o revisor pode fazer uma única pergunta: esta mudança mexe só na estrutura? Revisar um pull request misturado é muito mais difícil, e os bugs se escondem na mistura.

Nos meus projetos em TypeScript eu me apoio nas ferramentas: refatorações do editor (renomear, extrair, mover), linters e um compilador estrito são mais confiáveis do que editar à mão.

Quais refatorações se pagam primeiro num produto em crescimento?

Você não precisa de técnicas exóticas. Nos produtos em que trabalhei, um punhado de movimentos básicos entregou a maior parte do valor.

1. Dê nomes honestos. Uma função chamada process que na verdade valida e cobra um cartão é uma armadilha. Bons nomes são a documentação mais barata.
2. Divida funções e componentes enormes. Uma única função de 500 linhas é difícil de testar e difícil de mudar. Extraia partes com nome e uma única responsabilidade cada.
3. Remova duplicação quando ela é real. Se a mesma regra de negócio vive em três lugares, uma mudança vai acabar esquecendo um deles. Não junte código que só parece igual por coincidência.
4. Isole dependências externas. Coloque provedores de pagamento, serviços de email e APIs de terceiros atrás de um wrapper fino seu. Isso facilita os testes e barateia trocas futuras.
5. Apague código morto. Código sem uso custa tempo de leitura e esconde a lógica real. O controle de versão lembra dele se você precisar de volta.
6. Tire as regras de negócio da UI e das queries do banco. Regras num lugar claro são mais fáceis de testar e mudar.

Repare que nenhuma delas exige um framework novo ou um grande plano. Elas também constroem a base para movimentos maiores depois. Na Inovaula eu construí a v2 da plataforma web e depois liderei o time, que chegou ao fluxo de entrega mais estável que já tinha tido; na minha experiência, hábitos pequenos e consistentes como esses tornam esse tipo de previsibilidade mais fácil de alcançar.

Como encaixar a refatoração no cronograma de entregas?

A abordagem que funciona melhor não é uma sprint dedicada à refatoração. Essas são cortadas na primeira vez que um prazo escorrega. Em vez disso, faça da refatoração parte de como as funcionalidades são construídas.

• Prepare, depois mude. Antes de adicionar uma funcionalidade, gaste um pouco de tempo deixando a área mais fácil de mudar. Depois adicione a funcionalidade. Inclua as duas coisas na estimativa.
• Deixe um pouco mais limpo. Quando mexer num arquivo por qualquer motivo, faça uma pequena melhoria por perto. Isso se acumula sem precisar de projeto.
• Mantenha uma lista curta. Anote as áreas problemáticas conforme as encontrar, com uma nota sobre por que doem. Quando algo virar um bloqueio, você já terá as evidências.
• Limite o tempo dos esforços maiores. Se uma área precisa de uma reestruturação de verdade, combine um limite antes, entregue em fatias e pare quando o limite for atingido.
• Explique em termos de negócio. Ligue cada esforço a um resultado: menos incidentes no checkout, onboarding mais rápido de novos desenvolvedores ou menos risco antes de um lançamento.

Quando um time que lidero está sob forte pressão de prazo, eu ainda protejo duas coisas: testes nos fluxos de dinheiro e pequenas refatorações dentro do trabalho de funcionalidades. Limpezas maiores podem esperar uma janela mais calma.

Se a base de código é herdada e você ainda não sabe o que é arriscado, faça uma auditoria antes de refatorar qualquer coisa. Quando assumo uma base de código, sigo esta ordem: primeiro os acessos, depois o build, depois os fluxos de dinheiro, depois os riscos. Só então escolho os alvos.

Quer uma segunda opinião sobre sua base de código?

Se você está decidindo o que refatorar no seu produto, ou se ele precisa de mais do que refatoração, mande um email para me@filipeeduardo.dev com uma breve descrição da situação. Terei prazer em dar uma olhada e dizer o que eu verificaria primeiro.