Pair programming : coder en binôme, bonne ou très bonne idée ?

La programmation en binôme, plus connue sous le nom de pair programming est une méthode agile de développement logiciel où deux développeurs ou développeuses travaillent ensemble sur un même poste. Cette collaboration permet de partager les connaissances, et de surmonter les obstacles plus rapidement qu’en solo. Certaines organisations sont toutefois encore bien sceptiques quant au pair programming, considéré comme une utilisation inefficiente des ressources… Alors, bon plan ou perte de temps la programmation à deux ?

(indice : la réponse est dans le titre !)

Sommaire

1. Qu’est-ce que le pair programming ?
2. Avantages et inconvénients de la programmation à deux
3. Comment commencer à pair programmer dans votre entreprise ?

Qu’est-ce que le pair programming?

La programmation en binôme, qu’on appelle aussi parfois binômage ou programmation par pairs a été popularisée dans les années 90 grâce à l’eXtreme Programming. Issue des bonnes pratiques XP, elle consiste donc à faire collaborer deux devs sur un même PC. L’un rédige le code, c’est le conducteur (ou driver), tandis que l’autre observe et effectue une revue de code en direct, c’est le navigateur.

C’est un peu le même principe qu’un rallye automobile, avec un pilote et un copilote : le driver tient le clavier et la souris (le volant et les pédales), pendant que le navigateur lui donne des indications pour franchir les difficultés du parcours. En pair programming en revanche, les rôles sont inversés régulièrement, selon un rythme déterminé à l’avance.

A noter que le rôle de navigateur n’est pas passif. Au contraire, il ou elle aide le conducteur à chaque étape, à voix haute, et propose des améliorations ou des approches différentes quant au problème à résoudre. L’idée n’est pas de développer tour à tour ou d’être le scribe d’un collègue, mais bien de réfléchir à deux sur un même problème de programmation, pour que la solution finale arrive plus vite.

Il existe différentes manières de faire du pair programming.

Le couple conducteur-navigateur, avec un ou plusieurs PC.

La façon la plus classique de mettre en place cette pratique est tout simplement de s’asseoir côte à côte devant un écran d’ordinateur. Les deux développeurs ou développeuses prennent le clavier et la souris à tour de rôle, d’un côté pour écrire du code, et de l’autre pour relire, corriger et proposer des améliorations.

Il est aussi possible que chacun utilise son propre PC, le navigateur ou la navigatrice peut alors faire des recherches pour orienter son partenaire, ou même réaliser des maquettes en direct. La personne qui ne code pas peut également utiliser papier et crayon pour réaliser ces maquettes, notamment lorsqu’une portion importante du travail a trait au design architectural ou d’interfaces utilisateur.

Quoiqu’il en soit, les deux pair programmeurs travaillent de concert, discutent sur la meilleure manière d’aborder un problème, et n’implémentent une solution que lorsque celle-ci est doublement validée.

Le Ping-Pong pair programming.

Cette forme de pair programming est mise en œuvre dans un contexte de développement piloté par les tests (TDD). Une personne écrit un test, et l’autre écrit le code pour que le test passe. Une méthode efficace, surtout que les changements de rôles se font tout naturellement.

Attention toutefois à bien interchanger les positions et à ne pas faire écrire ou passer les tests par la même personne à chaque fois. Typiquement, le développeur le moins expérimenté ou le moins confiant aura tendance à toujours écrire les tests, pour qu’un développeur plus aguerri s’occupe d’écrire le code qui validera le test.

C’est une méthode plutôt sympa, où les deux personnes impliquées se lancent tour à tour des défis de programmation. Les échanges de rôles plus fréquents peuvent toutefois induire un temps total de développement plus long que les autres méthodes.

Le couplage fort, ou strong-style pairing.

Cette méthode consiste à obliger celui qui rédige le code à ne rien faire tant que le navigateur ne lui a pas communiqué de tâches. Le conducteur doit toujours demander l’avis de la personne qui l’accompagne avant de faire quoique ce soit. Les échanges de place se font dès que l’un des deux développeurs a une idée : c’est à l’autre de la transcrire en code ! Llewellyn Falco, coach Agile spécialiste du code legacy et du TDD, justifie cette approche ainsi :

Pour qu’une idée aille de votre tête à l’ordinateur, il faut qu’elle passe par les mains de quelqu’un d’autre.

En mettant en place cette pratique de strong style pair programming, chaque programmeur est impliqué dans le processus de développement (en particulier le navigateur qui peut parfois avoir tendance à prendre son rôle à la légère avec les autres méthodes).

Pair programming n’est pas mentoring.

Finalement, attention à ne pas confondre pair programming et mentoring, ce sont deux choses bien distinctes. Une relation professeur-élève est bien différente de deux professionnels collaborant sans aucune considération hiérarchique, même s’il y en a généralement un plus expérimenté que l’autre. L’idée n’est pas pour le navigateur de diriger le travail du conducteur mais bien de suggérer des manières d’avancer : la collaboration est la clé du pair programming !

Avantages et inconvénients de la programmation à deux.

Quand on pair programme, l’ensemble du code envoyé en production est donc créé par deux personnes qui travaillent de concert. Découvrons ensemble quels en sont les bénéfices et inconvénients (oui, il y en a… si on cherche bien).

Une meilleure qualité du code, sans augmentation des délais de livraison.

A première vue, on pourrait penser que le pair programming augmente les temps de livraison de 100%, car on a deux personnes qui travaillent sur le même morceau de code. Sauf que deux têtes valent mieux qu’une plus une, et que la réalité est plutôt autour des 15%. Ok, mais c’est toujours 15% de plus, donc 15% de trop…

En réalité, lorsqu’un programme est codé par deux personnes, les retours d’expérience montrent que la qualité du code est largement supérieure. Les deux développeurs ou développeuses discutent des meilleures façons de résoudre les problèmes rencontrés, ce qui permet d’avoir un code plus propre, plus facile à lire et à retravailler dans le futur.

Les développements réalisés en pair programming contiennent ainsi 15% de bugs en moins en moyenne. Si l’on considère qu’un seul bug peut occuper plusieurs personnes pendant plusieurs heures, et que les larges projets peuvent en contenir des centaines, le calcul est vite fait.

Une collaboration saine et efficace.

Lorsqu’on débute en pair programming, on entend souvent des remarques du genre « Je suis quelqu’un de très introverti. Je déteste devoir interagir avec d’autres personnes, et l’idée de le faire constamment ne me plaît pas du tout ». Formulées à voix haute ou non, ces remarques sont tout à fait justifiées, mais une fois la timidité dépassée peu sont ceux qui ne veulent plus entendre parler de pair programming.

Au-delà des gains en termes de productivité et de qualité induits par la revue de code en continu, développer à plusieurs (à deux en l’occurrence) peut en effet s’avérer bien plus exaltant que d’évoluer seul dans son coin, et ce pour différentes raisons :

• Partager ses connaissances et meilleures pratiques. S’associer avec un développeur ou une développeuse senior est le meilleur moyen pour quelqu’un de moins expérimenté d’améliorer ses pratiques. Mais les devs plus expérimentés peuvent également apprendre des plus jeunes, que ce soit en découvrant une commande Linux inconnue, en utilisant un nouvel IDE ou le dernier framework Front-end à la mode, chacun peut apporter à l’autre.
• Moins d’interruptions. Si l’un des deux pair-programmeurs doit s’absenter pour assister à une quelconque réunion, l’autre peut rester concentré sur la tâche en cours sans perdre le fil.
• Une coordination d’ensemble plus simple. Vu qu’il y a deux fois moins de postes à gérer, coordonner le projet dans son ensemble nécessite moins d’efforts.
• Le renforcement de l’esprit d’équipe et des liens entre développeurs. Quelques bonnes sessions de pair programming sont tout aussi efficaces qu’un long week-end de team building en Ardèche.
• Moins de procrastination. Développer à deux permet d’éviter de se déconcentrer en allant checker ses mails, son Slack, WhatsApp ou autre. Cela peut paraître insignifiant mais les distractions sont aujourd’hui partout, et le temps passé à faire autre chose que du code est parfois très conséquent.

Certaines sociétés, qui placent la collaboration au centre de leurs pratiques, interdisent même à leurs développeurs de faire partir du code en production s’ils ont travaillé seul dessus !

Des intégrations facilitées.

Le transfert de connaissances est très fluide en pair programming. De fait, au lieu de passer par des heures d’auto-formation, l’intégration d’un nouveau collaborateur peut se faire en lui assignant un partenaire de programmation. Il ou elle plongera directement dans le code source, avec quelqu’un à ses côtés qui le connaît déjà, produisant ainsi de la valeur bien plus rapidement pour l’entreprise.

