| name | refactor-safely |
| description | Use ao refatorar código legado, extrair um serviço ou fazer mudanças que preservam comportamento. Aciona com 'refactor', 'legacy code', 'strangler fig', 'characterization test', 'mikado method'. |
Refatorar com segurança
Quando invocar
- Ao trabalhar em código sem testes suficientes.
- Ao dividir um monólito / extrair um serviço.
- Quando uma mudança é "uma linha", mas toca um caminho assustador.
Primeira regra
Refatoração preserva comportamento. Se você não consegue provar que o comportamento foi preservado, não é refatoração - é reescrita. Coloque testes de caracterização em prática primeiro.
O workflow
- Caracterize - escreva testes que fixem o comportamento atual, incluindo peculiaridades. Não corrija bugs ainda; o objetivo é uma rede de segurança, não correção.
- Passos pequenos e reversíveis - uma transformação que preserva comportamento por vez. Faça commit entre cada uma.
- Mantenha verde - execute testes após cada passo. Reverta imediatamente se ficar vermelho e você não souber por quê.
- Separe commits de refatoração de commits de mudança de comportamento - revisores conseguem focar, o bisect continua útil.
- Integre com frequência - branches de refatoração de vida longa apodrecem.
Padrões
Strangler Fig (para sistemas)
- Coloque uma façade (proxy, router, feature flag) na frente do sistema antigo.
- Direcione uma fatia fina de tráfego para a nova implementação.
- Faça a nova implementação crescer fatia por fatia; reduza a antiga.
- Apague a antiga quando seu tráfego chegar a zero.
Mikado Method (para código)
- Escreva o objetivo.
- Tente de forma ingênua; anote o que quebra como pré-requisitos.
- Reverta. Ataque primeiro um pré-requisito. Faça recursão.
- As folhas são concluídas primeiro; o objetivo original cai por último.
Branch by Abstraction
Introduza uma interface, migre chamadores para ela, troque implementações e aposente a antiga - tudo sem uma branch de vida longa.
Testes de caracterização - como
- Execute o código com entradas representativas, registre a saída (golden files / snapshot tests).
- Prefira observar de fora (HTTP, CLI, estado do DB) - resiliente a refatoração interna.
- Cubra também os casos estranhos; são eles que quebram.
- Aceite que alguns comportamentos são bugs que você agora está fixando - marque-os, corrija depois que a rede de segurança existir.
Antipadrões
- PRs de "refactor" que também corrigem bugs, mudam APIs e renomeiam arquivos - impossíveis de revisar, impossíveis de reverter.
- Reescrita big-bang sem entrega por meses.
- Deletar código antigo antes que o novo código atenda 100% do tráfego.
- Refatorar sem testes, confiando em verificação manual de caminho feliz.
Referências
