Pair pro­gram­ming : le principe des quatre yeux dans le dé­ve­lop­pe­ment de logiciels

Le dé­ve­lop­pe­ment de nouveaux logiciels est une ini­tia­tive coûteuse. Suivant le volume du programme, de très nom­breuses éven­tua­li­tés, fonc­tion­na­li­tés et pro­blé­ma­tiques doivent être prises en compte. Même des dé­ve­lop­peurs de logiciels ex­pé­ri­men­tés peuvent s’y perdre. Pour que la pro­gram­ma­tion soit la plus efficace possible, mais qu’il en résulte si­mul­ta­né­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 pro­gram­ming est de moins grande envergure : les dé­ve­lop­peurs tra­vail­lent toujours par deux à un code. Comment cela peut-il fonc­tion­ner et quels sont les avantages de cette méthode de travail ?

La méthode de la pro­gram­ma­tion en binôme est surtout utilisée pour le dé­ve­lop­pe­ment de logiciels dits agiles et est con­crè­te­ment demandée pour la pro­gram­ma­tion extrême (XP). Dans le cas du pair pro­gram­ming, sys­té­ma­ti­que­ment deux personnes tra­vail­lent si­mul­ta­né­ment sur le code, et sont donc idéa­le­ment assises di­rec­te­ment 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 in­for­ma­ti­ciens échangent en per­ma­nence : ils discutent des problèmes, trouvent des solutions et dé­ve­lop­pent des idées créatives.

Nor­ma­le­ment, les deux col­la­bo­ra­teurs se voient attribuer deux rôles dif­fé­rents : le pro­gram­meur qui écrit le code est qualifié de pilote. Celui qui le contrôle est appelé le na­vi­ga­teur. Le fait que les deux inversent ré­gu­liè­re­ment les rôles (et ce à in­ter­valles rap­pro­chés) fait partie des règles de la pro­gram­ma­tion en binôme. Toute relation hié­rar­chique est ainsi exclue : ils ont tous les deux la même lé­gi­ti­mité et peuvent donc sans problème se mettre à la place de l’autre.

Idéa­le­ment, le poste de travail devrait lui aussi être adapté aux exigences du pair pro­gram­ming. Les deux par­te­naires ont ainsi une souris, un clavier et toujours leur propre moniteur, les écrans affichant res­pec­ti­ve­ment la même chose.

Le remote pair pro­gram­ming est en revanche un peu plus in­ha­bi­tuel. Les binômes ne sont pas assis l’un à côté de l’autre, mais se trouvent dans des lieux com­plè­te­ment dif­fé­rents. Pour que cela puisse fonc­tion­ner, il faut des solutions tech­niques spéciales. Malgré la distance, les collègues doivent être en mesure de com­mu­ni­quer di­rec­te­ment l’un avec l’autre, d’in­ter­ve­nir sur le code et de voir les mo­di­fi­ca­tions en temps réel.

Dans la pratique, deux dé­ve­lop­peurs d’un niveau d’ex­pé­rience différent tra­vail­lent souvent ensemble : un pro­gram­meur très ex­pé­ri­menté peut ainsi trans­mettre di­rec­te­ment son savoir-faire à son collègue plus jeune. Le col­la­bo­ra­teur junior peut de son côté éven­tuel­le­ment apporter au projet des idées neuves.

La com­bi­nai­son de deux collègues de dif­fé­rents secteurs peut également porter ses fruits : si un pro­gram­meur classique travaille avec un designer, ils peuvent se soutenir dans leurs domaines de com­pé­tences res­pec­tifs.

Le pair pro­gram­ming est surtout pertinent pour des projets d’assez grande envergure. En effet, si de grandes quantités de code doivent être ré­gu­liè­re­ment modifiées, le principe des quatre yeux s’avère par­ti­cu­liè­re­ment efficace. Il est la garantie d’obtenir toujours la meilleure version possible d’un segment du code source, ce qui réduit les rec­ti­fi­ca­tions et le nombre d’erreurs. Le contrôle ultérieur de codes sources très longs est chro­no­phage et laborieux. C’est la raison pour laquelle il est avan­ta­geux de le créer si possible dès le départ sans erreur.

