Refatoração

Refatoração é melhorar a estrutura interna do código sem mudar seu comportamento externo.

Essa definição tem duas partes críticas:

Melhorar a estrutura: Tornar o código mais fácil de entender, modificar ou estender. Isso inclui nomes melhores, funções menores, organização mais clara, menos duplicação.

Sem mudar o comportamento: O código faz exatamente o que fazia antes. Entradas produzem as mesmas saídas. Efeitos colaterais são idênticos. Os testes ainda passam.

Refatoração não é:

• Reescrever do zero
• Adicionar funcionalidades
• Corrigir bugs
• Otimização de desempenho (geralmente)

Se você está mudando o que o código faz, você não está refatorando—está fazendo outra coisa. Refatoração é especificamente sobre estrutura, não comportamento.

Martin Fowler documentou dezenas de refatorações específicas, cada uma com:

• Um nome (para que as equipes possam se comunicar)
• Uma motivação (quando usá-la)
• Mecânica (passo a passo de como fazer com segurança)

Aqui estão algumas que você usará constantemente:

Extrair Função: Pegue um trecho de código e coloque-o em uma nova função com um nome claro. Esta é provavelmente a refatoração mais comum.

Renomear: Mude o nome de uma variável, função ou classe para expressar melhor seu propósito. Bons nomes são surpreendentemente importantes.

Incorporar Função: O oposto de extrair—substitua uma chamada de função pelo seu corpo. Use quando uma função não adiciona clareza.

Extrair Variável: Pegue uma expressão complexa e dê um nome a ela atribuindo-a a uma variável.

Mover Função: Mova uma função para uma classe onde ela faz mais sentido.

Substituir Condicional por Polimorfismo: Substitua instruções if/else ou switch complexas por despacho orientado a objetos.

Essas não são refatorações "avançadas". São ferramentas do dia a dia. Aprenda-as até que se tornem automáticas.

Refatoração só é segura quando você tem testes. Sem testes, cada mudança pode quebrar algo, e você não saberá até a produção.

O processo de segurança:

1. Garanta que os testes passem antes de começar
2. Faça uma pequena mudança
3. Execute os testes
4. Se os testes passarem, continue; se falharem, reverta imediatamente
5. Repita

Passos pequenos são fundamentais. Não tente refatorar cinco coisas de uma vez. Extraia uma função, execute os testes, faça commit. Renomeie uma variável, execute os testes, faça commit. Dessa forma, se algo quebrar, você sabe exatamente o que causou.

IDEs modernas têm refatorações automatizadas que são mais seguras que mudanças manuais. "Renomear" na sua IDE atualiza todas as referências. "Extrair Função" cria a função e atualiza o local de chamada. Use essas ferramentas.

A Regra do Escoteiro: Deixe o código melhor do que você o encontrou. Quando você tocar no código por qualquer motivo, faça uma pequena melhoria. Com o tempo, a base de código fica mais limpa em vez de mais suja.

Refatore constantemente. Refatoração não é uma fase ou sprint separada. É contínua.

Gatilhos específicos para refatorar:

Antes de adicionar uma funcionalidade: Se a estrutura atual torna a funcionalidade difícil de adicionar, refatore primeiro. Torne a mudança fácil, depois faça a mudança fácil.

Depois de fazer um teste passar: Este é o "refatorar" em vermelho-verde-refatorar. Limpe antes de passar para o próximo teste.

Quando você perceber um code smell: Código duplicado, métodos longos, nomes pouco claros, condicionais complexas—esses são sinais de que refatoração é necessária.

Durante revisão de código: Se você vê algo que melhoraria, faça ou anote para depois.

Quando você tem tempo: Tenha um "backlog de refatoração" de problemas conhecidos. Quando você tiver folga, pegue algo da lista.

Não refatore quando:

• Você não tem testes
• Você está prestes a entregar (estabilize, não mude)
• Você não entende o que o código faz (entenda primeiro)

Débito técnico é o custo acumulado de tomar atalhos. Toda vez que você diz "vou limpar isso depois" e não faz, você adiciona débito. Toda vez que você copia e cola em vez de extrair, você adiciona débito.

Débito acumula juros. Código bagunçado leva mais tempo para mudar. Bugs se escondem na complexidade. Novos membros da equipe lutam para entender. O custo da mudança aumenta.

Refatoração é como você paga o débito. Refatoração regular mantém o débito gerenciável. Negligenciar a refatoração deixa o débito se acumular até que a base de código se torne impraticável.

A percepção chave: Refatoração não é um luxo. É manutenção essencial. Você não pede permissão para pagar o débito—você simplesmente faz isso como parte do seu trabalho.

XP incorpora refatoração no processo. Cada funcionalidade, cada correção de bug, cada tarefa inclui tempo para deixar o código melhor do que você o encontrou. Você não precisa de uma "sprint de refatoração"—você precisa de um hábito de refatoração.