04-guia-professor

🎓 Guia do Professor - Aula 02

🎯 Preparação da Aula

⏰ 30 min antes da aula:

• Testar códigos no projeto-pratico/ - especialmente exemplos de duplicação
• Preparar demonstração do “bug de inconsistência” (ExemploAntes.java)
• Verificar que EmailValidator e CpfValidator compilam e rodam
• Abrir slides no VS Code com Marp

📋 Checklist de Material:

• Projetor funcionando para live coding de refatoração
• Código “problemático” pronto para demonstrar duplicação
• Timer para exercícios de identificação de duplicação
• Exemplos de sistemas reais com problemas DRY

---

🚨 Troubleshooting Comum

❌ “Por que não posso só copiar e colar código?”

Situação: Aluno questiona a necessidade de eliminar duplicação

Resposta estruturada:

“Vamos fazer um experimento. No código atual, se você encontrar um bug na validação de e-mail, quantos lugares você precisa corrigir? [Deixe responder] E se esquecer de corrigir um deles? [Demonstre o problema real] Por isso centralizamos: bug fix em 1 lugar = correção em todos os usos.”

Demonstração prática:

// Simule bug: validação aceita e-mail sem @
// Mostre que cadastro aceita, mas login rejeita
// Demonstre como correção centralizada resolve tudo

❌ “EmailValidator é muito específico, não vai servir para outros projetos”

Problema: Resistência à criação de classes utilitárias

Solução pedagógica:

1. Mostre evolução incremental: Comece simples, evolua conforme necessidade
2. Demonstre flexibilidade: Adicione método isValido() e normalizar()
3. Conecte com experiência: “Quantos sistemas vocês conhecem que não precisam validar e-mail?”

❌ “Testes parecem complicados demais”

Causa típica: Alunos focam em cenários complexos

Estratégia:

// Comece com teste óbvio
@Test
void testEmailValido_DevePassar() {
    assertDoesNotThrow(() -> EmailValidator.validarOuFalhar("test@test.com"));
}
 
// Depois evolua para casos complexos

Mantra: “Teste primeiro o básico, depois os edge cases”

---

💡 Dicas Pedagógicas

🎯 Condução do Live Coding:

⚡ Roteiro de Demonstração (30 min):

1. Comece com problema real (10 min):

   // Mostre código com duplicação
   demonstrarInconsistencia(); // Resultado: falha!

2. Refatore passo a passo (15 min):

   • Extraia primeiro método static
   • Substitua primeira ocorrência
   • Substitua segunda ocorrência
   • Teste novamente - demonstre que inconsistência sumiu

3. Evolua para solução robusta (5 min):

   • Adicione método isValido()
   • Adicione método normalizar()
   • Mostre como regra única pode ter múltiplas interfaces

📊 Gestão de Timing:

Segmento	Tempo Real	Buffer	Dica Importante
Conceitos DRY	12-18 min	15 min	Se correr muito, foque só no “um lugar para mudar”
Live refatoração	25-35 min	30 min	ESSENCIAL: demonstre o problema antes da solução
Exercícios	25-35 min	30 min	Circule e identifique duplicações com alunos
Review	10-15 min	15 min	Foque nos benefícios práticos que apareceram

🤝 Engajamento da Turma:

Perguntas estratégicas durante o coding:

• “Alguém já teve bug que estava ‘corrigido’ em um lugar mas ainda acontecia em outro?”
• “Por que vocês acham que este cadastro funciona mas o login falha?”
• “Se eu mudasse essa regra de validação, quantos arquivos precisaria alterar?”

Sinais de que está funcionando:

• 🟢 Alunos identificam duplicação antes de você mostrar
• 🟢 Comentários como “ah, entendi, é o mesmo problema que…”
• 🟢 Perguntas sobre quando aplicar DRY vs quando não aplicar

Sinais de alerta:

• 🔴 Foco demais na sintaxe (static, final) em vez do conceito
• 🔴 Preocupação com “onde colocar a classe” em vez de eliminar duplicação
• 🔴 Questionamento se “vale a pena” para código “simples”

---

🔧 Adaptações por Perfil de Turma

👶 Turma Iniciante:

• Foque na dor: Demonstre bug real antes de mostrar solução
• Simplifique terminologia: “código repetido” ao invés de “duplicação de lógica”
• Use exemplos visuais: Mostre lado a lado código antes/depois
• Dê template: Forneça esqueleto da classe utilitária para preencherem

💼 Turma Experiente:

