Programação em Par

Programação em par significa dois desenvolvedores trabalhando juntos em uma estação de trabalho. Um digita (o driver); o outro observa, pensa e navega (o navigator).

Isso parece ineficiente. Você está pagando duas pessoas para fazer o trabalho de uma. Mas a matemática funciona de forma diferente do que você esperaria:

• Menos bugs chegam à produção (o navigator detecta erros em tempo real)
• O conhecimento se espalha pela equipe (sem silos de conhecimento)
• A qualidade do código melhora (revisão de código em tempo real)
• Desenvolvedores juniores evoluem mais rápido (aprendendo com seniores)
• O foco melhora (é mais difícil checar o Twitter quando alguém está observando)

Estudos mostram que pares produzem código com 15% menos defeitos enquanto levam apenas 15% mais tempo. Isso não é o dobro do custo para melhor qualidade—é um investimento de 15% para resultados dramaticamente melhores.

O modelo clássico de pair programming tem dois papéis:

O Driver segura o teclado. Ele:

• Digita o código
• Foca na tarefa imediata (sintaxe, esta linha, este teste)
• Pensa taticamente sobre implementação
• Fala sobre o que está fazendo

O Navigator observa e pensa. Ele:

• Revisa o código conforme é escrito
• Pensa estrategicamente (esse design faz sentido?)
• Mantém o panorama geral em mente
• Detecta erros de digitação, erros de lógica e problemas de design
• Busca informações quando necessário

Troque de papéis regularmente. A cada 15-30 minutos, alternem. Isso mantém ambos os parceiros engajados e evita que uma pessoa domine.

O navigator não é passivo. Se você está navegando e vê algo errado, fale imediatamente. Não espere. O valor do pair programming vem do feedback contínuo.

Existem vários estilos eficazes de pair programming:

Ping-Pong Pairing (funciona muito bem com TDD):

1. Pessoa A escreve um teste que falha
2. Pessoa B faz passar e escreve o próximo teste que falha
3. Pessoa A faz passar e escreve o próximo teste que falha
4. Continue alternando

Isso mantém ambas as pessoas codificando ativamente e mantém a disciplina do TDD.

Strong-Style Pairing: "Para uma ideia ir da sua cabeça para o computador, ela deve passar pelas mãos de outra pessoa."

O navigator diz ao driver o que digitar. O driver apenas digita; ele não toma decisões. Isso é ótimo para ensinar—o junior digita enquanto o senior navega, forçando a transferência de conhecimento.

Tour Guide Pairing: Uma pessoa conhece a base de código; a outra está aprendendo. O especialista dirige e explica, dando um tour pelo código. Depois eles trocam, com o aprendiz tentando tarefas sob orientação.

Escolha o estilo que se encaixa na situação. Ping-pong para TDD. Strong-style para mentoria. Tour guide para onboarding.

Pair programming funciona remotamente também. Você precisa de:

• Compartilhamento de tela com baixa latência (VS Code Live Share, JetBrains Code With Me, ou compartilhamento de tela com controle remoto)
• Comunicação por voz (conexão de áudio constante)
• Câmera opcional mas útil (ver reações e linguagem corporal)

Dicas para pair programming remoto:

• Use uma ferramenta que permita ambas as pessoas digitarem (não apenas compartilhamento de tela)
• Faça pausas mais frequentes—pair programming remoto é mais cansativo
• Comunique-se verbalmente em excesso (você não consegue ler a linguagem corporal tão bem)
• Concordem sobre configurações do editor e atalhos de teclado antes de começar

Algumas equipes descobrem que o pair programming remoto funciona ainda melhor que presencialmente porque não há a tentação de "se inclinar e pegar o teclado". Cada pessoa permanece em seu papel.

Faça pair programming em:

• Problemas complexos onde duas perspectivas ajudam
• Caminhos críticos do código (autenticação, pagamentos, integridade de dados)
• Código desconhecido (uma pessoa conhece, outra está aprendendo)
• Quando você está travado (perspectiva nova quebra impasses)
• Onboarding de novo membro da equipe

Considere trabalho solo para:

• Tarefas simples e rotineiras (atualizar configuração, renomear coisas)
• Spikes exploratórios (quando você precisa pensar sozinho)
• Quando uma pessoa tem expertise profunda que a outra não pode contribuir

XP não exige 100% de pair programming, apesar da crença comum. O XP original especificava pair programming para código de produção, mas o XP moderno reconhece que equipes eficazes misturam trabalho solo e em par baseado no contexto.

O ponto-chave: nunca deixe código ir para produção sem revisão. Se você não fez pair programming, revise. Pair programming é apenas revisão de código em tempo real.

"Nossos desenvolvedores não querem fazer pair programming." Comece devagar. Faça pair programming apenas em problemas difíceis. Deixe as pessoas experimentarem os benefícios. Não force 100% de pair programming no primeiro dia.

"Não podemos pagar duas pessoas em uma tarefa." Você também não pode pagar bugs de produção. A economia favorece o pair programming quando você considera bugs reduzidos, conhecimento compartilhado e qualidade de código melhorada.

"Desenvolvedores seniores serão desacelerados." Às vezes. Mas seniores fazendo pair programming com juniores aceleram a equipe toda. O conhecimento do senior se espalha. O junior evolui. É um investimento na capacidade da equipe.

"Introvertidos odeiam pair programming." Alguns introvertidos amam pair programming porque é interação estruturada com um propósito claro. Outros precisam de tempo solo para recarregar. Respeite necessidades individuais, mas não assuma que introversão significa anti-pair programming.

"Programação em par é exaustiva." É mais intensa que trabalho solo. Faça pausas. Não faça pair programming por 8 horas seguidas. Misture pair programming com trabalho solo, revisão de código ou trabalho de design.