Pourquoi j'ai un canard en plastique sur mon bureau
J’ai un canard en plastique sur mon bureau, devant mon écran de droite. Il ne bouge jamais de là. Mon défi du jour, c’est de faire un post sur les canards en plastique, et de vous glisser un lien d’affil pour que vous en achetiez un. On parie ?
Plus qu’un objet de déco, mon canard, que j’ai nommé Captain Debug, est un vrai outil de travail. Ça s’appelle du « Rubber Duck Debugging » : quand je me sens coincé devant un bout de code qui refuse obstinément de fonctionner (reconnaissez que ça vous arrive aussi), je fais appel à mon canard magique.
Il est magique, parce qu’il connaît toutes les réponses. Il est beaucoup plus malin que moi, et il n’est jamais coincé (coincoincé, même… bravo pour ceux qui suivent). Du coup, quand je suis vraiment en galère, je fais appel à lui. Pour que son pouvoir fonctionne, il faut qu’il soit en possession de toutes les informations nécessaires.
Je me retrouve alors à lui expliquer, point par point, ce que j’attends de mon code, et ligne par ligne, ce qu’il fait. Et la magie opère : je finis quasi-systématiquement par buter sur un piège logique.
Pourquoi ça marche ?
Parfois, j’ai du mal à expliquer la situation au canard. Il devient alors évident qu’une partie de ce que je fais n’est pas claire dans mon esprit, et que c’est un des points sur lesquels je dois me pencher pour résoudre mon casse-tête.
Il y a très longtemps, j’ai fait de l’eXtreme Programming : on était deux développeurs devant un poste (« Pair programming »), et on se surveillait à tour de rôle. Ça permettait, en plus d’éviter les fautes de frappes et d’inattention, d’avoir un petit lutin qui gardait la tête froide sur les objectifs que le code devait atteindre. Pendant que l’un se concentre sur la logique en mode « big picture », le deuxième s’occupe de l’implémentation fine. Ça marche super bien, mais ça a un inconvénient majeur, puisque dans l’esprit des acheteurs, ça double le prix d’une session de travail. Difficile d’expliquer au client qu’il va payer plus, parce qu’un mec a les bras croisés derrière moi, et qu’il sera payé aussi. Croyez-moi, j’ai essayé. Rares étaient ceux, à l’époque, qui étaient prêts à comprendre le principe.
Pourtant, c’est comme ça qu’à démarré la mode des méthodes agiles, dont les revues de code sont partie intégrante. En poussant à l’eXtreme (d’où le nom), on se retrouve avec un mec perché sur l’épaule, dans une revue de code en temps réel et en continu.
Sur Internet, on a aussi la mode émergente des « ELI5 » pour « Explain Like I’m Five » , ou « Explique-moi comme si j’avais 5 ans ». On dévie un peu du debugging, puisque le eli5 est utilisé pour un peu tout et n’importe quoi, et c’est très bien comme ça. On en voit souvent passer sur Reddit, par exemple : « eli5 blockchain ». Un mec débarque, il s’est renseigné sur le sujet, et pourtant ça ne rentre pas. Il demande alors qu’on lui explique, de bout en bout et avec des mots simples, le concept, ses bénéfices, etc. Répondre à ces questions demande un énorme effort de vulgarisation, mais ça permet d’avoir une vue d’ensemble claire et compréhensible d’un problème complexe.
C’est la même chose avec le canard : on doit reprendre du début à la fin, sans sauter d’étapes, et en restant le plus explicites possible.
Origine
Pour la petite histoire, la méthode du Canard en Plastique semble être apparue en premier dans « The Pragmatic Programmer » , par Andrew Hunt et David Thomas. Ce livre, qui date de 1999, présente un tour d’horizon de méthodes de travail (orientés code), avec leurs points forts et leurs limites. Je vous conseille d’y jeter un oeil, c’est avec le Hacker Manifesto un des écrits qui m’a beaucoup fait évoluer. Je me suis jeté sur l’édition « 20e anniversaire » sortie en septembre 2019.
Alors, j’ai réussi mon pari ? Achetez votre canard : https://amzn.to/2Jy1Be8 (lien affilié)