Nota do Editor:  Farhan Thawar é o vice-presidente de Engenharia de Toronto Xtreme Labs . Antes de ingressar na equipe Xtreme, Farhan ocupou os cargos de Chief Software Architect em Eu amo Recompensas, o Chefe de Pesquisa e plataforma Microsoft MSN para Canadá e líder técnico em Software Trilogy. Este post é uma resposta à (ex-Xtremer) Jon EvansPair Programming considerada prejudicial? , que descreveu algumas das vantagens e desvantagens da programação em pares.

Você está em um carro a 100 milhas por hora em uma estrada de terra. Os turnos são de 100 grampos º e existem inclinações e depressões que fariam choques de um carro normal de cair para a direita fora de seus eixos.

Sorte para você, você não está sozinho. Você tem um parceiro. Porque existem dois de você, você pode dividir as responsabilidades de chegar à linha de chegada em primeiro lugar – em uma única peça.

• Driver: com foco no controle intenso do volante, que equipa o acelerador, freio e pedais da embreagem, e não se esqueça do freio de emergência da mais alta importância
• Navegador: encarregado de ler as direções de mapas, verificar velocidade do vento / motor de luzes e alertar o condutor de voltas iminentes, depressões e inclinações.

Esta é a base da programação do par. A prática deliberada de pessoal cada estação de trabalho com dois engenheiros de software focado em escrever software em conjunto. Semelhante ao Rally Racing, o piloto e navegador têm o mesmo objetivo – escrever código de alta qualidade e de fácil manutenção que funciona.

Como ele funciona?

• Dois teclados e dois mouses
• Dois monitores grandes
• Dois engenheiros
• UM computador

O motorista e navegador pode muitas vezes trocam de papéis ao longo de uma sessão de programação (ao contrário de corridas de rali):

• Driver: Além do que o Navigator não – ativamente digitando no teclado, pode render ao navegador
• Navegador: A verificação de erros, olhando para cima APIs, pensando em maneiras de melhorar a estrutura do código, pode entrar e unidade

Então, por programa de par? Há tantas razões, mas vou discutir os três primeiros:

• Aprenda mais rápido: Como você gostaria de aprender Java de James Gosling ou C # de Anders Hejlsberg? O emparelhamento é a melhor maneira de aprender uma nova plataforma (espere, você não achou que fosse aula de estilo não é?). Ao colocar você no mesmo teclado eo monitor como o assistente de Java, que fica no canto, o condutor e navegador benefício. O navegador (também bem versado em engenharia de software, não apenas Java) traz os mesmos benefícios para o motorista como um segundo par de olhos, constantemente sondando e questionando “por que as coisas são feitas dessa maneira?” Inevitavelmente as regras antigas e ineficientes hábitos do motorista estão quebrados. O navegador aprende Java mais rápido do que poderia, em sala de aula, mais rápido do que livros e mais rápido do que por conta própria.
• Conhecimento do domínio de transferência: O velho ditado costumava ser que os engenheiros devem se concentrar em uma área de especialidade e era raro encontrar engenheiros que eram bons em mais de uma coisa (ou seja, como um engenheiro que foi grande em JavaScript e banco de dados back-end otimização). Emparelhamento dissipa este velho paradigma. Par um engenheiro de front-end (Anisha) com um engenheiro de back-end (Brian) por alguns meses e você verá Anisha detonando declarações preparadas e Brian trabalhar em otimizações HTML5 em nenhum momento. Não acredita em mim?Venha e emparelhar em um projeto em um sistema que você nunca trabalhou antes.
• Intensidade: É tão difícil se concentrar nestes dias. Com o Twitter / Facebook / email / YouTube / Tumblr / IM / etc, eu não sei como qualquer trabalho é feito. E se eu pudesse colocar um engenheiro super-forte ao seu lado para ajudá-lo a se concentrar nas tarefas na mão? Agora, o que se vocês dois podem trocar idéias entre si e desbloquear o outro mais rápido do que procurar respostas no Google? Não, esses serviços não estão bloqueadas, é só com duas pessoas trabalhando juntas para verificar a necessidade de serviços personalizados (incluindo e-mail) normalmente espera até que uma pausa criativa.ou seja, mais tempo na tarefa.

