A programação em par é uma prática um tanto quanto controversa, e altamente ágil contra-intuitiva. Em poucas palavras, são duas pessoas que trabalham na mesma coisa, usando apenas um computador, ao mesmo tempo. Parece loucura que isso funcionaria de fato, muito menos ser melhor do que dois programadores trabalhando separadamente. Mas de alguma forma ela funciona.
Estamos usando essa técnica há algum tempo, e tenho notado alguns benefícios interessantes que gostaria de compartilhar.
Eliminando dialetos
Se você pedir a 10 pessoas para escrever um pequeno parágrafo sobre uma ideia específica, provavelmente receberá 10 resultados muito diferentes. De fato, isso provavelmente seria verdade mesmo se você tivesse especificado exatamente o que queria que a pessoa escrevesse (tudo – desde quantas frases deveriam ser utilizadas até as estruturas gramaticais permitidas).
O mesmo vale para os programadores. Os devs possuem seus próprios estilos de escrita de código, não importa a linguagem. Eles diferem em nomes de variáveis e nomes, preferências para construções específicas de fluxo de controle, comentários de estilos etc. Resumindo, os devs possuem seus próprios dialetos.
Esses dialetos são especialmente perceptíveis quando um único dev trabalha exclusivamente em uma parte específica de uma grande base de código. Ler módulos diferentes em um código fonte é como ir a uma excursão no campo e ouvir tudo com sotaques diferentes.
Claro, existem coisas que você pode fazer para tentar minimizar essas diferenças (coisas como padrões de codificação e convenções de nomenclatura). No entanto, acho que a maioria dos devs tem dificuldade em seguir as convenções de nomenclatura quando são deixados à sua própria sorte. É muito fácil recorrer ao seu dialeto quando ninguém está olhando.
Comece a trabalhar em par (pairing). O pairing é quase surpreendentemente eficaz em eliminar dialetos de dev e em obter um código inteiro para ler a base como se fosse escrito por um único programador. Aparentemente, é muito mais difícil injetar seu próprio estilo no código quando alguém assume o teclado a cada poucos minutos.
Reduzindo a complexidade
Muitos devs amam a complexidade. Mais perturbador, muitos se sentem obrigados a, desnecessariamente, introduzi-la no código que escrevem. O mais preocupante de tudo é que poucos têm a autoconsciência para perceber o que estão fazendo antes que seja tarde demais. Então, os códigos fontes em todos os lugares estão repletos de versões diferentes de uma máquina de Goldberg.
O fato é que, quando o código está apenas na sua cabeça, ele normalmente parece muito simples. As condições de limites e os casos extremos são examinados rapidamente, saltos esquisitos de lógica não parecem tão estranhos, as construções complexas parecem simples, e assim por diante.
A programação em par te obriga a explicar suas ideias de design aparentemente racionais para outro ser humano. Na maioria das vezes, o próprio ato de explicar para alguém o ajuda a perceber que algo está errado. E, se isso não o faz, um olhar intrigado ou um cético “OK…” do seu par provavelmente o fará.
Pensamento final
As duas razões mais comumente aceitas para programação em par são promover propriedade compartilhada e forçar revisões de código contínuas. São benefícios importantes com certeza, mas a programação em par também ajuda de outras maneiras. Você já notou algum que você gostaria de compartilhar?
***
Texto original disponível em http://tatiyants.com/benefits-of-pair-programming/
Fonte: iMasters
Diego Macêdo
Sou bacharel em Sistemas de Informação pela Estácio de Sá (Alagoas), especialista em Gestão Estratégica da Tecnologia da Informação pela Univ. Gama Filho (UGF) e pós-graduando em Gestão da Segurança da Informação pela Univ. do Sul de Santa Catarina (UNISUL). Certificações que possuo: EC-Council CEH, CompTIA (Security+, CySA+ e Pentest+), EXIN (EHF e ISO 27001), MCSO, MCRM, ITIL v3. Tenho interesse por todas as áreas da informática, mas em especial em Gestão e Governança de TI, Segurança da Informação e Ethical Hacking.