InfoQ

InfoQ

Notícias

Meus Favoritos

Faça oLogin ou Cadastre-se para ativar o recurso de favoritos por tempo ilimitado.

O conteúdo foi adicionado aos favoritos!

Houve um erro ao adicionar aos favoritos! Por favor, tente novamente.

Como programação pareada funciona

Postado por Lucas Souza em 26 Jan 2010

Seções
Processos e Práticas
Tópicos
Agile ,
Técnicas Ágeis
Tags
Pair Programming

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.

bacana por Felipe Rodrigues Enviado
Re: bacana por renan sales Enviado
  1. Voltar ao topo

    bacana

    por Felipe Rodrigues

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

  2. Voltar ao topo

    Re: bacana

    por 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

Conteúdo Educacional

Formando equipes de alto desempenho, parte 1: Início e fases de evolução

Nesta primeira parte de uma série sobre equipes de alto desempenho e gerenciamento Agile, veja uma introdução geral e uma apresentação dos estágios de formação das equipes.

Business Model Canvas, passo a passo

O Business Model Canvas é uma ferramenta estratégica para a construção visual de novos produtos ou serviços. Conheça cada um dos seus elementos e como preencher o Canvas, passo a passo.

Google Apps Script, Parte 2: Google Docs, triggers e envio de emails

Nessa segunda e última parte de uma série sobre o Google Apps Script, conheça como funciona o envio de emails, a conversão de documentos e como criar menus e triggers.

Serviços de cloud computing PaaS: um guia para desenvolvedores Java

Este artigo avalia seis dos mais importantes fornecedores de serviços de cloud computing PaaS para desenvolvedores Java, analisando critérios como desempenho, escalabilidade e tecnologias suportadas.

Canvas de Modelo de Negócios: uma contribuição para o sucesso de Startups

O Canvas de Modelo de Negócios é um novo modo de comunicar e suportar a validação iterativa, incremental e empírica de modelos de negócio de startups e novos produtos substituindo o plano de negócios.

Entrevista com Rebecca Parsons Parte 2: Agile Distribuído, Arquitetura vs. Design e SOA

Nesta segunda e última parte de uma entrevista exclusiva para InfoQ Brasil, Rebecca Parsons, CTO da ThoughtWorks, fala sobre o Agile Distribuído e técnicas para definição de arquiteturas.

Entrevista com Rebecca Parsons Parte 1: Agile nas Empresas e Arquitetura Evolucionária

Nessa primeira parte de uma entrevista com a CTO da ThoughtWorks, veja recomendações sobre formas de construir e arquitetar sistemas para obter o máximo de flexibilidade e responsividade a mudanças.

Agile das equipes à organização: o papel do gerente, estratégias e dicas para a adoção

Os gerentes de projetos podem assumir o papel crítico de liderar a introdução do Agile. Vejas conceitos, dicas e técnicas para apoiar esse processo de mudanças.