E esses são apenas três razões. Eu nem sequer falar sobre o mau ambiente de trabalho aberto (sim, você pode conseguir um fluxo com outra pessoa), a capacidade de facilmente adicionar engenheiros dos badass para a sua equipe para aumentar a velocidade ou as taxas de retenção incrivelmente altos para engenheiros impressionantes. (Btw: estamos contratando ).

Ambos os laboratórios central e Xtreme Labs desfrutar hierarquias extremamente rasas e burocracia pouco. Eu mencionei que estabelecemos horas (9-6:00) e ninguém trabalha em casa? A blasfêmia.

Eu, pelo menos receber os nossos senhores programação em par!

Agora, para dissipar alguns mitos:

• Par de programação deve acontecer 100% do tempo: impossível. Eu parar de escrever porque você ir ao banheiro ou você está em casa doente? Claro que não. Isso não significa que nós não encorajamos o emparelhamento tanto quanto possível, porque o que fazemos, e certamente há momentos em que o emparelhamento é inferior a ideal para que não forme par de então.
• Emparelhamento Groupthink causas: O quê? Groupthink acontece quando você tem equipes muito grandes. Se qualquer coisa, o emparelhamento impede o pensamento de grupo, como cada par é de apenas dois engenheiros. É dois uma grande equipe? Vá ler The Mythical Man-Month. “Nenhum sistema deve ser projetado por mais de 2 pessoas”.Equipes pequenas não causam groupthink, as equipes realmente grandes fazem.
• Emparelhamento grandes engenheiros juntos torna ineficaz: negatron.

Guy Steele sobre o emparelhamento com o lendário Richard Stallman:

“Nós sentamos em uma manhã”, recorda Steele. “Eu estava no teclado, e ele estava no meu cotovelo”, diz Steele. “Ele estava perfeitamente disposto a deixar-me escrever, mas ele também estava me dizendo o que escrever.

“A sessão de programação durou 10 horas. Ao longo desse tempo todo, diz Steele, nem ele nem Stallman fez uma pausa ou fez qualquer conversa fiada. Ao final da sessão, eles haviam conseguido hackear o código-fonte bastante impressão para pouco menos de 100 linhas. “Meus dedos estavam no teclado o tempo todo”, Steele recorda, “mas parecia que ambas as nossas idéias foram fluindo na tela. Ele me disse o que digitar, e eu digitei isso. “

A duração da sessão de revelou-se quando Steele finalmente deixou o AI Lab. Do lado de fora do prédio a 545 Praça Tech, ele ficou surpreso ao encontrar-se cercado pela escuridão da noite. Como um programador, Steele foi utilizado para sessões de maratona de codificação. Ainda assim, alguma coisa sobre esta sessão foi diferente. Trabalhando com o Stallman tinha forçado Steele para bloquear todos os estímulos externos e concentrar a totalidade de suas energias mentais na tarefa na mão. Olhando para trás, Steele diz que encontrou o Stallman mente fundir tanto emocionante e assustador ao mesmo tempo. “Meu primeiro pensamento foi mais tarde: era uma grande experiência, muito intenso, e que eu nunca quis fazê-lo novamente em minha vida.”

Sim, programação em par não é para todos ou cada empresa.

Mas há também meio-irmão de programação par de pouco falado: lado a lado de programação. Você ganha alguns, mas não todos, os aspectos positivos do Emparelhamento (se sua organização não consegue lidar com a mudança), mas os engenheiros podem manter seus egos e suas próprias máquinas. Fazemos isso quando estamos trabalhando em tarefas rotineiras que não exigem um segundo conjunto de olhos (por exemplo, a inserção de ativos de design em uma aplicação móvel).Temos laptops floater você pode agarrar para fazer isso, mas ambos os engenheiros podem ver cada telas de outros.

Então, para recapitular, você só deve emparelhar programa quando quiser intensamente focados, engenheiros eficazes para escrever software de alta qualidade, para aprender uns com os outros e compartilhar o conhecimento de domínio.

Para tudo o resto, o programa silo durante todo o dia …

Crédito da imagem: Charles RINCHEVAL, Flickr