Pair Programming/Code Review

"Duas cabeças pensam melhor do que uma."

Acho que essa frase, cujo autor eu desconheço, reflete a essência da programação em par (pair programming). Não vamos chover no molhado aqui explicando o conceito que é melhor descrito aqui, aqui ou aqui.

Os prós da programação em par (código com melhor qualidade, em parte devido a maior atenção do programador quando sob o efeito de outro par de olhos, aprendizado e troca de experiência, etc, etc) puderam ser sentidas com a pequena experiência que alguns desenvolvedores tiveram ao adotarem esta prática em algumas tarefas.

Agora a pergunta que não quer calar é se estamos fazendo programação em par de forma sistemática. Bom a resposta é não. "Mas como ? Você acabou de dizer que programação em par é uma ótima técnica. É bom ou não ?". Deixe explicar.

Primeiro em "um ambinte Scrum" a democracia é fundamental. Sem este preceito as pessoas não se envolvem não sentem-se estimuladas a agir e por melhor que seja uma idéa a probabilidade de ela fracassar por causa deste "fator humano" é grande.

Como não "votamos" o uso da programação em par (devido ao tempo de apresentar a ideia seus preceitos básicos etc etc) os próprios integrantes do time se encarregaram eles mesmos de utilizarem esta técnica quando acharam conveniente. Mesmo sem saber que o que estavam fazendo era pair programming.

Respondendo a pergunta a programação em par é usada quando o time acha necessário e os motivos são: aprendizado(um programador tem um skill que pode auxiliar outro na realização da tarefa), qualidade do código (dois desenvolvedores tem tarefas semelhantes logo resolveram executar as duas tarefas juntos).

Mas mesmo com essa liberdade no uso ou não da programação em par tentamos sempre fazer uso da revisão do código(ok ok, isso não foi votado mas espero não ver nenhuma rebelião por causa disto ... o que é isso lá fora tochas, uma fogueira ???) e não exite um revisor fixo (tá bom eu confesso as vezes eu reviso). A revisão não tem o intuito de desqualificar o código sendo revisado. A intenção é que revisor e o autor do código entrem em consenso sobre o melhor caminho para boas práticas de codificação e código de qualidade. Ambos aprendem e todos ganham. Bom essa é a intenção quem pode falar se estamos conseguindo este objetivo é o time (não vou pressionar ninguém a falar algo positivo sobre este artigo mas sabem aquelas férias na Disney de que falei ? Pois é, o primeiro que falar que o que escrevi é metira pode dar adeus as férias).

"Conhece-te a ti mesmo".

P.S: Como esse artigo tá muito sério resolvi citar Sócrates. :-D