Cinq façons de concevoir le pair programming

Paul-Yves Lucas
Jul 2 · 4 min read

Le pair programming est souvent cité comme un avantage. On le présente comme un bon moyen de progresser en équipe. Mais qu’est-ce que cette organisation implique réellement ?

Une mauvaise méthode de pair programming

De toute évidence, il ne s’agit pas d’une session de piano, d’un duo jouant simultanément sur le même clavier. Le pair programming peut être abordé de différentes façons, chacune avec ses avantages et ses défauts. Faisons le point ensemble dans cet article.

La dictée

Lorsque l’un des deux participants se révèle d’avantage expert sur la technologie utilisée ou le programme en lui-même, c’est à lui que revient naturellement le rôle d’énoncer les différentes étapes à effectuer. Il donne ses directives, un peu comme une dictée (ou une recette de cuisine).

Cette méthode s’avère utile pour présenter à l’intéressé une partie du code qu’il ne connaît pas, et plus généralement pour enseigner des méthodes aux profils plus juniors.

Le niveau de détail dicté peut évidemment varier. D’une simple explication des fonctions à implémenter au détail du code ligne par ligne, la dictée ne sera pas la même.

Pour accompagner ces instructions, il est recommandé d’en profiter pour faire une visite guidée du code. Par exemple en ouvrant différents fichiers, le mentor pourra expliquer les tenants et aboutissants des différentes méthodes. En particulier à l’occasion des premiers jours d’un nouveau junior, la session peut aller jusqu’à faire les commits et la pull request.

Le superviseur

Dans la même veine, mais avec une approche plus “apprentissage par la pratique”, le mentor peut prendre du recul en donnant juste les grandes lignes de la fonctionnalité. C’est alors au junior, qui écrit le code, de commenter son travail en expliquant ses choix. Le mentor pourra répondre aux questions, donner des conseils et éventuellement les solutions pour les problèmes les plus ardus.

Cette approche perd le côté visite guidée de la précédente, mais les leçons apprises seront probablement mieux retenues, au prix d’un rythme moins soutenu et peut-être d’un peu plus de stress chez certains. Elle a aussi pour autre bénéfice de mieux appréhender la façon dont un nouveau venu construit son image mentale du code et cherche des solutions.

Bien entendu, cette méthode peut se cumuler avec la précédente ou s’alterner selon le niveau de fatigue des participants. Il suffit seulement de bien garder en tête leurs bénéfices respectifs.

Le clavier tournant

Au premier abord, cette méthode peut sembler similaire aux précédentes. La distinction ? Toutes les 10 minutes, le clavier change de mains et les rôles tournent.

Cette méthode peut être utilisée lorsque les deux participants ont suffisamment confiance en la capacité de l’autre à résoudre un problème, ou qu’au moins tout le monde a les idées claires sur la façon dont un problème va être résolu.

La force de cette méthode ? Les deux participants remplissent deux rôles. On se retrouve avec virtuellement quatre paires d’yeux sur le code, ce qui devrait augmenter les chances de repérer les passages délicats et les résoudres plus aisément, tout en évitant la frustration de bloquer seul face à un problème.

La fonctionnalité en parallèle

Travail en parallèle

Quand on implémente une fonctionnalité qui peut être découpée facilement (back et front, modèle et service, deux classes filles différentes…), on peut parfois s’assoir à côté de son collègue, diviser le travail en deux et travailler en parallèle sur la même branche. Une bonne communication est alors la clé du succès, pour savoir qui fait quoi. Des commits réguliers assureront que tout le monde est à jour sur les parties communes dès que possible. Le but de cette méthode est plus d’augmenter la vitesse de développement que de partager des connaissances.

Mon avis sur cette méthode ? Je trouve qu’elle fonctionne mieux lorsque la différence de niveaux entre les participants n’est pas trop grande, mais surtout lorsque la fonctionnalité est claire et divisée proprement. Mon conseil : discutez longuement avant de commencer à procéder de cette façon, puis continuez à communiquer très régulièrement sur les avancées de chacun.

Le debug en tandem

Comme pour la méthode précédente mais avec un côté exploratoire, le debugging peut se faire en paire. Chacun a son environnement de développement opérationnel et va explorer indépendamment les différentes parties de l’application à la recherche de la cause exacte du bug. Cette méthode a l’avantage de permettre d’avancer plus rapidement sur plusieurs fronts en même temps, augmentant les chances de trouver la source du bug plus vite. L’implémentation du correctif pourra alors se faire avec une des méthodes précédentes si la situation s’y prête, sinon à vous de trouver qui va se charger de corriger le bug.

Conclusion

Il y a plusieurs façons d’aborder le pair programming, chacune avec ses propres bénéfices. On ne devrait pas se mettre à faire du pair programming par effet de mode, mais bien prendre en compte la situation pour choisir la méthode la plus adaptée.


Envie de tester ça avec nous ? On recrute !

https://jobs.captaincontrat.com/

Captain Contrat Tech

Blog technique de Captain Contrat

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade