Ping pong pair programming kezako ?

Je ne saurais donner l’origine exacte de cette méthode/exercice. Nous en avons une référence sur le Wiki : http://wiki.c2.com/?PairProgrammingPingPongPattern ainsi que dans le livre The Clean Coder de Robert C. Martin.
Pour réaliser une séance de ping pong pair programming, il s’agit de suivre le processus suivant :

• A écrit un nouveau test et vérifie que ça échoue
• B implémente le code voulu pour faire passer le test
• B écrit le nouveau test et vérifie que ça échoue
• A implémente le code voulu pour faire passer le test

Il est facile de repérer que nous mixons là deux pratiques : celle du Test Driven Development (TDD) et celle du pair programming dans un jeu de ping pong.
Pour certains, il s’agit d’un exercice à faire pour s’entraîner et pratiquer un peu de TDD ou de pair programming. Pour d’autres, il s’agit de la seule et unique manière valable de faire du pair programming.
Les avis divergent et on peut alors se demander où est le vrai dans tout ça.
J’ai personnellement pratiqué ce concept comme exercice et l’ai vu pratiqué par d’autres toujours comme exercice lors d’un meetup au Software Craftsmanship de Lyon.
Je ne sais donc pas quels sont les résultats qu’on peut obtenir dans un vrai projet.
Cependant, en tant qu’exercice, les bienfaits que j’y vois sont les suivants :

• Nouvelle manière de pratiquer le TDD :

En effet, c’est une manière d’apprendre ou réapprendre le TDD et de voir en équipe comment le mettre en place

• Nouvelle manière de pratiquer le pair programming dans un jeu dynamique où les deux personnes sont contraintes de rester actives au moins à tour de rôle

En effet, un des problèmes qui peut survenir lors d’une séance de pair programming, c’est le fait qu’une des personnes relâche son attention. La séance de pair programming perd de son intérêt puisqu’une seule personne continue à être active. Le fait d’obliger les deux membres à participer activement (mains au clavier) à la construction du code oblige à rester dans une certaine dynamique. Comme le souligne le Wiki, cela permet aussi de déceler plus rapidement les “blackouts”.
Personnellement et étrangement, j’ai aussi ressenti un détachement au moment où l’autre rédige un test ou élabore une portion de code. C’est dommage puisque l’idée du pair programming c’est de rester à l’écoute et d’être à même de prendre du recul pour repérer ce qui ne va pas dans ce que réalise son pair.

• Une manière de pratiquer la programmation par intention

En effet, j’ai personnellement pratiqué l’exercice en discutant avec mon partenaire. Cependant, j’ai vu des personnes le prendre dans un autre sens que j’ai trouvé intéressant : le pratiquer en silence. Ainsi, les tests rédigés doivent être explicites pour que le deuxième membre puisse y répondre avec ce qui est attendu. De la même manière, puisque le code est aussitôt repris par l’autre, celui-ci aussi doit être clair et manifester directement ses intentions.

• Une nouvelle manière de pratiquer le refactoring

En effet, le processus définit la phase de test, la phase de code, mais pas celle de refactoring. L’exercice oblige donc à se demander comment refactorer. Il y a plusieurs stratégies. Certains vont décider que chaque membre s’en charge à tour de rôle. Personnellement, avec mon partenaire, nous avons décidé de réaliser cette tâche ensemble, ce qui nous obligeait à revenir ensemble sur ce que chacun avait réalisé.
La méthode a certes des bienfaits. Alors pourquoi ne pas l’utiliser en projet ? Un développeur m’a dit la mettre en place pour former les nouveaux arrivés et que c’était assez efficace. Personnellement, je ne l’ai jamais fait. Je vois plusieurs freins à une concrète mise en place dans un projet :

• Un des deux participants a minima doit maîtriser le TDD
• Les participants doivent être d’accord avec cette manière de développer
• Et si on garde l’attention des membres de manière au moins intermittente, il s’agit aussi de la garder de manière constante pour que le pair programming ne perde pas son aspect de relecture continue au fur et à mesure de l’écriture du code

En conclusion, même si je vois des difficultés quant à l’utilisation de cette méthode dans un contexte projet, je pense qu’elles ne sont pas insurmontables et je trouve l’approche très intéressante en tant qu’exercice.