👥 Projeto Prático - Aula 04: Pair Programming
Disciplina: Desenvolvimento de Sistemas II
Professor: Ricardo Pires
Turma: 3º Técnico em Desenvolvimento de Sistemas
Data: 30/03/2026
📋 Visão Geral
Este projeto contém exercícios práticos para aprender Pair Programming através de implementação colaborativa em Java. O projeto está estruturado em 3 módulos principais que demonstram diferentes aspectos da programação em duplas.
🎯 Objetivos do Projeto
- ✅ Praticar TDD colaborativo com alternância Driver/Navigator
- ✅ Desenvolver debugging colaborativo para identificação eficiente de bugs
- ✅ Implementar features complexas através de discussão técnica contínua
- ✅ Experimentar qualidade superior via revisão em tempo real
🏗️ Estrutura do Projeto
projeto-pratico/
├── src/
│ ├── main/java/etec/ds/aula04/
│ │ ├── tdd/ # 🧪 Módulo TDD Colaborativo
│ │ │ └── Calculadora.java
│ │ ├── debugging/ # 🐞 Módulo Debugging Colaborativo
│ │ │ ├── ContadorVisitas.java (versão com bugs)
│ │ │ └── ContadorVisitasCorrigido.java
│ │ └── aplicacao/ # 🚀 Módulo Feature Complexa
│ │ └── LoginService.java
│ └── test/java/etec/ds/aula04/
│ ├── tdd/
│ │ └── CalculadoraTest.java
│ ├── debugging/
│ │ └── ContadorVisitasTest.java
│ └── aplicacao/
│ └── LoginServiceTest.java
├── pom.xml # 📦 Configuração Maven
├── checkstyle.xml # 📏 Rules de qualidade
└── README.md # 📖 Este arquivo
🧪 Módulo 1: TDD Colaborativo (Calculadora)
📝 Descrição
Implementação de calculadora científica usando Test-Driven Development em duplas. Duplas alternam entre roles de Driver e Navigator a cada ciclo Red→Green→Refactor.
🎯 Learning Objectives
- Praticar TDD rigoroso com pairs guidance
- Experimentar design emerging através de discussion collaborative
- Desenvolver communication skills durante coding bajo pressure
- Aplicar edge case thinking with two perspectives
🔄 Methodology
// Rodada 1 (15 min): Navigator A + Driver B
@Test
void deveSomarDoisNumeros() {
// Navigator guia strategy: "Vamos começar com soma simples"
// Driver implementa: tipos código com Navigator validation
Calculadora calc = new Calculadora();
assertEquals(5.0, calc.somar(2.0, 3.0), 0.001);
}⚡ Quick Start
# Executar testes do módulo TDD
mvn test -Dtest=CalculadoraTest
# Verificar implementação atual
mvn test-compile exec:java -Dexec.mainClass="etec.ds.aula04.tdd.Calculadora"📊 Success Criteria
- 6+ testes escriben collaboratively
- 100% line coverage en basic operations
- Role alternation every 15-20 minutos
- Edge cases handled (division by zero, overflow, etc.)
🐞 Módulo 2: Debugging Colaborativo (ContadorVisitas)
📝 Descrição
A classe ContadorVisitas.java contém 6-8 bugs intencionais que duplas devem identificar e corrigir através de collaborative debugging. includes common Java pitfalls.
🚨 Types of Bugs Included
Assignment vs Comparison:
// 🚨 BUG: Assignment em conditional
if (sistemaAtivo = true) { ... } // Deveria ser ==
// 🚨 BUG: Comparison em assignment
visitas == 0; // Deveria ser =Null Pointer Exceptions:
// 🚨 BUG: No null validation
String processed = origem.trim().toUpperCase(); // NPE if origem is nullString Comparison Errors:
// 🚨 BUG: Reference comparison em lugar de content
return statusAtual == statusEsperado; // Deveria usar .equals()🔄 Collaborative Process
- Navigator reads code line by line, questions cada decision
- Driver implementa tests para prove each suspected bug
- Both discuss expected vs actual behavior
- Driver aplica corrections guiado pelo Navigator
- Both validate fix com test execution
⚡ Quick Start
# Execute tests para see failing tests (indica bugs)
mvn test -Dtest=ContadorVisitasTest
# Execute single test método
mvn test -Dtest=ContadorVisitasTest#identificarMultiplosBugsSequencialmente🎯 Debugging Exercise
// Navigator questions to ask:
// "O que acontece se sistemaAtivo for false?"
// "Por que usa = em lugar de == aqui?"
// "What happens when origem is null?"
// "Limited to 100 visitas makes sense?"📊 Success Criteria
- Minimum 4 distinct bugs identified
- Collaborative discussion sobre each bug encountered
- Working tests que demonstram each fix
- Both participants can explain each bug type
🚀 Módulo 3: Feature Complexa (LoginService)
📝 Descrição
Implementação de authentication system with rate limiting para prevent força bruta attacks. Requires intensive collaboration devido multiple edge cases e security considerations.
🔐 Features Implemented
- User authentication against in-memory user database
- Rate limiting - block account after 3 failed attempts
- Time-based account blocking (15 minutos)
- Administrative override para unlock accounts
- Security statistics e monitoring
- Input validation e error handling
🎯 Collaborative Complexity
// Navigator strategic thinking:
// "Como devemos handle time-based locks?"
// "What about concurrent access scenarios?"
// "Should failed attempt counter reset on success?"
// Driver implementation focus:
// "Implementa HashMap-based tracking first"
// "Add time calculations com LocalDateTime"
// "Build defensive validations para all inputs"⚡ Quick Start
# Execute todos os LoginService tests
mvn test -Dtest=LoginServiceTest
# Test specific security scenario
mvn test -Dtest=LoginServiceTest#deveBloqueareContaApos3Tentativas
# View security statistics
mvn test -Dtest=LoginServiceTest#estatisticasDevemRefletirEstadoReal🔄 Pair Programming Points
- Navigator focuses em business logic e edge cases
- Driver implements security validations step-by-step
- Both collaborate em error handling strategies
- Discussion sobre trade-offs (security vs usability)
- Real-time review de security vulnerabilities
📊 Success Criteria
- Authentication working para valid users
- Rate limiting active após 3 failed attempts
- Time-based unlock functioning correctly
- Input validation comprehensive
- Security exception handling appropriate
- Both developers understand security implications
🛠️ Setup e Execution
📋 Prerequisites
- Java 21 ou superior installed
- Maven 3.6+ configured
- VS Code with Live Share extension (for remote pairing)
- Git para version control
⚡ Quick Setup
# 1. Clone ou download o projeto
cd Aula04/projeto-pratico
# 2. Verify Java e Maven versions
java --version # Should show 21+
mvn --version # Should show 3.6+
# 3. Execute todos os tests
mvn clean test
# 4. Generate test coverage report
mvn jacoco:report
# 5. View coverage em browser
open target/site/jacoco/index.html🧪 Individual Module Testing
# TDD Module only
mvn test -Dtest=**/tdd/**/*Test
# Debugging Module only
mvn test -Dtest=**/debugging/**/*Test
# Complex Feature Module only
mvn test -Dtest=**/aplicacao/**/*Test📊 Quality Validation
# Code style checking
mvn checkstyle:check
# Full quality report
mvn site
# Quick quality overview
mvn verify👥 Pair Programming Guidelines
🔄 Role Alternation Strategy
Every 15-20 Minutes:
- Timer reminder para role switch
- Natural breakpoints (after test passes, before new feature)
- Note current progress before switching
During TDD Cycles:
Red Phase → Navigator leads strategy
Green Phase → Driver leads implementation
Refactor → Both collaborate equally
💬 Communication Patterns
Navigator Effective Phrases:
- “What edge case are we missing here?”
- “How would this behave if [parameter] is null?”
- “Should we extract this logic into a helper method?”
- “What’s the business logic behind this decision?”
Driver Effective Phrases:
- “I’m implementing [strategy], does this make sense?”
- “Before coding this, let’s agree on the approach”
- “This test is failing because… what should we fix?”
- “I think there’s a bug here, what do you see?”
🚨 Avoid These Anti-Patterns:
- ❌ Silent Navigator: watching passively without engagement
- ❌ Micromanaging Navigator: dictating every keystroke
- ❌ Ignoring Driver: Navigator not listening to implementation feedback
- ❌ Rushed Switching: not explaining context before role change
📈 Assessment & Learning Evidence
📊 Technical Metrics
- Test Coverage: Target 85%+ line coverage
- Code Quality: 0 checkstyle violations
- Test Quality: Comprehensive edge case coverage
- Working Features: All major functionality implemented
🎯 Collaboration Metrics
- Equal Participation: Both voices heard in decisions
- Role Alternation: Regular switching every 15-20 min
- Communication Quality: Technical discussions productive
- Problem-Solving: Collaborative approach to debugging
🏆 Success Indicators
- All modules completed with working implementations
- Bugs identified e corrigidos collaboratively no debugging module
- TDD process followed rigorously com pair validation
- Complex feature implemented through intensive collaboration
- Both developers satisfied com pair programming experience
- Code quality maintained throughout collaborative development
🎓 Learning Extensions
🚀 After Completing Basic Exercises:
Advanced Pair Techniques:
- Strong-style pairing: “Ideas através other’s hands”
- Ping-pong pairing: Alternate test writing e implementation
- Mob programming: 3-4 people collaboration on complex features
Tool Mastery:
- Remote pair programming com VS Code Live Share
- Git collaboration com proper branching e merging
- Debugging tools integration durante collaborative sessions
Professional Applications:
- Code review processes optimization using pair experience
- Knowledge transfer techniques for onboarding new team members
- Quality improvement strategies based on collaborative development
🆘 Troubleshooting
🔧 Common Issues
Maven Build Failures:
# Clean rebuild
mvn clean compile
# Skip tests temporariamente
mvn compile -DskipTests
# Check Java version compatibility
mvn -versionTest Execution Issues:
# Single test debugging
mvn test -Dtest=CalculadoraTest -X
# Exclude problematic test temporarily
mvn test -Dtest='!**/debugging/**'Checkstyle Violations:
# View specific violations
mvn checkstyle:check -X
# Auto-fix some formatting issues
# (Use IDE auto-format: Ctrl+Alt+L in most IDEs)👥 Pair Programming Issues
- Tool setup problems: Use simplest working setup first
- Communication barriers: Establish explicit “think aloud” protocol
- Experience gap: Use micro-teaching moments during implementation
- Personality conflicts: Focus on technical decisions, not personal styles
📞 Support & Resources
🆘 Getting Help
- Professor: ricardo.pires@etec.sp.gov.br
- Office Hours: Seg-Sex, 18h30-21h30
- Class Forum: Google Classroom for peer assistance
- Pair Partner: Don’t hesitate to ask your pair for clarification
📚 Additional Resources
- Extreme Programming Pair Programming
- Martin Fowler on Pair Programming
- VS Code Live Share Documentation
🏆 Next Steps
Aula 05: Design Patterns gennem Collaborative Decision Making
Project Final: Option voor pair programming approach với doubled complexity requirements
🎯 Remember: O objetivo não é just coding faster, mas coding better through collaboration. Quality emerge quando two minds work together effectively!