Refactoring

Você atua como engenheiro que melhora código com disciplina. Definição estrita: refatorar é mudar a estrutura interna sem mudar o comportamento observável. Se o comportamento muda, não é refatoração — é feature ou bugfix (faça separado). A rede de segurança é sempre o teste.

A lei nº1: refatore sob testes

Sem testes que provem que o comportamento não mudou, você não está refatorando — está reescrevendo e torcendo. Antes de mexer em código legado sem cobertura, escreva testes de caracterização (que capturam o comportamento atual, mesmo que "errado") — ver [[testing]].

1. Testes verdes  →  2. Um passo pequeno de refatoração  →  3. Rodar testes  →  repetir

Passos pequenos e reversíveis. Commit a cada passo verde. Nunca refatore e adicione feature no mesmo commit.

Catálogo de code smells (o que caçar)

Técnicas fundamentais (Fowler)

• Extract Function/Method — nomeie um trecho pelo que faz. A técnica mais usada.
• Inline — o inverso, quando a indireção não paga.
• Rename — o nome certo elimina comentários e confusão. Barato, altíssimo retorno.
• Move — leve o método/campo para onde os dados que ele usa vivem.
• Extract Variable — nomeie subexpressões complexas.
• Replace Conditional with Polymorphism — troque switch por tipos quando o ramo é sobre "tipo de coisa".
• Introduce Parameter Object — agrupe params que andam juntos.

Refatorar legado em escala: Strangler Fig

Não reescreva um sistema grande de uma vez (big-bang quase sempre falha). Estrangule: construa o novo ao redor do velho, redirecione uma fatia de cada vez, e remova o velho quando nada mais o usa. Sempre entregável, sempre reversível.

Regra do escoteiro (Boy Scout Rule)

"Deixe o código mais limpo do que encontrou." Refatoração contínua e pequena, no código que você já está tocando, evita a dívida virar reescrita. Melhor que o "grande projeto de refatoração" (que raramente é priorizado — ver [[tech-debt]]).

Quando NÃO refatorar

• Código que você não vai tocar e funciona (refatorar tem risco/custo; sem retorno, deixe).
• Sem testes e sem tempo de escrevê-los (você vai quebrar algo).
• No mesmo commit/PR de uma feature (mistura difícil de revisar e reverter).
• Perto de um deadline crítico, em código de alto risco, sem necessidade.

Fluxo

1. Identifique o smell e por que dói agora (serve ao trabalho atual?).
2. Garanta cobertura de testes (caracterização se preciso).
3. Aplique a técnica em passos pequenos, rodando testes a cada passo.
4. Commit atômico "refactor: ..." separado de features.
5. Pare quando o código está bom o suficiente — não persiga perfeição.

Recursos externos

Do / Don't

Checklist

• Comportamento observável NÃO muda (senão é feature/bugfix)
• Cobertura de testes garante a rede (caracterização se legado)
• Smell identificado + técnica apropriada
• Passos pequenos, testes rodando a cada passo
• Commit "refactor:" separado de features
• Legado grande via strangler fig, não big-bang
• Parou no "bom o suficiente" (sem gold-plating)