Il n’est par ailleurs pas né­ces­saire de faire toujours tra­vail­ler les mêmes collègues ensemble (même au sein d’un projet). Il est même plutôt avan­ta­geux d’éclater ré­gu­liè­re­ment 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 in­té­gra­lité. La réussite du projet dépend alors aussi moins d’individus spé­ci­fiques. Si une personne vient à faire faux bond, l’in­té­gra­lité 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 pro­gram­ma­tion ou d’un autre projet), cela présente en principe de nombreux avantages. Quatre yeux voient gé­né­ra­le­ment mieux que deux : le risque d’erreurs est réduit par le pair pro­gram­ming. Pendant qu’une personne écrit, l’autre regarde le code et se concentre uni­que­ment sur la détection des failles. Il est gé­né­ra­le­ment difficile de voir ses propres erreurs. Un collège détecte souvent beaucoup plus ra­pi­de­ment les in­co­hé­rences.

Par ailleurs, la créa­ti­vité dé­ve­lop­pée avec la com­mu­ni­ca­tion présente également un avantage in­con­tes­table : l’échange permanent du binôme permet de faire jaillir des idées aux­quelles l’un ou l’autre n’aurait sans doute jamais pensé. L’in­te­rac­tion des deux par­te­naires permet également de mieux résoudre les problèmes, plus ra­pi­de­ment. En effet, alors qu’un individu seul se satisfera po­ten­tiel­le­ment de la première solution trouvée, il devra obli­ga­toi­re­ment justifier ses décisions vis-à-vis de son collègue dans le cas du pair pro­gram­ming. Celui-ci aura néanmoins éven­tuel­le­ment un autre point de vue sur le problème et ne se satisfera donc pas de la solution proposée. La dis­cus­sion qui en résultera permettra souvent de générer des idées amé­lio­rant nettement le code.

Un bon code est fi­na­le­ment aussi un code épuré : l’ex­pé­rience a démontré que le code source généré lors du pair pro­gram­ming était souvent plus court et donc plus efficace. L’économie en res­sources au niveau de la main­te­nance et du re­ma­nie­ment sera donc im­por­tante.

Comme indiqué pré­cé­dem­ment, cette technique peut aussi être utilisée pour permettre à des col­la­bo­ra­teurs ex­pé­ri­men­tés de trans­mettre leurs con­nais­sances à des collègues plus jeunes. L’en­tre­prise bénéficie ainsi non seulement des avantages du pair pro­gram­ming (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 à dis­po­si­tion : certes, deux pro­gram­meurs avancent nettement plus vite qu’un seul, mais pas aussi vite que deux pro­gram­meurs tra­vail­lant sé­pa­ré­ment. Autrement dit, avec cette méthode, soit les projets pro­gres­se­ront plus lentement, soit davantage de personnes devront être em­bau­chées, ce qui en­traî­nera une aug­men­ta­tion des coûts. Les partisans du pair pro­gram­ming partent cependant du principe que ce surplus de travail initial vaut fi­na­le­ment le coup : étant donné que le code ainsi créé contient moins d’erreurs et est glo­ba­le­ment mieux structuré, des économies sont faites au niveau de la main­te­nance.

Un autre avantage possible : le pair pro­gram­ming s’inscrit par­fai­te­ment dans la création d’un bon esprit d’équipe, mais à la seule condition que les deux collègues puissent bien tra­vail­ler ensemble. Le binôme doit interagir si étroi­te­ment que des problèmes per­son­nels con­dui­sent soit à un ra­len­tis­se­ment du projet, soit dé­bouchent sur une situation explosive. C’est la raison pour laquelle dans cette méthode, le choix des col­la­bo­ra­teurs ne peut pas être laissé au hasard. Il est certes idéal que chacun ait l’op­por­tu­nité de tra­vail­ler avec tel ou tel collègue, mais cela ne peut fonc­tion­ner que si toute l’équipe est en parfaite harmonie.