5 min leitura • Guide 406 of 877
Práticas de Pair Programming
Pair programming significa dois desenvolvedores trabalhando juntos em um computador. Bom pairing produz código melhor, compartilha conhecimento e constrói relacionamentos no time. Pairing ruim é frustrante e improdutivo. Este guia cobre práticas efetivas de pairing.
Benefícios do Pairing
| Benefício | Impacto |
|---|---|
| Qualidade de código | Menos bugs, melhor design |
| Compartilhamento de conhecimento | Sem pontos únicos de falha |
| Onboarding | Ramp-up mais rápido |
| Foco | Menos distração |
Papéis no Pairing
Driver e Navigator
PAPÉIS DE PAIRING
═════════════════
DRIVER:
─────────────────────────────────────
├── Mãos no teclado
├── Escreve o código
├── Foca na implementação
├── Pensa em sintaxe
├── Problema imediato
└── Tático
NAVIGATOR:
─────────────────────────────────────
├── Observa e revisa
├── Pensa na visão geral
├── Identifica bugs e issues
├── Considera design
├── Olha adiante
├── Sugere melhorias
└── Estratégico
TROCANDO:
─────────────────────────────────────
Troque a cada 15-30 minutos:
├── Timer ou pausa natural
├── Ambos ficam engajados
├── Perspectiva fresca
├── Propriedade compartilhada
└── Participação igual
ANTI-PADRÃO:
─────────────────────────────────────
Pairing ruim:
├── Navigator checa celular
├── Driver ignora navigator
├── Uma pessoa sempre dirige
├── Coding silencioso
├── Não é realmente pairing
└── Engajamento é necessário
Estilos de Pairing
Diferentes Abordagens
ESTILOS DE PAIRING
══════════════════
DRIVER-NAVIGATOR (Clássico):
─────────────────────────────────────
├── Um dirige, outro navega
├── Troca regularmente
├── Papéis claros
├── Bom para maioria do trabalho
└── Estilo padrão
PING-PONG (TDD):
─────────────────────────────────────
Processo:
├── A escreve teste falhando
├── B faz teste passar
├── B escreve próximo teste falhando
├── A faz teste passar
├── Continua alternando
└── Ótimo para TDD
Exemplo:
A: escreve teste → VERMELHO
B: implementa → VERDE
B: escreve teste → VERMELHO
A: implementa → VERDE
...
STRONG-STYLE:
─────────────────────────────────────
Regra: "Para uma ideia ir da sua
cabeça para o computador, deve
passar pelas mãos de outra pessoa"
├── Navigator tem ideia
├── Deve explicar para driver
├── Driver implementa
├── Força comunicação
├── Bom para ensinar
└── Transferência explícita de conhecimento
BACKSEAT NAVIGATOR:
─────────────────────────────────────
Quando usar:
├── Expert + novato
├── Expert navega mais
├── Novato aprende fazendo
├── Handoff gradual
└── Bom para mentoria
Configuração de Ambiente
Setup para Pairing
AMBIENTE DE PAIRING:
┌─────────────────────────────────────────────────────────────┐
│ │
│ PRESENCIAL: │
│ ──────────── │
│ • Uma estação de trabalho │
│ • Monitor grande ou dois monitores │
│ • Dois teclados/mouses (opcional) │
│ • Cadeiras lado a lado │
│ • Espaço confortável │
│ │
│ REMOTO: │
│ ───────── │
│ • Screen sharing (Zoom, Teams, Discord) │
│ • VS Code Live Share ou similar │
│ • Boa conexão de internet │
│ • Câmera ligada (recomendado) │
│ • Microfone de qualidade │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ FERRAMENTAS ÚTEIS: │
│ ────────────────── │
│ • VS Code Live Share - Edição colaborativa │
│ • Pop - Pairing dedicado │
│ • Tuple - Pairing para Mac │
│ • Screen.so - Compartilhamento rápido │
│ │
│ CONTROLE REMOTO: │
│ ──────────────── │
│ Alternar quem compartilha tela quando trocar papéis │
│ Ou usar ferramenta que permite ambos editarem │
│ │
└─────────────────────────────────────────────────────────────┘
Quando Fazer Pair
Decisão de Pairing
QUANDO FAZER E NÃO FAZER PAIR:
┌─────────────────────────────────────────────────────────────┐
│ │
│ SEMPRE PAIR: │
│ ───────────── │
│ ✅ Código complexo ou crítico │
│ ✅ Área não familiar do codebase │
│ ✅ Onboarding de novo membro │
│ ✅ Design de arquitetura │
│ ✅ Debugging difícil │
│ ✅ Código de segurança │
│ │
│ CONSIDERE PAIR: │
│ ─────────────── │
│ 🤔 Features de tamanho médio │
│ 🤔 Refactoring significativo │
│ 🤔 Aprender nova tecnologia │
│ 🤔 Quando bloqueado │
│ │
│ NÃO PAIR: │
│ ────────── │
│ ❌ Tarefas triviais (typos, formatação) │
│ ❌ Pesquisa individual │
│ ❌ Trabalho administrativo │
│ ❌ Quando ambos estão exaustos │
│ ❌ Quando precisa de deep focus solo │
│ │
│ REGRA GERAL: │
│ ───────────── │
│ Pair quando benefício > custo │
│ Custo = 2x pessoa-tempo │
│ Benefício = qualidade + aprendizado + foco │
│ │
└─────────────────────────────────────────────────────────────┘
Melhores Práticas
Checklist de Implementação
CHECKLIST DE PAIR PROGRAMMING
═════════════════════════════
ANTES:
☐ Objetivo claro definido
☐ Ambiente preparado
☐ Tempo acordado
☐ Papéis iniciais definidos
DURANTE:
☐ Comunicação constante
☐ Trocas a cada 15-30 min
☐ Ambos engajados
☐ Pausas quando necessário
DEPOIS:
☐ Resumo do progresso
☐ Decisões documentadas
☐ Próximos passos claros
☐ Feedback trocado
CULTURA:
☐ Tempo protegido para pairing
☐ Rotação de pairs
☐ Respeito mútuo
☐ Abertura a feedback
Pairing efetivo transforma dois desenvolvedores em mais que a soma das partes.