02 855 233 42 contact@oniti.fr

Rubber Duck Debugging : à chacun son canard en plastique !

Voilà des jours et des jours que la rédaction de cet article me démangeait ! Je mourrais d’envie de vous faire part de ma découverte.  L’histoire commence par un collègue qui me suggère : “Oh, toi, je vais t’acheter un petit canard !”. Regard interloqué et silence gêné… Tout de même, c’est osé pour un collègue que je connais depuis moins d’un mois ! L’histoire se poursuit deux semaines après, au Devfest 2021 organisé à la Cité des Congrés, lorsque j’observe un stand plein de petits canards en plastique. Ah non, là, il se passe décidément quelque chose de très spécial dans ce milieu du développement informatique ! J’ai initié mon enquête...

Un concept de débogage pour le moins original

Alors, la révélation. Au gré de mes recherches et échanges, je découvre la théorie du « rubber duck debugging », aussi appelée « rubber ducking » ou « méthode du canard en plastique » (mais c’est moins drôle à dire très vite).

S’il y a quelques semaines nous vous parlions dans un autre article de bugs, aujourd’hui je vous propose une méthode pour remédier aux erreurs de programmation, simplement.  

Quand un développeur code, il a tendance à se plonger pleinement dans la rédaction de son programme. Lorsqu’un bogue survient, il est courant qu’il s’évertue à vouloir le corriger et le maîtriser. Il peut alors devenir compliqué de ralentir le rythme de ses pensées et de maîtriser l’urgence possible de la situation. Peuvent alors apparaître frustration, agacement, impatience… C’est généralement à ce moment qu’une pause café s’impose. Il en profite pour échanger avec un collègue des difficultés qu’il rencontre. Eurêka ; alors qu’il formule sa problématique, tout s’éclaire et il trouve une nouvelle piste, parfois même la solution.

Décryptage pour les moldus

Si vous êtes programmeur-développeur, vous comprenez précisément cette sensation. Si vous n’êtes pas du métier, visualisez simplement cette scène vécue des centaines de fois… Vous avez perdu un objet, vos clés par exemple. Vous fouillez machinalement toutes vos poches, tous vos sacs, tout votre logement. Puis, subitement, hors d’haleine et énervé.e, vous prenez le temps de vous asseoir. “Bon, réfléchis un peu”. Vous vous mettez à retracer le chemin : quand les ai-je utilisées la dernière fois, pour quel usage, dans quelle pièce ? Et là, l’illumination ; l’image vous revient avec la solution. Vous retrouvez vos clés.   

Du recul, encore et toujours !

Vous l’aurez compris, tout l’intérêt de la méthode repose sur le fait de prendre le recul suffisant pour ne plus se concentrer uniquement sur le problème. Expliquer les grandes lignes et l’objectif du code, redessiner à la fois la destination et le parcours pour y parvenir, ligne par ligne, dans les moindres détails, permet de retracer le fil conducteur naturel, évident et simple du code. Expliciter l’implicite dans une revue de code permet de réaliser le delta entre ce que nous voulons faire, ce que nous pouvons faire et ce que nous avons réellement fait. Le changement de perspective nous invite à considérer un enjeu ou une action qui avait été délaissé, ignoré ou contourné dans un bout de code.

Nous rejoignons la maxime de Nicolas Boileau “Ce qui se conçoit bien s’énonce clairement et les mots pour le dire arrivent aisément”, mais dans une logique inverse. En verbalisant clairement, précisément, nous concevons bien. Et en l’occurrence, nous développons bien !

Le rôle du canard en plastique

Qu’est-ce qu’un canard en caoutchouc vient faire dans cette histoire me direz-vous ? Il vous permet de laisser tranquille votre collègue qui ne demandait rien d’autre que de boire son café en paix et en silence. Vous vous confiez alors à la figurine. 

L’avantage du canard ? Il est toujours disponible et il ne se plaint jamais. Votre monologue peut être infini et l’écoute éternelle.

Les origines du rubber duck debugging

Cette théorie a été évoquée pour la première fois en 1999 dans l’ouvrage The pragmatic programmer : from journeyman to master, de Andrew Hunt et David Thomas. Ce dernier avait été interpellé puis séduit par cette méthode de débogage qu’un prestigieux programmeur, étudiant de l’Imperial College London, avait adoptée. Avec son co-auteur, ils ont étendu sa connaissance et sa notoriété, tant et si bien que de nombreux autres ouvrages l’ont également évoquée et développée. 

Depuis, dans le monde du génie logiciel, le petit canard en plastique est devenu une figur(in)e incontournable dans les agences de solutions informatiques.

Chez Oniti, ça collectionne le canard ? 

Nous, comme l’Université de Sherbrooke au Canada qui a rebaptisé la méthode “Parler à une plante verte”, nous avons décidé d’élargir le choix de notre interlocuteur privilégié en modifiant l’apparence de l’objet iconique sur nos bureaux.

Ainsi, certains d’entre nous ont par exemple opté pour un petit caneton à remontoir, une tête de mort fluorescente ou encore des figurines issues de manga tel que Tokyo Ghoul. La personnalisation est libre et importante ; il s’agit maintenant de notre plus grand confident après tout ! 

Bon, pour être tout à fait francs, on préfère quand même échanger, râler et co-construire avec les collègues. Chez Oniti, nous sommes trop soudés et communicants pour nous satisfaire d’un objet en plastique comme pilier de notre évolution.

Alors, convaincus ?

Prêts pour l’adoption de votre petit canard ? Vous laisserez-vous tenter ? 

Noob ou rockstar (comprendre “débutants ou experts”, parce que oui, dans ce monde, en plus du canard, il y a le jargon !), nous vous invitons à expérimenter la méthode. Parce que quelles que soient votre expérience et votre ancienneté, codes cassés et débogages feront toujours partie de votre quotidien et du métier. 

Allez, après tout, sauter le pas et tenter l’aventure ne casse pas non plus trois pattes à un canard… 

Morale de l’article

Verbalisez, prenez du recul et si vos collègues vous proposent de vous offrir un petit canard, ne paniquez pas. Je répète : NE PA-NI-QUEZ PAS ! Ils vous veulent du bien.