👥 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 null

String Comparison Errors:

// 🚨 BUG: Reference comparison em lugar de content
return statusAtual == statusEsperado;  // Deveria usar .equals()

🔄 Collaborative Process

  1. Navigator reads code line by line, questions cada decision
  2. Driver implementa tests para prove each suspected bug
  3. Both discuss expected vs actual behavior
  4. Driver aplica corrections guiado pelo Navigator
  5. 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

  1. Navigator focuses em business logic e edge cases
  2. Driver implements security validations step-by-step
  3. Both collaborate em error handling strategies
  4. Discussion sobre trade-offs (security vs usability)
  5. 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

  • “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 -version

Test 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

🏆 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!

0 items neste arquivo.