Entendendo a Arquitetura Atual
Antes de refatorar uma unica linha, voce precisa entender profundamente o codigo que vai mudar. Refatorar sem compreender e receita para bugs. O Claude Code le o codebase e explica a arquitetura atual antes de qualquer mudanca.
🎯 Conceito Principal
O principio "read before change" e a fundacao de toda refatoracao segura:
- •Mapeie dependencias: Quais arquivos importam o modulo que voce quer refatorar? Quem depende dele? Mudancas em interfaces afetam todos os consumidores
- •Identifique padroes: O codigo segue algum padrao especifico? Ha convencoes de naming, estrutura ou organizacao que precisam ser mantidas?
- •Verifique testes existentes: Ha testes que cobrem o codigo atual? Se nao, crie-os antes de refatorar — eles sao sua rede de seguranca
💡 Dica Pratica
Peca ao Claude para mapear a arquitetura antes de qualquer mudanca:
Definindo o Objetivo da Refatoracao
Refatoracao sem objetivo claro vira refatoracao infinita. Defina exatamente o que voce quer melhorar: performance? legibilidade? testabilidade? desacoplamento? Sem um alvo claro, voce pode acabar mudando tudo sem melhorar nada.
🎯 Conceito Principal
Um objetivo claro de refatoracao tem tres caracteristicas:
- •Especifico: "Extrair a logica de validacao para um modulo separado" em vez de "melhorar o codigo"
- •Mensuravel: Voce consegue verificar se o objetivo foi alcancado? Menos dependencias? Menos linhas? Mais testes passando?
- •Preservador de comportamento: O comportamento externo deve ser identico. Refatoracao muda a estrutura, nao a funcionalidade
💡 Dica Pratica
Comunique o objetivo de forma explicita:
Refatorando em Commits Pequenos
A regra de ouro da refatoracao: commits pequenos e incrementais. Cada commit deve ser uma mudanca atomica que compila, passa nos testes e pode ser revertida independentemente. Nunca faca uma refatoracao gigante em um unico commit.
🎯 Conceito Principal
Small incremental changes sao a abordagem mais segura:
- •Um passo por vez: Renomeie uma variavel, extraia uma funcao, mova um arquivo — cada mudanca e um commit separado
- •Revertivel: Se algo quebrar, voce pode reverter o ultimo commit sem perder todo o progresso
- •Revisavel: Commits pequenos sao mais faceis de revisar. Um diff de 20 linhas e facil de entender; um de 2000 linhas ninguem le
💡 Dica Pratica
Peca ao Claude para dividir a refatoracao em passos atomicos:
Mantendo Testes Verdes
A cada passo da refatoracao, todos os testes devem continuar passando. Se um teste quebra, ou o teste esta errado (e precisa ser atualizado) ou a refatoracao introduziu uma mudanca de comportamento (e precisa ser corrigida).
🎯 Conceito Principal
Testes verdes apos cada mudanca e inegociavel em refatoracao:
- •Rode apos cada passo: Nao acumule mudancas sem testar. Rode a suite completa apos cada commit atomico
- •Testes que quebram = sinal: Um teste quebrando durante refatoracao indica que voce mudou comportamento. Investigue antes de atualizar o teste
- •Crie testes antes: Se o codigo nao tem cobertura adequada, adicione testes antes de refatorar. Eles sao sua garantia
💡 Dica Pratica
Automatize a verificacao apos cada passo:
Revisando o Diff Completo
Apos completar todos os passos da refatoracao, faca uma revisao final do diff completo. Olhe para todas as mudancas juntas e verifique se o resultado final e coerente, legivel e melhora genuinamente o codigo.
🎯 Conceito Principal
A revisao final verifica o resultado holístico:
- •Visao macro: Cada commit individual faz sentido, mas o conjunto todo melhora o codigo? O resultado final e mais limpo?
- •Consistencia: As convencoes de naming sao consistentes em todo o diff? Ha mistura de estilos?
- •Simplicidade: O codigo refatorado e genuinamente mais simples ou apenas diferente? Complexidade desnecessaria foi removida?
💡 Dica Pratica
Peca ao Claude para fazer uma revisao critica do resultado:
Patterns de Refatoracao Seguros
Existem padroes de refatoracao que sao inerentemente seguros e outros que sao arriscados. Conhecer a diferenca ajuda a escolher as mudancas certas e na ordem certa.
🎯 Conceito Principal
Padroes seguros vs padroes arriscados:
- •Seguros: Rename (variavel, funcao, arquivo), Extract Function, Extract Module, Move File, Inline Variable, Remove Dead Code
- •Moderados: Change Signature, Extract Interface, Replace Conditional with Polymorphism
- •Arriscados: Rewrite from scratch, Change data structures, Merge modules com logicas diferentes
💡 Dica Pratica
Comece sempre pelos padroes seguros e avance gradualmente:
Exercicio Pratico
Refatorar modulo mantendo testes verdes
Escolha um modulo de um projeto seu que precise de melhoria estrutural e aplique o workflow completo de refatoracao.
Mapeie a arquitetura com o Claude
Peca leitura e explicacao do modulo antes de mudar qualquer coisa.
Defina objetivo claro e refatore em commits pequenos
Um passo atomico por commit, testes rodando apos cada um.
Revise o diff final e confirme a melhoria
Verifique que o resultado e genuinamente melhor que o original.
✅ Criterios de Sucesso
📋 Resumo do Modulo
Proximo Modulo:
3.4 - Workflow: Entender Codebase Novo