Pair Programming

Le pair programming signifie que deux développeurs travaillent ensemble à un poste de travail. L'un tape (le pilote); l'autre observe, réfléchit et navigue (le navigateur).

Cela semble inefficace. Vous payez deux personnes pour faire le travail d'une seule. Mais les calculs fonctionnent différemment de ce que vous attendez :

• Moins de bogues atteignent la production (le navigateur détecte les erreurs en temps réel)
• Les connaissances se répandent dans l'équipe (pas de silos de connaissances)
• La qualité du code s'améliore (révision de code en temps réel)
• Les développeurs juniors progressent plus rapidement (apprentissage auprès des seniors)
• La concentration s'améliore (c'est plus difficile de consulter Twitter quand quelqu'un regarde)

Les études montrent que les paires produisent du code avec 15 % de défauts en moins tout en prenant seulement 15 % de temps en plus. Ce n'est pas le double du coût pour une meilleure qualité — c'est un investissement de 15 % pour des résultats nettement meilleurs.

Le modèle classique de pair programming comporte deux rôles :

Le pilote tient le clavier. Il :

• Tape le code
• Se concentre sur la tâche immédiate (syntaxe, cette ligne, ce test)
• Réfléchit tactiquement à l'implémentation
• Explique ce qu'il fait

Le navigateur observe et réfléchit. Il :

• Révise le code au fur et à mesure qu'il est écrit
• Réfléchit stratégiquement (cette conception a-t-elle du sens?)
• Garde la vue d'ensemble à l'esprit
• Détecte les fautes de frappe, les erreurs de logique et les problèmes de conception
• Cherche des informations au besoin

Changez de rôle régulièrement. Toutes les 15 à 30 minutes, échangez. Cela maintient les deux partenaires engagés et empêche une personne de dominer.

Le navigateur n'est pas passif. Si vous naviguez et que vous voyez quelque chose qui ne va pas, parlez immédiatement. N'attendez pas. La valeur du pair programming vient de la rétroaction continue.

Il existe plusieurs styles efficaces de pair programming :

Pair programming ping-pong (fonctionne très bien avec le TDD) :

1. La personne A écrit un test qui échoue
2. La personne B le fait passer et écrit le prochain test qui échoue
3. La personne A le fait passer et écrit le prochain test qui échoue
4. Continuez à alterner

Cela maintient les deux personnes activement en train de coder et maintient la discipline du TDD.

Pair programming de style fort : « Pour qu'une idée passe de votre tête à l'ordinateur, elle doit passer par les mains de quelqu'un d'autre. »

Le navigateur dit au pilote quoi taper. Le pilote tape seulement; il ne prend pas de décisions. C'est excellent pour l'enseignement — le junior tape pendant que le senior navigue, forçant le transfert de connaissances.

Pair programming guide touristique : Une personne connaît la base de code; l'autre apprend. L'expert pilote et explique, donnant une visite guidée du code. Ensuite, ils échangent, l'apprenant tentant des tâches sous supervision.

Choisissez le style qui convient à la situation. Ping-pong pour le TDD. Style fort pour le mentorat. Guide touristique pour l'intégration.

Le pair programming fonctionne aussi à distance. Vous avez besoin de :

• Partage d'écran avec faible latence (VS Code Live Share, JetBrains Code With Me, ou partage d'écran avec contrôle à distance)
• Communication vocale (connexion audio constante)
• Caméra optionnelle mais utile (voir les réactions et le langage corporel)

Conseils pour le pair programming à distance :

• Utilisez un outil qui permet aux deux personnes de taper (pas seulement le partage d'écran)
• Prenez des pauses plus fréquentes — le pair programming à distance est plus fatigant
• Surcommuniquez verbalement (vous ne pouvez pas lire le langage corporel aussi bien)
• Convenez des paramètres de l'éditeur et des raccourcis clavier avant de commencer

Certaines équipes trouvent que le pair programming à distance fonctionne encore mieux qu'en personne parce qu'il n'y a pas de tentation de « se pencher et prendre le clavier ». Chaque personne reste dans son rôle.

Faites du pair programming pour :

• Les problèmes complexes où deux perspectives aident
• Les chemins de code critiques (authentification, paiements, intégrité des données)
• Le code inconnu (une personne le connaît, une apprend)
• Quand vous êtes bloqué (une nouvelle perspective débloque les impasses)
• L'intégration d'un nouveau membre de l'équipe

Envisagez le travail solo pour :

• Les tâches simples et routinières (mise à jour de configuration, renommage de choses)
• Les explorations (quand vous devez réfléchir seul)
• Quand une personne a une expertise approfondie à laquelle l'autre ne peut pas contribuer

XP n'impose pas 100 % de pair programming, contrairement à la croyance populaire. Le XP original spécifiait le pair programming pour le code de production, mais le XP moderne reconnaît que les équipes efficaces mélangent le travail solo et en paire selon le contexte.

La clé : ne laissez jamais du code aller en production sans révision. Si vous ne faites pas de pair programming dessus, révisez-le. Le pair programming n'est qu'une révision de code en temps réel.

« Nos développeurs ne veulent pas faire de pair programming. » Commencez lentement. Faites du pair programming uniquement sur les problèmes difficiles. Laissez les gens expérimenter les avantages. N'imposez pas 100 % de pair programming dès le premier jour.

« Nous ne pouvons pas nous permettre deux personnes sur une tâche. » Vous ne pouvez pas non plus vous permettre des bogues en production. L'économie favorise le pair programming quand vous tenez compte de la réduction des bogues, des connaissances partagées et de l'amélioration de la qualité du code.

« Les développeurs seniors seront ralentis. » Parfois. Mais les seniors en pair programming avec les juniors accélèrent toute l'équipe. Les connaissances du senior se répandent. Le junior progresse. C'est un investissement dans la capacité de l'équipe.

« Les introvertis détestent le pair programming. » Certains introvertis adorent le pair programming parce que c'est une interaction structurée avec un objectif clair. D'autres ont besoin de temps seul pour se ressourcer. Respectez les besoins individuels, mais ne supposez pas que l'introversion signifie anti-pair programming.

« Le pair programming est épuisant. » C'est plus intense que le travail solo. Prenez des pauses. Ne faites pas de pair programming pendant 8 heures d'affilée. Mélangez le pair programming avec le travail solo, la révision de code ou le travail de conception.