Pair programming : le principe des quatre yeux dans le développement de logiciels

Le développement de nouveaux logiciels est une initiative coûteuse. Suivant le volume du programme, de très nombreuses éventualités, fonctionnalités et problématiques doivent être prises en compte. Même des développeurs de logiciels expérimentés peuvent s’y perdre. Pour que la programmation soit la plus efficace possible, mais qu’il en résulte simultanément un code sans erreur, des méthodes de travail modernes ont été mises au point ces dernières années et décennies : le scrum et le kanban servent par exemple à améliorer l’ensemble du système.

Le pair programming est de moins grande envergure : les développeurs travaillent toujours par deux à un code. Comment cela peut-il fonctionner et quels sont les avantages de cette méthode de travail ?

La méthode de la programmation en binôme est surtout utilisée pour le développement de logiciels dits agiles et est concrètement demandée pour la programmation extrême (XP). Dans le cas du pair programming, systématiquement deux personnes travaillent simultanément sur le code, et sont donc idéalement assises directement l’une à côté de l’autre. L’une écrit le code pendant que l’autre le vérifie en temps réel. En même temps, les deux informaticiens échangent en permanence : ils discutent des problèmes, trouvent des solutions et développent des idées créatives.

Normalement, les deux collaborateurs se voient attribuer deux rôles différents : le programmeur qui écrit le code est qualifié de pilote. Celui qui le contrôle est appelé le navigateur. Le fait que les deux inversent régulièrement les rôles (et ce à intervalles rapprochés) fait partie des règles de la programmation en binôme. Toute relation hiérarchique est ainsi exclue : ils ont tous les deux la même légitimité et peuvent donc sans problème se mettre à la place de l’autre.

Idéalement, le poste de travail devrait lui aussi être adapté aux exigences du pair programming. Les deux partenaires ont ainsi une souris, un clavier et toujours leur propre moniteur, les écrans affichant respectivement la même chose.

Le remote pair programming est en revanche un peu plus inhabituel. Les binômes ne sont pas assis l’un à côté de l’autre, mais se trouvent dans des lieux complètement différents. Pour que cela puisse fonctionner, il faut des solutions techniques spéciales. Malgré la distance, les collègues doivent être en mesure de communiquer directement l’un avec l’autre, d’intervenir sur le code et de voir les modifications en temps réel.

Dans la pratique, deux développeurs d’un niveau d’expérience différent travaillent souvent ensemble : un programmeur très expérimenté peut ainsi transmettre directement son savoir-faire à son collègue plus jeune. Le collaborateur junior peut de son côté éventuellement apporter au projet des idées neuves.

La combinaison de deux collègues de différents secteurs peut également porter ses fruits : si un programmeur classique travaille avec un designer, ils peuvent se soutenir dans leurs domaines de compétences respectifs.

Le pair programming est surtout pertinent pour des projets d’assez grande envergure. En effet, si de grandes quantités de code doivent être régulièrement modifiées, le principe des quatre yeux s’avère particulièrement efficace. Il est la garantie d’obtenir toujours la meilleure version possible d’un segment du code source, ce qui réduit les rectifications et le nombre d’erreurs. Le contrôle ultérieur de codes sources très longs est chronophage et laborieux. C’est la raison pour laquelle il est avantageux de le créer si possible dès le départ sans erreur.

Il n’est par ailleurs pas nécessaire de faire toujours travailler les mêmes collègues ensemble (même au sein d’un projet). Il est même plutôt avantageux d’éclater régulièrement les binômes pour en former d’autres. Chaque membre de l’équipe peut ainsi se faire une bonne idée du code source dans son intégralité. La réussite du projet dépend alors aussi moins d’individus spécifiques. Si une personne vient à faire faux bond, l’intégralité du projet ne sera pas menacée, car tous les autres pourront compenser cette absence.

Quand on travaille à deux sur un projet (qu’il s’agisse de programmation ou d’un autre projet), cela présente en principe de nombreux avantages. Quatre yeux voient généralement mieux que deux : le risque d’erreurs est réduit par le pair programming. Pendant qu’une personne écrit, l’autre regarde le code et se concentre uniquement sur la détection des failles. Il est généralement difficile de voir ses propres erreurs. Un collège détecte souvent beaucoup plus rapidement les incohérences.

Par ailleurs, la créativité développée avec la communication présente également un avantage incontestable : l’échange permanent du binôme permet de faire jaillir des idées auxquelles l’un ou l’autre n’aurait sans doute jamais pensé. L’interaction des deux partenaires permet également de mieux résoudre les problèmes, plus rapidement. En effet, alors qu’un individu seul se satisfera potentiellement de la première solution trouvée, il devra obligatoirement justifier ses décisions vis-à-vis de son collègue dans le cas du pair programming. Celui-ci aura néanmoins éventuellement un autre point de vue sur le problème et ne se satisfera donc pas de la solution proposée. La discussion qui en résultera permettra souvent de générer des idées améliorant nettement le code.

Un bon code est finalement aussi un code épuré : l’expérience a démontré que le code source généré lors du pair programming était souvent plus court et donc plus efficace. L’économie en ressources au niveau de la maintenance et du remaniement sera donc importante.

Comme indiqué précédemment, cette technique peut aussi être utilisée pour permettre à des collaborateurs expérimentés de transmettre leurs connaissances à des collègues plus jeunes. L’entreprise bénéficie ainsi non seulement des avantages du pair programming (la création d’un code de grande qualité), mais aussi de la méthode à des fins de formation.

Le tout prend néanmoins beaucoup du temps à disposition : certes, deux programmeurs avancent nettement plus vite qu’un seul, mais pas aussi vite que deux programmeurs travaillant séparément. Autrement dit, avec cette méthode, soit les projets progresseront plus lentement, soit davantage de personnes devront être embauchées, ce qui entraînera une augmentation des coûts. Les partisans du pair programming partent cependant du principe que ce surplus de travail initial vaut finalement le coup : étant donné que le code ainsi créé contient moins d’erreurs et est globalement mieux structuré, des économies sont faites au niveau de la maintenance.

Un autre avantage possible : le pair programming s’inscrit parfaitement dans la création d’un bon esprit d’équipe, mais à la seule condition que les deux collègues puissent bien travailler ensemble. Le binôme doit interagir si étroitement que des problèmes personnels conduisent soit à un ralentissement du projet, soit débouchent sur une situation explosive. C’est la raison pour laquelle dans cette méthode, le choix des collaborateurs ne peut pas être laissé au hasard. Il est certes idéal que chacun ait l’opportunité de travailler avec tel ou tel collègue, mais cela ne peut fonctionner que si toute l’équipe est en parfaite harmonie.