BT
x A sua opinião é importante! Por favor preencha a pesquisa do InfoQ sobre os seus hábitos de leitura!

Como programação pareada funciona

por Lucas Souza em 26 Jan 2010 |

Stuart Wray escreveu em Janeiro de 2010 um artigo para a revista IEEE Software entítulado "Como programação pareada funciona".
Neste artigo Stuart nos mostra as várias abordagens seguidas pela programação pareada e nos ajuda a identificar uma maneira comum de a utilizarmos:

Minha experiência como desenvolvedor utilizando programação pareada é que ela não é apenas uma técnica onde uma pessoa programa e a outra pessoa assiste. Ambos programadores trabalham juntos, conversam o tempo todo, fazendo lembretes do que eles tem para fazer, e indicam pedaços de código na tela (um dos clichés da programação pareada é que, se você está fazendo ela de maneira certa, sua tela deve estar coberta com marcas engurduradas de dedos no final do dia). Programadores se revezam no teclado, geralmente trocando dizendo a seguinte frase, 'Não, deixe eu te mostrar o que eu quero dizer'

Com base na sua descrição sobre a programação pareada foi possível extrair quatro mecanismos que tornam a programação pareada de fato um verdadeiro sucesso.

Mecanismo 1: Conversa dos Pares de Programadores
Brian Kernighan e Rob Pike recomendam explicar os problemas em voz alta. Parte da eficácia da programação pareada é devido provavelmente a este efeito sendo continuamente desencadeado: Quando um programador se sente travado, o vai e vêm da conversa serve para destravá-lo da mesma maneira que programadores individuais falando sobre seus problemas em voz alta."
Ele também nos mostra os principais benefícios que as conversas trazem e nos sugere uma teoria que ele chama de "Teoria do Programador Expert" onde os membros do par entendem-se em relação à como os problemas informados são resolvidos de forma mais efetiva:

Esta é a maneira como realmente a "Teoria do Programador Expert" funciona: um expert é mais apto a fazer uma questão mais profunda, a qual induz o outro programador. Também parece possível que apenas pensando que você está falando com um expert, ajudará o programador travado à produzir perguntas profundas que foram perguntadas à eles pelos experts no passado


Resumindo o valor das conversas é muito importante quando utilizamos programação pareada.

O primeiro mecanismo portanto nos leva a profetizar que programadores que conversam mais sobre seus programas devem ser mais produtivos e que aqueles que levantam questões mais profundas para o outro devem ser os mais produtivos de todos

Mecanismo 2: Programadores pareados observam mais detalhes
Um dos bordões do desenvolvimento de software diz que "Você não vê seus próprios erros". Simplesmente as vezes não vemos nossos próprios erros por estarmos muito concentrado no problema a ser resolvido.

O que nós observamos depende do que esperamos ver e o que inconsientemente nos consideramos notável. Embora programadores em par bem sucessidos concentram-se nas mesmas coisas, eles podem notar coisas diferentes
Então, duas pessoas programando juntas não terão o mesmo conhecimento prévio: um provavelmente encontrará algumas coisas mais rapidamente e o outro coisas diferentes de maneira mais rápida. Onde a taxa de trabalho do par está limitada pela taxa que eles podem achar coisas, duas cabeças devem pensar melhor que uma. E de fato, umas das primeiras observações que as pessoas fazem quando começam a programar em pares é que as pessoas que não estão digitando sempre acham erros ortográficos mais rápido: "Olha, você esqueceu da vírgula aqui"

Ele também nos avisa sobre a fádiga que pode atingir o par, isto é, quando dois programadores programam juntos, as coisas que eles observam e as coisas que eles deixam de observar se tornam semelhantes. E com isso muitas vezes a programação em par passa a não surtir efeito. Ele diz que a fadiga entre os pares deve ser evitada efetuando a troca dos pares regularmente.

Alguns pares de programadores consideram a troca de pares como parte opcional da programação pareada, e em times pequenos, ou com poucos programadores dispostos a parear, pode ser uma alternativa. De qualquer maneira, a fadiga no par significa que eles serão pouco menos produtivos

Mecanismo 3: Combatendo práticas improdutivas
A
pressão da equipe para não utilizarmos más práticas é uma das mais eficazes técnicas da programação pareada. Ele cita o exemplo da programação "codifica e corrige" e relaciona isso com o jogo de máquinas caça níqueis.

Esta é a propriedade da programação interativa que torna díficil fazer a coisa certa. Com a técnica "codifica e corrige", cada vez que rodamos nosso código é como se colocassêmos uma moeda em uma máquina caça níqueis. Máquinas caça níqueis são uma das formas mais viciantes de jogos de azar, e as recompensas da programação "codifica e corrige" significa que ela poderia ser igualmente viciante.
Programadores pareados podem ser menos suscetíveis a práticas ruins porque eles podem prometer escrever código de uma determinada maneira e garantir que as promessas do outro serão mantidas e vice-versa. O predomínio de duas pessoas trabalhando em empregos onde a falibilidade humana é um problema sério deve nos levar seriamente a considerar que a pressão dentro do par pode ser uma solução para nós.

Mecanismo 4: Compartilhando conhecimento sobre coisas específicas
As diferenças de produtividade entre os indivíduos é muito ampla. Isso significa que as estimativas de tempo e dificuldade de uma determinada atividade são muitos difíceis de serem exatas. Isso é aplicável tanto para programadores bons quanto para programadores ruins. Você só pode de fato determinar a produtividade de uma pessoa quando você trabalha a algum tempo com ela.

Muitos programadores trabalham em seus próprios problemas, então nenhum deles sabe o quão bom (ou ruim) eles realmente são.
Mais na programação pareada, as pessoas trabalham continuamente juntas. Por eles manterem uma troca dos pares, todo mundo no time aprende quem são os mais experts em cada assunto. Desta comparação, eles também fazem idéia do seu nível de conhecimento sobre um determinado assunto. Devemos portanto esperar estimativas mais corretas de tempo e dificuldade do time dos programadores em par do que do time de programadores sozinhos. Da minha experiência, este parece ser o caso.

Quais técnicas e mecanismos fazem a programação pareada eficaz no seu caso?
InfoQ tem mais conteúdos sobre Programação Pareada aqui.

Olá visitante

Você precisa cadastrar-se no InfoQ Brasil ou para enviar comentários. Há muitas vantagens em se cadastrar.

Obtenha o máximo da experiência do InfoQ Brasil.

Dê sua opinião

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber mensagens dessa discussão

bacana by Felipe Rodrigues

Muito legal a dinâmica Lucas... pegou o jeito da coisa fácilmente. :)

Re: bacana by renan sales

Muito legal a matéria, pena que as empresas não dão importância para essa pratica (pelo menos a maioria delas).
As empresas acham isso perca de tempo, pensando que estão perdendo tempo e dinheiro, enquanto 2 programadores estão fazendo trabalho de 1.
Acharia legal se essa pratica fosse adotada onde trabalho mais acho que isso está bem longe de acontecer

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber mensagens dessa discussão

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber mensagens dessa discussão

2 Dê sua opinião

Conteúdo educacional

Feedback geral
Bugs
Publicidade
Editorial
InfoQ Brasil e todo o seu conteúdo: todos os direitos reservados. © 2006-2014 C4Media Inc.
Política de privacidade
BT