Programação em par é uma prática utilizada por times que adotam o Extreme Programming (XP). É uma prática polêmica, que diz que todo o código produzido por um time deve ser produzido em duplas.
Quando há olhos suficientes, todos os erros
são óbvios
- Eric S. Raymond
Em um primeiro olhar, a impressão é que é uma prática fadada ao fracasso, uma vez que parece ser uma prática que estimula o desperdício, mesmo podendo apresentar alguns benefícios. Não parece ser lógico dobrar o gasto para execução de uma tarefa.
Trabalho em par
Toda pessoa que já fez uma viagem de avião sabe que a aeronave possui um piloto e um co-piloto. Na prática, o piloto é perfeitamente capaz de realizar o voo sozinho, no entanto, alguém teria coragem de entrar em um avião sem um co-piloto? O que aconteceria caso o piloto tivesse algum problema, ou mesmo cometesse um erro durante o voo?
O princípio da programação em par é justamente esse. Duas pessoas, juntas, trabalham melhor do que duas pessoas isoladas.
Como funciona
Durante a implementação, um programador age como piloto (digitando o código) e outro age como co-piloto (revisando o que está sendo digitado, apontando problemas e pensando na solução como um todo).
A cada determinado ciclo de tempo, os profissionais invertem os papéis. Dessa forma o piloto passa a ocupar o papel de co-piloto e vice-versa.
Vantagens
Até aqui, nada parece justificar o investimento de ter duas pessoas realizando a mesma tarefa, afinal, desenvolvimento de software não envolve tantos riscos quanto aviação.
No entanto, a programação em par traz diversas vantagens a todos os envolvidos:
Compartilhamento do conhecimento
Como todo o código produzido é visto por, pelo menos, duas pessoas é menor o risco de existir a figura do “responsável pelo código do produto X”. O conhecimento pode ser ainda mais compartilhado, principalmente se os pares forem revezados com frequência.
Isso é, obviamente, bom para o projeto. Mas também é muito bom para os desenvolvedores. Afinal de contas, é comum desenvolvedores que não podem tirar férias pois caso contrário o projeto onde eles trabalham não pode ser mantido.
Ser o responsável único por determinado projeto, ou parte dele, quase sempre é um fardo pesado demais que faz com que o desenvolvedor seja levado ao esgotamento.
Correção de falhas
Com duas pessoas olhando o código, as falhas e erros de lógica são detectados (e corrigidos) mais cedo. Isso faz com que o trabalho seja mais fluído, uma vez que é mais difícil aquela situação onde o programador perde horas realizando o debug do código para encontrar uma falha de lógica, por exemplo.
Manutenibilidade
Um código escrito à quatro mãos é, naturalmente, mais simples de sofrer manutenção. Afinal de contas, durante a escrita do código sua clareza já estava sendo testada pelo co-piloto, que questionará sempre que não entender determinado trecho.
Confiança
Como o código é desenvolvido em pares, os desenvolvedores tem mais confiança no resultado final, uma vez que ele foi validado por, pelo menos, mais uma pessoa.
Os possíveis erros e problemas também são divididos, o que faz com que o time como um todo passe a enxergar o código como propriedade coletiva. Nesse formato, todos estão sempre dispostos a ajudar, pois o sucesso ou fracasso pertencem a todos os membros da equipe.
Amadurecimento
Trabalhando em pares, os profissionais amadurecem a sua forma de trabalhar. Em times com profissionais mais experientes mesclados com profissionais menos experientes, o pareamento faz com que essa experiência seja transferida diretamente, na resolução de problemas do dia a dia. Dessa forma, os profissionais menos experientes tem uma curva de aprendizado reduzida.
Na programação em par ocorre o chamado aprendizado situado. Existe um problema real a ser resolvido, com a complexidade padrão do projeto, e com todas suas restrições.
Durante o ciclo de desenvolvimento há uma constante relação aluno-professor entre o par, sendo que esse papel é constantemente revezado de acordo com o nível de conhecimento de cada um no caso específico.
Mesmo quando ambos não sabem como resolver o problema, a pesquisa se torna mais eficiente e eles podem validar as ideias em conjunto, o que faz com que normalmente a solução encontrada seja mais confiável.
Pressão do Par
Essa talvez seja uma das maiores vantagens da programação em par, principalmente do ponto de vista das organizações.
Um programador com carga horária de, por exemplo, 8 horas por dia passa boa parte desse tempo disperso em outras atividades (e-mails, mensagens instantâneas, mensagens no celular, telefonemas, conversas, etc.).
Além disso, como o trabalho de programação é algo que envolve atividades muito complexas, durante o dia é comum que o desenvolvedor faça pausas em seu trabalho, para descansar a mente e voltar à carga.
Isso sem contar com o tempo gasto na procura por problemas, debugando código para encontrar defeitos ou a causa de comportamentos inesperados.
Quando há uma outra pessoa junto fazendo o trabalho, a tendência é que o desperdício de tempo diminua consideravelmente. Qualquer pessoa fica constrangida ao acessar e-mails, mensagens instantâneas ou mesmo atender celular na presença de terceiros. Além disso, como o trabalho é compartilhado, há um maior sentimento de compromisso e ninguém gosta de ser responsável pelo fracasso de outro.
Quanto ao descanso periódico, que é realmente necessário, ele ocorre naturalmente quando o par troca de função. (O co-piloto descansa, porém continua envolvido no sucesso da tarefa).
A quantidade de tempo gasto na busca por defeitos também diminui radicalmente, uma vez que o co-piloto alerta para os defeitos durante o desenvolvimento. Mesmo no caso onde essa busca seja necessária, em duas pessoas o tempo tende a ser bem menor.
Com isso, é seguro afirmar que a pressão do par faz com que os dois desenvolvedores produzam juntos uma quantidade de trabalho maior do que produziriam isolados, mesmo somando o trabalho dos dois ao final do dia.
Velocidade
As vantagens apontadas acima levam, naturalmente, a um aumento na velocidade de desenvolvimento do time.
Um código com menos bugs, onde as soluções são discutidas e há a pressão do par para que o resultado saia, faz com que as soluções fiquem prontas mais rapidamente e com mais qualidade.
Além disso, a inserção de um novo membro no time também é facilitada, uma vez que todos tem o hábito de compartilhar conhecimentos e construir soluções em conjunto.
Dificuldades
Existem, é claro, algumas dificuldades para a adoção da programação em par. A primeira delas diz respeito a personalidade os desenvolvedores envolvidos.
Eles devem entender que o código produzido é coletivo, e não sua propriedade. Devem também aceitar sugestões e críticas ao seu trabalho, entendendo que isso decorre do fato de a propriedade do código ser coletiva.
Outra grande dificuldade é convencer “quem paga a conta” que vale a pena. No entanto, isso pode ser feito utilizando-se a prática. Realizando alguns experimentos com programação em par, comparando o resultado com programação solo, normalmente chega-se a conclusão de que a programação em par é extremamente vantajosa.
Dicas para trabalhar em par
Pode até não parecer, mas trabalhar em par não é tão simples assim. Algumas dicas podem ajudar os times a trabalharem em pares:
Entender como as pessoas trabalham
Para trabalharem juntas, as pessoas devem entender e respeitar a forma como cada uma delas faz as coisas. Isso deve ser explicitado por todos, de forma que não hajam dúvidas e equívocos no momento do pareamento. Por exemplo, existem pessoas que gostam de trabalhar com diagramas, outras preferem analisar o código antes de iniciar. O importante aqui é que o par esteja consciente da forma de cada um trabalhar, e consiga montar um esquema de trabalho para ele.
Realizar trocas de pares frequentes
É importante que os pares sejam trocados com certa frequência. Isso pode ser feito a cada sprint, a cada dia, a cada turno, essa frequência deve ser definida pelo time.
É importante pois as pessoas são diferentes, cada uma possui conhecimentos e habilidades diferentes das demais. A melhor forma de garantir um bom entrosamento e uma boa transferência de conhecimento é misturando-as.
Todos devem saber porque estão trabalhando em par
Não basta que os desenvolvedores estejam em pares. Eles devem saber porque trabalham em par, e tirar o máximo proveito dessa situação. Buscar novas formas de resolver os problemas, compartilhar as soluções, realizar revisão de código e conversar. Essas práticas devem fazer parte da alma do par, sendo executadas o tempo todo.
Espero que com esse artigo tenham ficado claros os benefícios da programação em par. Sei que o tema é bem polêmico, no entanto é algo que vale a pena ser pelo menos experimentado. Afinal de contas, uma prática tão controversa não teria tantos defensores caso não apresentasse resultados.
Dúvidas ou complementos ao assunto são bem-vindos nos comentários. Um abraço.
