Motivações para a programação em par

03/03/2015

Como programador gosto de explicar os entraves do meu dia a dia para pessoas de áreas distintas da minha. Embora raramente eu receba uma solução, o simples fato de explicar o problema em voz alta acaba me levando a vê-lo com outros olhos e consequentemente resolvê-lo. Esse costume pode ser comparado a uma técnica mencionada por John Sturdly e abordada por Brian Kernighan e Rob Pike no livro Practice Programming, que consiste em externalizar sua linha de pensamento para um objeto inanimado, como um pato de borracha ou um objeto de decoração qualquer.

Um bom sotware surge a partir da intercalação entre as atividades de codificação propriamente dita e entendimento do problema. Embora a codificação seja a atividade mais evidente, mais de dois terços do tempo de um programador é usado na análise, e ao verbalizar a linha de raciocínio, o profissional acaba por encontrar falhas ou novos insights que de outra forma não faria.

Pensar em voz alta é um princípio da programação em par

No contexto da programação em par a exposição do raciocínio em voz alta é essencial, levando a técnica descrita anteriormente a um outro nível, deixando de ser apenas a explicação de um problema e se transformando em um diálogo a respeito.

Uma das motivações à programação em par é a solução dos momentos onde o programador se sente preso a um problema, muitas vezes levando horas para resolvê-lo. Ele possui o conhecimento e a habilidade, porém têm dificuldades para relacionar todas as facetas à resolução de um algoritmo. Normalmente esses relacionamentos acontecem em momentos aleatórios por meio de um insight que o leva a interligar todos os pontos e resolver o problema.

Creio que todas as carreiras analíticas acabam tendo problemas similares. Normalmente este insight chega durante conversas. Não é preciso ela ser a respeito do seu problema, as vezes uma conversa trivial leva a resolver uma adversidade naturalmente. Tudo se resume em fazer a pergunta certa. Talvez, esse seja o motivo a levar professores aprender tanto quanto seus alunos.

Aprender é uma atividade solitária por sua natureza, considerando como "aprender" o ato de absorver novos conhecimentos. Porém o estudo acaba sendo coletivo, desde crianças aprendemos em turmas, onde todos compartilham de um mesmo aprendizado. Pense na última vez que você viu outra pessoa levantar uma questão em turma. Talvez aquela não era a sua questão, mas o levou a pensar de formas não avaliadas anteriormente. Talvez, inclusive a fazer novas perguntas.

Aprenda ensinando, conheça novos pontos de vista

Uma das coisas que mais valorizo neste tipo de desenvolvimento é poder experimentar diferentes estilos de desenvolvimento e validar o meu próprio. Saber a opinião de outro profissional sobre a forma como você trabalha é tão importante quanto a um autor saber o que sua audiência pensa do seu livro. Claro, a menos que você esteja escrevendo para você mesmo. Do contrário, existe uma grande chance de no futuro outro profissional precisar fazer modificações no seu trabalho.

Se ninguém nunca opinou sobre seu estilo de programação, não existe como saber se está fazendo realmente um código fácil de ser mantido. É importante lembrar: para se caracterizar como de fácil manutenção, ele precisa poder ser alterado por outra pessoa. Ao escrever cada linha e ter alguém questionando o motivo daquela linha existir, você estará criando constantemente um código mais fácil de atualizar. Paul Graham diz em seu trabalho "Great Hackers" que apenas trabalhando lado a lado com outro programador é possível julgar sua experiência.

Na minha opinião, este último ponto seria suficiente para justificar a programação em par. Sendo impossível julgar sua habilidade pela sua própria experiência, a programação em dupla fornece um meio eficaz de se avaliar perante outros da sua área.

No mundo empresarial isso é chamado de benchmarking, e é essencial para se medir o quanto a empresa conquistou e o quanto ela ainda pode conquistar, da mesma forma que se você pretende evoluir como profissional, é preciso saber onde você está hoje em comparação aos seus pares, para traçar seu alvo e se motivar a alcançá-lo. Porque peixe parado, é peixe morto.