Programmer à deux en vue d’une embauche peut également être un très bon moyen pour évaluer la qualité d’un candidat ou d’une candidate, et se faire une idée de sa future intégration avec l’équipe de développement en place.

Cela dit, le pair programming n’est pas non plus sans inconvénient.

Compliquer les tâches simples.

Au vu des succès et de l’engouement que le pair programming peut susciter dans une équipe de développement, ses membres peuvent avoir tendance à trop en faire. Certains problèmes de programmation ne nécessitent absolument pas que deux personnes se penchent dessus : une correction de bug toute bête ou une fonctionnalité facile à implémenter ne sont pas propices au pair programming.

Attention donc à ne pas recourir à la programmation à deux à tout va, surtout pour des tâches plutôt simples, où un deuxième cerveau ne sera pas forcément utile.

Surcharger mentalement les développeurs et développeuses.

Quand deux pair programmeurs travaillent de concert, il est beaucoup plus difficile de se déconcentrer et de prendre des petites pauses mentales, pourtant bénéfiques pour la productivité. Les développeurs qui travaillent en binôme évoquent parfois des journées de code éprouvantes mentalement, car la concentration est à son maximum pendant toute la session de pair programming.

Comment commencer à pair programmer dans votre entreprise.

Alors, convaincu·e ? Voici pour finir quelques conseils et bonnes pratiques pour débuter la programmation en binôme au sein de votre organisation.

Y aller doucement, mais sur des développements complexes.

Le pair programming est très facile à implémenter, dans le sens où ce n’est pas tout ou rien. Il est tout à fait possible de programmer à deux seulement de temps en temps. Dans un contexte de développement agile, cela peut aussi être mis en place le temps d’une itération.

Vous pouvez ainsi tenter l’expérience du pair programming sans remettre en cause toute l’organisation et les habitudes de votre entreprise. Cela permettra de surcroît à tout le monde de comparer les performances avec la programmation en solo.

Pour débuter, il est conseillé de coder en binôme sur des tâches complexes et plutôt longues, plutôt que sur des développements simples et rapides. Les avantages du pair programming n’en seront que plus visibles.

Parler, beaucoup parler.

On ne fait jamais de programmation à deux sans causer. Si un binôme est silencieux, c’est qu’il n’y a pas de partage, pas assez en tous cas. Que vous soyez côte à côte ou à distance (on y revient juste en-dessous), échangez, pensez à voix haute, c’est ce qui fera l’efficacité de votre session de pair programming.

Quelques outils pour pair programmer à distance.

Si la plupart des sessions de programmation en binôme se font derrière un seul et même écran, il est tout à fait possible de faire du pair programming à distance. Les outils informatiques favorisant la collaboration sont aujourd’hui légion, et le temps des chaînes d’emails, appels Skype ou transferts interminables de .zip semble révolu.

Vous trouverez ci-dessous une liste d’outils de développeurs destinés à celles et ceux qui travaillent dans une équipe dispatchée ou qui sont régulièrement amenés à collaborer sur des bouts de code :

• Visual Studio Live Share : la solution Microsoft pour le développement collaboratif, basée sur son IDE bien connu.
• Teletype for Atom : le nouvel entrant sur le créneau, gratuit et open source.
• RemoteCollab : un plugin SublimeText pour permettre à plusieurs développeurs de travailler sur le même projet en temps réel.
• CodeSandbox : avec sa fonctionnalité Live, cet outil permet de collaborer sur vos différents sandboxs.
• Codeanywhere : comme son nom l’indique, cette solution basée sur votre navigateur vous permet de « coder partout », ou en tous cas depuis n’importe quel appareil.
• CodePen : moyennant une souscription à l’abonnement Pro, le mode Collab offre finalement un environnement sur lequel plusieurs développeurs peuvent travailler simultanément.

Sachez finalement qu’il faut du temps pour s’habituer au pair programming, cela risque de vous paraître bizarre au début, mais pas d’inquiétude, l’habitude vient en codant !

Pour accélérer les choses, nous vous proposons une formation pour mettre en application les meilleures pratiques de pair programming. 2 jours de code-retreat durant lesquels les apprenants abordent également le TDD, clean code, l’architecture émergente ou encore les principes SOLID.

Le pair programming, vu par CommitStrip :