📓 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.