Pair Programming - Programação em Pares

Uma das práticas mais icônicas e controversas das metodologias ágeis é a programação em pares ou pair programming. Talvez as reuniões em pé sejam mais famosas, mas a adoção da programação em pares realmente é a que mais divide opiniões. A nossa intuição diz que colocar dois programadores para realizar a tarefa que um deles faria sozinho é desperdício, mas isso não é verdade, e no post de hoje vou explicar o porquê.

Querendo saber mais sobre métodos ágeis, recomendo após a leitura do post conhecer o meu livro sobre o assunto.

Como funciona?

Oriunda da metodologia ágil XP (Extreme Programming, do autor e engenheiro de software Kent Beck), a pair programming não é “apenas” dois programadores sentados e enquanto um programa o outro mexe no celular. Programar em pares requer disciplina, humildade e trabalho em equipe. As ideias de Beck foram uma forte influência para a cultura ágil no início dos anos 2000, tendo ele sido inclusive um dos 17 signatários originais do Manifesto Ágil, famoso por ser a “constituição” das metodologias ágeis.

Temos dois papéis aqui: o de motorista (driver no original), e o de navegador (navigator), semelhante ao que temos em ralis, onde um dirige e o outro dá instruções, controla a rota, etc. O motorista é o programador da rodada, ele fica com o teclado e mouse programando o que tem de ser feito, enquanto que o navegador (também chamado de observador/observer) dá sugestões, avisa de erros e espera a sua vez de programar, afinal, de tempos em tempos, os papéis devem se inverter.

Não existe uma regra clara de quando devem ocorrer essas trocas, e no caso do pair programming estar sendo usado para mentoring (ver adiante), essa troca pode nem ocorrer ou ser mais esporádica. Mas falarei disso mais pra frente.

Ok, imagino que você tenha entendido como ela funciona. A desvantagem óbvia é o custo de desenvolvimento, não há o que falar aqui, pesquisam indicam aumentos de 15% a 100% no custo de desenvolvimento.

Mas quais as vantagens?

Duas cabeças pensam melhor que uma

Essa expressão é bem antiga e nunca vi uma situação em que não seja verdade. Duas pessoas focadas em realizar uma tarefa intelectual produzem melhores resultados que apenas uma e isso também vale para programação. Por melhor que seja o desenvolvedor, sempre há um ponto de vista diferente que poderia ser explorado no código, um erro que passou despercebido ou mesmo uma forma melhor de fazer a mesma tarefa. Programadores tendem a trabalhar sempre da mesma forma, de maneira viciada, e colocar outro programador do lado ajuda a fazer com que eles compartilhem seus truques e modus operandi, gerando programadores ainda melhores na sua equipe.

Mesmo quando temos dois programadores de mesmo nível, sempre há troca de experiências e o nível de confiança é maior na solução sendo entregue, pois o sentimento de responsabilidade também é maior. No entanto, talvez o maior ganho do ponto de vista coletivo do time seja quando se colocam dois programadores com experiências distintas como um veterano e um novato (expert-novice no original) como falarei a seguir.

Mentoring

Falei de troca de experiências no tópico anterior, como uma forma de aumentar a qualidade dos programadores da equipe. Mas e se os programadores forem de níveis muito diferentes? Pair programming funciona neste caso? Aí é que funciona!

Simplesmente a melhor maneira de um programador aprendiz evoluir rapidamente para júnior é colocá-lo para programar junto de outro mais experiente (pleno ou sênior). Apenas mude um pouco a dinâmica: coloque o menos experiente com a mão na massa e o mais experiente dando as barbadas. Se nunca fez isso na sua empresa será uma experiência impressionante para você. O nome bonito disso é mentoring.

Programadores novatos tendem a perder muito tempo em coisas triviais por falta de experiência na profissão. Todo programador veterano sabe que deve usar e abusar do Google, e que não vale a pena tentar adivinhar como funciona alguma coisa, que é melhor perguntar pra alguém que já saiba ou buscar na Internet. Sites como o StackOverflow são o melhor amigo do desenvolvedor e devem ser usados à exaustão. Geralmente os veteranos possuem atalhos da IDE utilizada pela empresa que podem ensinar aos novatos para aumentar sua produtividade, sem contar que com a supervisão de um veterano, é possível dar tarefas mais interessantes aos novatos do que ficar fazendo programinhas que nunca serão usados.

Independente se você planeja aplicar pair programming ou não na sua empresa, você deveria testar mentoring (chamado de expert-novice no livro original), vale a pena e está acima de qualquer preconceito conservador que você possa ter sobre colocar duas pessoas para realizar uma tarefa.

Peer Review

Sabe aquela música do Capital Inicial que diz assim: “O que você faz quando, ninguém te vê fazendo?”, para os programadores existe apenas uma resposta possível: gambiarra! Isso não quer dizer que os programadores sejam incompetentes ou de má índole, apenas que eles são humanos. Quando não há uma vigilância tendemos a fazer as coisas de maneira mais prática e nem sempre do melhor jeito, inconscientemente. E aí que entra outro aspecto da programação em pares que você pode aplicar, o peer review, ou revisão em pares.

Se você nunca aplicou a técnica, não precisa começar hoje para ver os benefícios. Apenas diga a um desenvolvedor da equipe que você irá revisar o código dele mais tarde, para ver se está tudo ok. Apenas isso já será o suficiente para aumentar a qualidade do código produzido. Falo isso por experiência própria, pois aplico esse método com meus alunos de programação. No momento que o profissional sabe que seu código será revisado, ele passa a se preocupar mais com o fato de que outro terá de conseguir entendê-lo e terá vergonha de deixar alguma gambiarra ou algo fora do padrão para trás. Se ele deixar, ou é inexperiente ou é preguiçoso mesmo.

O peer review não é necessariamente programação em pares, como o próprio nome sugere, mas uma revisão que um programador X faz do código feito previamente por um programador Y, com a diferença que ele faz essa revisão junto do programador original, geralmente com ele explicando para o outro o que tinha na cabeça quando desenvolveu daquele jeito.

Novamente, pode parecer retrabalho ou desperdício, mas os ganhos de qualidade nas entregas são absurdos e a economia com manutenção posterior são grandes, uma vez que menos bugs e refatorações serão necessárias. Note que o objetivo aqui não é bancar o auditor ou botar no paredão aquele programador que você sabe que volta e meia dá umas “deslizadas”, mas sim ajudar o time a melhorar a qualidade do produto final.

Conclusões

Se você nunca tentou fazer atividades de programação em pares na sua equipe, vale uma tentativa. Comece com algo pequeno como mentoring ou peer review, antes de avançar com algo drástico como o pair programming full time. Dê uma lida no framework XP, muitas das técnicas pregadas por Kent Beck fazem mais sentido quando você olha o todo, ao invés do Pair Programming de maneira isolada, como o TDD, por exemplo. Você vai gastar mais no desenvolvimento? Sim. Mas o aumento na qualidade pode vir bem a calhar, principalmente em épocas turbulentas quando a qualidade do projeto não vai muito bem.

* OBS: curtiu o post? Então dá uma olhada no meu livro de Scrum e Métodos Ágeis e/ou no meu curso (abaixo) sobre o mesmo assunto!