Programação Pareada

O processo de programação pareada (em pares) é uma metodologia de trabalho defendida pelo eXtreme Programming (XP). Como o nome refere, cada unidade de programação é constituída por dois programadores num único computador. Poderemos incorrer no erro de pensar que é um desperdício de capacidade humana, uma vez que estão dois elementos a realizar o trabalho de um. No entanto esse pensamento não poderia estar mais afastado da realidade.

É expectável que uma equipa pareada produza a mesma quantidade de código que seria de esperar de dois programadores individuais, no entanto com a mais valia do código ter maior qualidade. Num artigo anterior escrevi sobre a importância e o papel da revisão de código no desenvolvimento de software. Processo que também consome tempo no presente mas que nos permite ganhar tempo no futuro através da maior maturidade e qualidade do código que seguirá para produção. Se se optar pela metodologia da programação em pares, poder-se-á presumir que a revisão de código já estará presente no código desenvolvido pela dupla de programadores.

Cada um dos programadores terá um papel específico – o “condutor” e o “navegador”.

Isto é, um escreve código enquanto o outro lê e antecipa situações. O melhor entrosamento verifica-se quando o teclado passa de um para o outro, sem que nenhum dos elementos esteja agarrado ao seu papel pre-estabelecido. Como se poder constatar, programação em pares tem tanto de soft-skills como de technical skills. Não é fácil para um programador aceitar a opinião de um par antes de testar a sua opinião. Como todas as demais soft-skills, é possível desenvolvê-la mas que requer tempo e abertura da parte do indivíduo.

“Já que vou ter de colocar dois programadores juntos, o melhor é colocar um sénior junto com um júnior, assim ele vai poder aprender”.

É preciso muito cuidado com este pensamento. A relação de mentoria é diferente da relação entre pares. Se efectivamente se pretende que a produtividade não diminua, a equipa deverá ser constituída por programadores competentes e já numa fase em que são totalmente autónomos.

Existem empresas que optam até por definir os papeis como “programador” e “tester”, ou seja, o “programador” irá escrever código para os testes unitários desenvolvidos pelo “tester”. Estes papéis vão sendo trocados e chegam mesmo a trocar no próprio dia. Como se pode compreender, seria completamente impossível de o fazer se os dois elementos não estivessem no mesmo nível de autonomia e conhecimento.

Outra indicação que o eXtreme Programming nos dá, “mover as pessoas”. É importante que as equipas pareadas sejam trocadas regularmente. Com isso iremos prevenir o aparecimento de “ilhas de conhecimento”, que de futuro nos poderá encaminhar para uma dívida técnica caso os detentores do conhecimento decidam sair da empresa – fenómeno tão temido por qualquer gestor tecnológico.

Assim se percebe que aliando a programação pareada a uma rotação interna de programadores obtemos maior:

  • fluxo contínuo de desenvolvimento e entrega,
  • disseminação de conhecimento da base de código do projecto,
  • qualidade no código produzido,
  • diminuição de possíveis dívidas técnicas.