• Conecte com experiência: Peça exemplos de duplicação que viram no trabalho
• Discuta trade-offs: Quando não aplicar DRY (performance crítica, domínios diferentes)
• Evolua rapidamente: Adicione validação de múltiplos campos, builders, etc.
• Desafio avançado: Como garantir que equipe use o validador centralizado?

🏫 Turma Mista:

• Use experientes como mentores: Eles ajudam a identificar duplicações
• Exercícios em camadas: Básico (identificar) → Intermediário (extrair) → Avançado (testar)
• Foque na discussão: Mais importante que todos codifiquem é que todos entendam

---

🎭 Scripts para Situações Difíceis

”Essa validação é muito simples, não precisa de uma classe só pra isso”

“Verdade! É simples mesmo. A pergunta é: se é tão simples assim, por que está duplicado em 3 lugares já? E quando precisar mudar, você quer caçar em quantos arquivos? Simples não significa barato de manter."

"Na empresa onde trabalho fazemos diferente”

“Perfeito! Como fazem lá? [Ouça] Interessante! O princípio DRY pode ser aplicado de várias formas. O importante é: regra única, local único. Qual seria outra forma de resolver este problema seguindo o mesmo princípio?"

"E se cada lugar precisar de uma validação diferente?”

“Excelente pergunta! Aí temos duas opções: ou não é a mesma regra (cada lugar tem sua responsabilidade específica), ou é a mesma regra mas com parametrização diferente. Vamos analisar: essas validações são realmente diferentes ou são variações da mesma regra?”

Turma muito dispersa/ceticismo alto:

“Vou fazer uma aposta com vocês. Vamos cronometrar: quanto tempo leva para encontrar onde está implementada a validação de e-mail neste código? [Cronometrar] Agora quanto tempo leva para mudar em todos os lugares? [Demonstrar] E na versão refatorada? [Mostrar diferença] Qual vocês prefeririam debuggar às 23h numa sexta-feira?”

---

📊 Avaliação de Performance da Aula

✅ Indicadores de Sucesso:

• 80%+ dos alunos completaram identificação de duplicação no Exercício 1
• Pelo menos 4 alunos apresentaram voluntariamente sua solução
• Discussão sobre quando aplicar vs quando não aplicar DRY
• Perguntas sobre sistemas reais e aplicação prática

⚠️ Sinais de Alerta:

• Foco excessivo em sintaxe (static, final) ao invés de conceito
• Dúvidas sobre “onde colocar arquivo” ao invés de eliminar duplicação
• Resistência ao conceito (“é exagero para validação simples”)
• Confusão entre DRY e reutilização prematura

📈 Melhorias para Próxima Vez:

• Que tipos de duplicação foram mais fáceis de identificar?
• Onde alunos tiveram mais difficulty no live coding?
• Que benefícios práticos ressoaram mais com a turma?
• Como conectar melhor com experiência prévia dos alunos?

---

🔗 Recursos de Backup

Se a tecnologia falhar:

• Exercício no papel: Circulem duplicações com caneta colorida
• Discussão conceitual: Quando corrigir bug em sistema, quantos lugares alteram?
• Brainstorming: Listar exemplos de duplicação que já viram

Se sobrar tempo:

• Desafio bônus: Implementar TelefoneValidator seguindo o padrão
• Code review: Analisar código de aluno identificando duplicações
• Discussion: Preview da Aula 03 (refatoração segura com testes)

Se faltar tempo:

• Foque no essencial: Demonstração do problema + conceito DRY
• Envie gabarito: Por email com comentários explicativos
• Review rápido: 3 pontos principais: duplicação = bug, regra única = local único, teste validador

---

🎯 Conexão Crítica com Aulas

📚 Da Aula 01 (Clean Code):

• Retome: Nomenclatura clara aplicada nos validadores (validarOuFalhar vs check)
• Conecte: Código limpo + DRY = sistema manutenível
• Evolua: Não é só legível, é único

🚀 Para Aula 03 (Refatoração):

• Prepare: Validadores criados serão base para refatoração segura
• Antecipe: “Próxima aula vamos mudar estrutura sem medo porque temos testes”
• Motivação: “Código centralizado é mais seguro de refatorar”

💡 Frase de Fechamento:

“Hoje aprendemos: regra única, local único. Próxima aula: mudança segura, testes únicos. No final do módulo vocês vão ter código que é limpo (Aula 1), reutilizável (hoje), e evolutivo (Aula 3+).”