📓 Le pair programming

☝️Cet article fait partie de la série “📓 Trucs & astuces à l’usage des jeunes développeurs web”

Le pair programming, comme son nom l’indique, est l’action de coder à deux : l’un des développeurs tient le clavier et code, pendant que l’autre lit et participe à l’écriture du code.

Dit comme ça, ça a l’air extrêmement contre-productif, deux personnes qui font le boulot d’une, c’est pas vraiment rentable…

Haha… non, allez, faites un effort, à Hollywood…

C’est ce que je pensais aussi avant de m’y essayer.

D’abord, le pair programming n’est pas systématique, mais devrait être régulier : une fois par semaine, par exemple. Ensuite, et c’est logique, les rôles doivent s’inverser régulièrement.

L’utilisation régulière du pair programming dans une équipe apporte énormément d’avantages…

Renforcement de la cohésion de l’équipe

Bon, d’accord, c’est pas forcément systématique, mais quand même, ça joue.

Confrontation / mise en commun des idées

Deux développeurs ne pensent jamais de la même façon, et confronter ces idées avant d’écrire le code est le meilleur moment pour le faire.

Augmentation de la couverture du code

Dans un projet en équipe, si une personne est l’auteur d’une grand partie du projet et vient à s’absenter (maladie, vacances, départ), il faut du temps au reste de l’équipe pour se réapproprier ces parties du projet. Le pair programming tend à réduire les parties de codes couvertes par une seule personne.

👌 le paramètre d’importance d’un développeur dans une équipe est aussi appelé le bus-factor, synthétisé par la phrase “et si untel venait à passer sous un bus, à quel point ce serait le bordel pour le projet” (on ne parle pas du facteur humain, qui est toujours négatif — je ne souhaite à personne de passer sous un bus, c’est lourd, un bus). Il est vital dans une équipe de réduire au maximum le bus-factor de chacun, le pair programming étant une bonne manière d’y contribuer.

Rapport apprentissage / performance

Le pair programming est aussi une formidable méthode d’apprentissage interne dans une équipe, que je vais illustrer par un exemple :

Il y a peu, dans une équipe où j’avais un rôle de lead developper, nous avions une tâche dans notre backlog qui consistait à régler un problème visuel en implémentant un système de préchargement d’images.
Objectivement, dans le contexte et avec l’expérience, j’en aurais eu pour vingt minutes, douche comprise. Or, nous avions une nouvelle recrue dans l’équipe à ce moment et mettre en place un tel système était à la fois quelque chose qu’il n’avait jamais eu l’occasion de faire et qui n’est pas forcément simple à mettre en place.
Le hic, c’est que dans le même ordre d’esprit, s’il avait du le faire tout seul, je pense qu’il en aurait eu pour une bonne demi-journée, voire une journée entière. Ça n’aurait pas forcément été mauvais pour lui, mais c’était un peu contre-productif par rapport à ma planification.
Du coup, on a planifié une séance de pair programming, avec ma recrue au clavier et moi à côté de lui. Je l’ai laissé travailler en le guidant dans la bonne direction, en lui laissant volontairement faire les erreurs prévisibles pour plus facilement lui montrer comment y pallier.
On en a eu pour 45 minutes, un compromis vraiment acceptable entre les deux évaluations.

Bref, le pair programming, c’est bien, mangez-en.