05-material-apoio

📚 Material de Apoio - Aula 01

🎯 Objetivo

Esta aula estabelece os fundamentos de código limpo que serão aplicados ao longo de todo o curso. O material abaixo oferece referências para aprofundamento e consolidação dos conceitos.

---

📖 Bibliografia Essencial

📚 Livros (por ordem de prioridade):

1. “Clean Code: A Handbook of Agile Software Craftsmanship” - Robert C. Martin

   • Capítulos relevantes: 1 (Clean Code), 2 (Meaningful Names), 4 (Comments)
   • Por que ler: Autoridade mundial em boas práticas
   • Como ler: 30 min por capítulo, com exemplos práticos

2. “Effective Java” - Joshua Bloch

   • Items relevantes: 67 (Optimize judiciously), 68 (Adhere to naming conventions)
   • Por que ler: Melhor guia específico para Java
   • Como ler: Um item por semana, aplicando no código próprio

3. “Code Complete” - Steve McConnell

   • Capítulos relevantes: 11 (Variable Names), 32 (Self-Documenting Code)
   • Por que ler: Base sólida de engenharia de software
   • Como ler: Referência para consulta por tópicos

---

🌐 Recursos Online

📄 Documentação Oficial:

• Oracle Java Code Conventions

  • Padrão oficial para nomenclatura Java
  • Atualizado regularmente pela Oracle

• Google Java Style Guide

  • Padrões usados pela Google
  • Mais rigoroso que o padrão Oracle

🎥 Videos Educativos:

• “Clean Code - Uncle Bob” (YouTube - 1h30min)

  • Palestra clássica do criador dos conceitos
  • Exemplos práticos em Java

• “Naming Things in Code” - Code Aesthetic (YouTube - 15min)

  • Foco específico em nomenclatura
  • Exemplos comparativos before/after

✍️ Artigos Técnicos:

• “The Art of Readable Code” - Dustin Boswell

  • Técnicas práticas de legibilidade
  • Exercícios para treinar

• “Comments vs Self-Documenting Code” - Martin Fowler Blog

  • Quando comentar e quando refatorar
  • Filosofia por trás das decisões

---

🛠️ Ferramentas Recomendadas

📱 Plugins para IDEs:

VS Code:

• Extension Pack for Java (Microsoft)
• SonarLint - Detecta problemas de qualidade
• Checkstyle - Valida convenções de estilo
• Better Comments - Melhora visualização de comentários

IntelliJ IDEA:

• SonarLint Plugin
• CheckStyle-IDEA
• Save Actions - Auto-formatação no save

Eclipse:

• SpotBugs - Detecção automática de problemas
• Eclipse Checkstyle Plugin

🔧 Ferramentas de Linha de Comando:

# Checkstyle - Validação de convenções
java -jar checkstyle-8.45.1-all.jar -c google_checks.xml arquivo.java
 
# SpotBugs - Análise estática
spotbugs -textui classes/
 
# PMD - Detecção de problemas comuns
pmd -d src -f text -R rulesets/java/basic.xml

---

💻 Laboratórios Práticos

🧪 Exercícios Complementares:

Laboratório 1: Refatoração Guiada (30 min)

// Arquivo: RefactoringLab.java (disponível no repositório)
// Objetivo: Aplicar TODAS as técnicas da aula em código real
// Métrica: Reduzir complexidade cognitiva de 15 para 5

Laboratório 2: Code Review em Equipe (45 min)

• Formar grupos de 3-4 pessoas
• Cada pessoa refatora o mesmo código “ruim”
• Comparar soluções e discutir trade-offs
• Criar consenso sobre “melhor” aproximação

Laboratório 3: Análise de Projeto Open Source (60 min)

• Escolher projeto Java conhecido (Spring, Hibernate, etc.)
• Analisar 3 classes diferentes
• Identificar padrões de naming e comentários
• Documentar “convenções” descobertas

🎯 Projetos de Continuidade:

Projeto A: Refatoração do Próprio Código

• Pegar código Java que você escreveu no passado
• Aplicar checklist da aula linha por linha
• Documentar “before/after” das mudanças
• Bonus: Medir tempo de compreensão com colega

Projeto B: Mentoria em Código

• Encontrar código confuso de colega/comunidade
• Refatorar aplicando princípios da aula
• Explicar mudanças pedagogicamente
• Valor: Desenvolve capacidade de ensinar

---

🏢 Aplicação Profissional

📊 Métricas de Qualidade:

Ferramentas de Medição:

• SonarQube: Complexity, maintainability index
• CodeClimate: GPA técnica, debt ratio
• NDepend: Coupling, cohesion metrics

KPIs para Acompanhar:

Métrica	Meta	Como Medir
Cyclomatic Complexity	< 10 por método	PMD, SonarQube
Method Names	80%+ verbos descritivos	Code review manual
Comment Ratio	10-15% do código	Ferramentas de análise
Time to Understand	< 2 min por método	Teste com novos devs

🤝 Implementação em Equipe:

Estratégias Graduais:

1. Semana 1-2: Adotar convenções de naming
2. Semana 3-4: Implementar checklist em code reviews
3. Semana 5-6: Configurar ferramentas automáticas
4. Onwards: Culture de melhoria contínua

Code Review Checklist:

- [ ] Nomes são auto-explicativos?
- [ ] Métodos fazem apenas UMA coisa?
- [ ] Comentários explicam "porquê", não "o quê"?
- [ ] Formatação está consistente?
- [ ] Código seria compreensível por júnior da equipe?

---

📈 Desenvolvimento Continuado

🎓 Próximos Níveis de Estudo:

Nível 2: Design Patterns

• Como padrões melhoram legibilidade
• Quando aplicar vs. over-engineering
• Material: Gang of Four + Head First Design Patterns

Nível 3: Architecture

• Clean Architecture principles
• Domain-Driven Design naming
• Material: Martin Fowler, Eric Evans

Nível 4: Performance Profiling

• Como manter legibilidade com otimizações
• Trade-offs entre perfromance e clareza
• Material: Java Performance Tuning

🏆 Certificações Relacionadas:

• Oracle Certified Professional Java SE
• SonarSource Clean Code Certification
• Java Code Reviewer Certification (varias instituições)

---

🔗 Comunidades e Networking

💬 Communities Online:

• Stack Overflow - Tag [java] + [clean-code]
• Reddit r/java - Discussões sobre boas práticas
• Java Code Geeks - Artigos e tutoriais
• LinkedIn Java Groups - Networking profissional

🎪 Eventos e Conferências:

• JavaOne / Oracle Code One - Anual
• Devoxx - Europa/Brasil
• JUG meetings - Grupos de usuários locais
• QCon - Tracks de software quality

---

📞 Suporte e Dúvidas

📧 Contatos de Mentoria:

• Professor: ricardo.pires@etec.sp.gov.br
• Monitoria: Quintas 14h-16h (Lab de Informática)
• Forum da turma: [Link Discord/Teams]

❓ FAQ Rápido:

“Estas regras não são muito rígidas”

As regras são ferramentas, não dogmas. O objetivo é comunicação efetiva em equipe. À medida que ganhar experiência, desenvolvera seu próprio estilo dentro das diretrizes.

”E se meu time não segue esses padrões?”

Comece individualmente, influencie pelo exemplo. Sugira in code reviews, proponha ferramentas. Mudança cultural leva tempo, mas começa indivual.

”Código limpo não impacta performance?”

Raramente. JVM é muito otimizada. 95% do tempo o bottleneck serrá algoritmo/DB/network, não naming. Otimizaçõo prematura é muito maior problema que over-naming.

---

✅ Checklist de Estudo Semanal

Para certificar boa absorção dos conceitos:

Esta Semana:

• Ler Clean Code Cap. 1-2 (60 min)
• Refatorar 2 métodos do próprio código (30 min)
• Configurar plugin Checkstyle na IDE (15 min)
• Experimentar Google Style Guide num projeto (45 min)

Próxima Semana:

• Fazer Laboratório 1 completo
• Revisar código de 1 colega usando checklist
• Ler artigo do Martin Fowler sobre comentários
• Preparar 1 exemplo de código ruim para Aula 02

Mês:

• Completar Projeto A (refatoração pessoal)
• Configurar SonarQube em 1 projeto
• Ler Effective Java Items relacionados
• Participar de 1 discussão online sobre clean code