📋 Plano de Aula - Refatoração Segura em Java
📑 Identificação
| Campo | Informação |
|---|---|
| Disciplina | Desenvolvimento de Sistemas II |
| Professor | Ricardo Pires |
| Turma | 3º Técnico DS |
| Data | 23/03/2026 |
| Duração | 105 minutos |
| Aula | 03/06 |
🎯 Objetivos de Aprendizagem
Geral:
Desenvolver competências para aplicar técnicas de refatoração segura em código Java, melhorando design interno sem alterar comportamento externo, reduzindo dívida técnica e aumentando manutenibilidade.
Específicos:
-
Conhecimento (Saber):
- Compreender conceito e importância da refatoração
- Identificar sinais que indicam necessidade de refatoração
- Conhecer técnicas fundamentais: Extract Method, Decompose Conditional, Remove Duplication
-
Habilidades (Saber Fazer):
- Aplicar Extract Method para decompor métodos longos
- Simplificar condicionais complexas com Guard Clauses
- Executar refatoração preservando comportamento original
- Validar refatoração através de testes automatizados
-
Atitudes (Saber Ser):
- Valorizar qualidade interna do código além de funcionalidade
- Desenvolver disciplina de refatoração contínua
- Cultivar responsabilidade pela manutenibilidade a longo prazo
📚 Conteúdo Programático
1. Conceitos de Refatoração (20 min)
- Definição: melhorar design interno preservando comportamento
- Diferença entre refatoração e reescrita de código
- Importância da cobertura de testes automatizados
- Quando refatorar e quando não refatorar
2. Sinais de Necessidade de Refatoração (15 min)
- Métodos longos com múltiplas responsabilidades
- Condicionais aninhadas complexas
- Duplicação de código entre classes/métodos
- Nomes confusos que não expressam intenção
3. Técnica Extract Method (25 min)
- Live coding: decomposição de método longo
- Identificação de pontos de extração
- Nomenclatura expressiva para métodos extraídos
- Validação através de testes que comportamento foi preservado
4. Técnica Decompose Conditional (15 min)
- Simplificação de condicionais aninhadas
- Guard Clauses para early return
- Extração de condições para métodos com nomes expressivos
5. Prática Orientada (30 min)
- Exercício 1: Extract Method em código real
- Exercício 2: Simplificação de condicionais
- Code review: validação de que comportamento foi preservado
⏱️ Cronograma Detalhado
| Tempo | Duração | Atividade | Metodologia | Recursos |
|---|---|---|---|---|
| 19h00-19h20 | 20 min | Conceitos de refatoração + importância | Expositiva dialogada | Slides, exemplos reais |
| 19h20-19h35 | 15 min | Sinais de código que precisa refatoração | Demonstrativa | IDE, código problemático |
| 19h35-20h00 | 25 min | Live coding: Extract Method | Demonstrativa | IDE, projetor, testes |
| 20h00-20h15 | 15 min | INTERVALO | - | - |
| 20h15-20h30 | 15 min | Decompose Conditional + Guard Clauses | Demonstrativa | IDE, comparações |
| 20h30-20h50 | 20 min | Exercício 1: Extract Method | Prática individual | Computadores |
| 20h50-21h05 | 15 min | Exercício 2: Simplificar condicionais | Prática individual | Computadores |
| 21h05-21h15 | 10 min | Code review e síntese | Colaborativa | Projetor |
🎯 Estratégias Metodológicas
Red-Green-Refactor (45 min):
- Red: Identificar código problemático com testes que detectam comportamento
- Green: Garantir que testes passam antes da refatoração
- Refactor: Aplicar técnicas preservando comportamento (testes continuam passando)
Live Coding Demonstrativo (40 min):
- Código real problemático com múltiplas responsabilidades
- Refatoração passo-a-passo com validação contínua via testes
- Comparação before/after mostrando benefícios tangíveis
Prática Reflexiva (20 min):
- Exercícios progressivos de identificação → refatoração → validação
- Code review colaborativo das soluções propostas
- Discussão crítica sobre quando refatorar vs quando não refatorar
🛠️ Recursos Didáticos
Tecnológicos:
- Computadores com ambiente Java + IDE configurado
- JUnit 5 para validação de comportamento preservado
- Projetor para demonstrações live coding
- Acesso aos códigos problemáticos preparados
Materiais:
- Código legacy com problemas reais de manutenibilidade
- Slides focados em sinais práticos de refatoração
- Exercícios progressivos com validação automática
- Checklist de técnicas de refatoração
Ambientais:
- Espaço para circular durante exercícios práticos
- Conectividade para compartilhamento de código
- Ambiente silencioso para concentração nas refatorações
📊 Avaliação
Formativa (Durante a aula):
- Observação direta na identificação de sinais problemáticos
- Qualidade da refatoração nos exercícios práticos
- Verificação de que comportamento foi preservado via testes
Critérios de Avaliação:
| Competência | Insuficiente | Regular | Bom | Excelente |
|---|---|---|---|---|
| Identificação | Não identifica problemas | Identifica óbvios | Identifica sistemática | Identifica sutis |
| Refatoração | Código quebra/altera comportamento | Funciona mas pouco limpo | Melhora significativamente | Solução elegante |
| Preservação | Comportamento alterado | Preserva parcialmente | Comportamento preservado | + testes adicionais |
| Nomenclatura | Nomes genéricos/confusos | Nomes adequados | Nomes expressivos | Nomes autodocumentados |
Somativa (Pós-aula):
- Refatoração de código real aplicando 2+ técnicas aprendidas
- Validação via testes que comportamento foi preservado
- Preparação mental para padrões de design (Aula 04)
🔄 Interdisciplinaridade
Conexões:
- Banco de Dados I: Normalização vs refatoração (melhoria de estrutura)
- Engenharia de Software: Manutenibilidade e evolução de sistemas
- Arquitetura de Software: Clean code e technical debt reduction
Competências Transversais:
- Pensamento crítico: Identificação de code smells
- Qualidade e melhoria contínua: Refatoração como disciplina
- Trabalho em equipe: Código limpo facilita colaboração
📈 Continuidade
Pré-requisitos confirmados:
- Princípio DRY da Aula 02 (base para Remove Duplication)
- Código limpo da Aula 01 (conceitos de métodos pequenos)
- Familiaridade com testes JUnit 5 para validação
Preparação para próximas aulas:
- Aula 04: Código refatorado servirá de base para aplicar Design Patterns
- Aula 05: Testes automatizados expandidos para TDD
- Projeto final: Arquitetura limpa com refatoração contínua
Estudo dirigido:
- Identificar 3 casos de código que precisa refatoração em projeto pessoal
- Aplicar Extract Method em pelo menos 1 método longo
- Ler: Refactoring (Fowler) - Capítulo sobre Extract Method
🔧 Adaptações Planejadas
Para turma iniciante:
- +10 min em conceitos básicos de refatoração
- Exemplos mais simples com 1-2 extrações vs sistema complexo
- Foco visual em sinais óbvios antes de detectar sutis
- Template de refatoração com passos numerados
Para turma experiente:
- -5 min conceitos, +15 min em técnicas avançadas
- Discussão de trade-offs: Quando NÃO refatorar (over-engineering)
- Desafios extras: Refatoração com performance constraints
- Análise crítica de refatorações de sistemas reais do trabalho
Para turma mista:
- Duplas experiente + iniciante para mentoring durante exercícios
- Exercícios em camadas: Identificação (todos) → Refatoração simples → Refatoração complexa
- Apresentações diferenciadas por nível de complexidade atingido
📝 Observações Finais
Pontos críticos de atenção:
- Segurança: Sempre validar via testes que comportamento foi preservado
- Disciplina: Refatoração deve ser pequena e incremental, não big-bang
- Foco prático: Refatoração existe para facilitar manutenção futura, não para perfectcionismo
Indicadores de sucesso da aula:
- 80%+ dos alunos aplicaram Extract Method corretamente no Exercício 1
- Discussão natural sobre “quando parar de refatorar”
- Perguntas conectando com código que já mantiveram
- Entendimento que refatoração é meio para manutenibilidade, não fim
Plano B para problemas técnicos:
- Refatoração no papel: Desenhar extração de métodos com marcadores coloridos
- Identificação visual: Destacar problemas em código impresso
- Discussão de casos: Brainstorming de exemplos de código problemático
Mensagem-chave da aula:
“Refatoração não é bout fazer código ‘bonito’. É sobre tomar decisões hoje que tornarão mudanças futuras mais fáceis e seguras. Se você consegue explicar facilmente o que o código faz, provavelmente não precisa refatorar.”