MODULO 3.3

👾 Refatorar Codigo

Workflow seguro para refatorar codigo existente sem quebrar funcionalidades, usando o Claude como parceiro de refatoracao.

6
Topicos
20
Minutos
Inter.
Nivel
Pratico
Tipo
1

🏗️ Entender a Arquitetura

Antes de refatorar, o Claude precisa entender a arquitetura atual para nao quebrar dependencias ou alterar comportamentos.

💡 Conceito Principal

Peca ao Claude para mapear o codigo antes de mudar qualquer coisa:

  • •"Analise src/services/payment.js. Quais funcoes ele exporta e quem as importa?"
  • •"Mapeie todas as dependencias do modulo de autenticacao"
  • •O Claude usa grep e leitura de arquivos para criar um mapa mental do codigo

⚡ Dica Pratica

Peca um diagnostico primeiro: "Antes de refatorar, identifique os code smells e problemas de arquitetura neste modulo"

2

🎯 Definir o Objetivo

Defina claramente o que voce quer melhorar e quais restricoes existem. Refatoracao sem objetivo claro vira reescrita desnecessaria.

💡 Conceito Principal

Seja especifico no objetivo da refatoracao:

  • •"Extraia a logica de validacao para um modulo separado mantendo a mesma API publica"
  • •"Converta os callbacks para async/await sem mudar o comportamento externo"
  • •Especifique restricoes: "Nao mude a interface publica" ou "Mantenha compatibilidade com v2"

⚡ Dica Pratica

Use Plan Mode: "[Plan Mode] Quero refatorar o PaymentService. Proponha um plano que melhore testabilidade sem mudar a API"

3

👁️ Revisar o Diff

Apos o Claude fazer as mudancas, revise cada diff cuidadosamente. Em refatoracao, um detalhe errado pode causar bugs sutis.

💡 Conceito Principal

O Claude mostra diffs antes de aplicar. Fique atento a:

  • •Mudancas de comportamento nao intencionais (ex: ordem de execucao alterada)
  • •Imports removidos que ainda sao necessarios em outros lugares
  • •Peca: "Me mostre o git diff completo antes de eu aceitar"

⚡ Dica Pratica

Se o diff for grande, peca um resumo: "Resuma as mudancas que voce fez e quais arquivos foram afetados"

4

🧪 Rodar Testes

Testes sao a rede de seguranca da refatoracao. Rode todos os testes apos cada mudanca para garantir que nada quebrou.

💡 Conceito Principal

Testes antes e depois da refatoracao:

  • •"Rode todos os testes e me mostre quais passam e quais falham"
  • •Se nao tem testes, peca: "Escreva testes para o comportamento atual antes de refatorar"
  • •Apos refatorar: "Rode os testes novamente. Os mesmos testes devem continuar passando"

⚡ Dica Pratica

Regra de ouro: "Sem testes = sem refatoracao. Primeiro escreva testes, depois refatore". Isso e valido tanto para humanos quanto para IA.

5

📦 Commit Incremental

Faca commits incrementais durante a refatoracao para ter pontos de retorno seguros caso algo de errado.

💡 Conceito Principal

Commits pequenos facilitam reverter se necessario:

  • •/commit apos cada etapa da refatoracao
  • •Ex: refactor: extract validation logic to separate module
  • •Se algo quebrar, e facil fazer git revert do ultimo commit

⚡ Dica Pratica

Peca ao Claude: "Faca commit apos cada etapa da refatoracao com mensagens descritivas". Assim voce tem um historico limpo.

6

📚 Boas Praticas

Siga estas boas praticas de refatoracao para maximizar a qualidade e minimizar riscos.

💡 Conceito Principal

Principios para refatoracao eficiente com Claude Code:

  • •Nunca refatore e adicione features ao mesmo tempo - sao commits separados
  • •Use "Refatore para melhorar X, mas mantenha o comportamento identico"
  • •Peca code review apos refatorar: /review para validar as mudancas

⚡ Dica Pratica

Para refatoracoes grandes, use a estrategia "strangler fig": "Crie o novo modulo em paralelo, migre os callers um por um, e depois remova o antigo"

📋 Resumo do Modulo

✓
Arquitetura - Mapeie dependencias antes de mexer
✓
Objetivo - Defina exatamente o que quer melhorar
✓
Diff - Revise cada mudanca com cuidado
✓
Testes - Rode antes e depois de cada etapa
✓
Commits - Incremental para facilitar rollback
✓
Boas Praticas - Separe refatoracao de features

Proximo Modulo:

3.4 - Entender um Codebase Novo

← Voltar Proximo Modulo →