Tom Dommett escreveu para compartilhar sua experiência positiva com programação em pares:
A ideia é que dois desenvolvedores trabalhem na mesma máquina. Ambos têm teclado
e mouse. Em um determinado momento, um é o driver e o outro o navegador. Os
Os papéis se alternam a cada hora ou sempre que necessário. O motorista codifica, o navegador lê, verifica, faz a correção ortográfica e testa a sanidade do código, enquanto pensa nos problemas e no que fazer em seguida. Se o motorista tiver um problema, há duas pessoas para encontrar uma solução, e uma das duas geralmente tem uma boa ideia.Outras vantagens incluem o fato de que, quando duas pessoas têm
especialidades, essas habilidades são transferidas. O treinamento ad-hoc ocorre quando uma pessoa mostra à outra alguns truques, boas soluções alternativas, etc.O resultado final é que ambos os desenvolvedores estão totalmente cientes do código, como ele funciona e por que foi feito dessa forma. É provável que o código seja melhor do que o de um desenvolvedor trabalhando sozinho, pois havia alguém observando. É menos provável que
É menos provável que contenha bugs, hacks e coisas que causem problemas de manutenção mais tarde.Em uma equipe maior, o emparelhamento pode mudar a cada semana, de modo que cada membro da equipe faça parceria com alguém diferente. Essa é uma grande vantagem, pois faz com que os desenvolvedores conversem e comuniquem ideias na linguagem comum do código.
Descobrimos que isso é tão rápido quanto trabalhar separadamente. O código foi escrito
mais rápido e não precisava ser revisado. E quando era necessário mudar, mais de uma pessoa estava familiarizada com o código.
É um resultado animador. Eu aplaudo qualquer coisa que faça com que as equipes se comuniquem melhor.
Estou intrigado com a ideia de programação em pares, mas o Nunca vivi pessoalmente o estilo de vida da programação em pares. No entanto, gosto de trabalhar em estreita colaboração com outros desenvolvedores. Sempre que me sento para trabalhar lado a lado com um colega desenvolvedor, sempre absorvo alguns de seus truques e técnicas. É uma experiência de aprendizado rápido para ambos os participantes. Mas só fiz isso em pequenas doses. Tenho um pouco de receio de passar oito horas inteiras trabalhando dessa forma. Suspeito que isso pode ser cansativo em doses maiores, a menos que o senhor tenha muita sorte na escolha do parceiro de emparelhamento.
Eu escrevi sobre a eficácia das revisões de código anteriormente. Isso é algo com o qual tenho experiência pessoal; posso atestar sem reservas o valor das revisões de código. Não posso ajudar o me perguntando se a programação em pares nada mais é do que revisão de código com esteroides. Não que um substitua o outro – o senhor certamente poderia fazer os dois -, mas suspeito que muitos dos benefícios da programação em pares poderiam ser obtidos por meio de práticas sólidas de revisão por pares.
Mas as revisões de código também não são uma panaceia, como Marty Fried apontou:
Minha experiência com revisões de código tem sido mista. Um dos problemas parece ser que ninguém quer gastar tempo para realmente entender o novo código que faz algo não trivial, portanto, o feedback geralmente é muito geral. Porém, mais tarde, quando alguém está trabalhando no código para adicionar funcionalidade ou corrigir bugs, geralmente recebe muito feedback (às vezes envolvendo grandes martelos), mas aí pode ser tarde demais para ser eficaz; o programador pode nem estar por perto. Acho que pode ser útil ter um de qualquer forma, mas é difícil fazer com que um colega programador diga ao seu chefe que outro programador fez um trabalho ruim.
A vantagem da programação em pares é o imediatismo: é impossível ignorar o revisor quando ele está sentado bem ao lado do senhor. A maioria das pessoas opta passivamente por não participar se tiver a opção. Com a programação em pares, isso não é possível. Cada metade do par tem para entender o código, ali mesmo, no momento em que ele está sendo escrito. O emparelhamento pode ser invasivo, mas também pode forçar um nível de comunicação que, de outra forma, nunca seria alcançado.
Por outro lado, a revisão por pares é muito melhor do que empilhar corpos físicos na mesma área. Considere as experiências de Macadamian com a revisão de código enquanto trabalhava no projeto WINE:
Havia dois processos no projeto WINE com os quais não estávamos acostumados: revisões públicas por pares, em que novos códigos e patches eram distribuídos em uma lista de discussão para todos os envolvidos no projeto; e committer único, em que o líder do projeto tinha a palavra final sobre quais patches eram aceitos na árvore de código-fonte.
Logo descobrimos que Alexandre Julliard, que tem sido o mantenedor do WINE e um dos principais desenvolvedores desde 1994, era muito exigente quanto ao código que entrava na árvore de código-fonte. Os patches da nossa equipe eram examinados e, quando alguns eram rejeitados, havia muita reclamação. “Meu código funciona, quem esse senhor pensa que é? Estamos em um prazo!” Mas, à medida que o projeto avançava, percebemos que estávamos produzindo nosso melhor código de todos os tempos. Produzir um código limpo e bem projetado que foi admitido na árvore de código-fonte na primeira passagem logo se tornou uma questão de orgulho. Também descobrimos que, apesar de o projeto ser enorme e estar espalhado por todo o mundo, sabíamos exatamente como o projeto inteiro estava progredindo, pois víamos cada patch na lista de discussão. Agora, realizamos revisões de código em todos os projetos e, em projetos maiores, criamos uma lista de discussão interna e designamos um único committer. Pode ser doloroso configurar a revisão de código em sua empresa, e pode haver alguma reclamação, mas o senhor verá grandes melhorias na qualidade e na capacidade de manutenção do seu código.
Acho que ambas as técnicas são claramente uma rede bomembora cada um deles tenha seus prós e contras específicos. Incentivo as pessoas que têm experiência tanto com programação em pares quanto com revisões de código a compartilhar suas experiências nos comentários. Um é mais eficaz do que o outro? Devemos usar os dois?
No final, não acho que seja uma questão de escolher um em detrimento do outro, mas sim de garantir que o senhor tenha mais de um par de olhos observando o código que escreveuindependentemente de como o senhor decidir fazer isso. Quando seu código é revisado por outro ser humano, esteja ele sentado ao seu lado ou a milhares de quilômetros de distância, o senhor vai produzir software melhor. Isso eu posso garantir.