Salut et bienvenue sur Code Garage, je m'appelle Nicolas Bondan-Vernard
et on va découvrir ensemble des sujets passionnants autour du métier de Dev et de la programmation en général.
Ce premier épisode, il est consacré au rubber duck debugging.
Donc trouver la cause et la résolution d'une anomalie dans du code,
ça fait partie intégrante du métier de développeur.
Il y a certaines défaillances, certains problèmes qu'on va même mettre
jusqu'à plusieurs jours à corriger.
Parfois, même lorsque le bug est détecté, reproduit et isolé,
la méthode de résolution, le correctif, peut rester très très très compliqué à trouver.
Du moins pour la personne qui a écrit le code en question.
Ça arrive qu'on ait besoin d'aller demander l'aide d'un autre développeur ou d'une autre développeuse
pour avoir par exemple un regard neuf et trouvé et implémenté cette fameuse solution
que nous-mêmes on n'a pas été capables de trouver.
En fait, il y a deux inconvénients à ça.
C'est que d'une, on n'a pas toujours une dev disponible sous la main,
surtout pas 24 heures sur 24.
Et surtout, s'il s'est fait de manière trop répétée,
qu'on va tout le temps demander à un collègue ou une collègue,
on perd vraiment en eau tenue.
Mais heureusement, il existe une technique ancestrale,
pas ancestrale, on voit mais une technique qui a fait ses preuves
et qui est utilisée par des développeurs depuis des décennies
et qu'on va pouvoir mettre en place facilement et qui a de très bons résultats.
C'est quoi cette technique ?
C'est tout simplement de parler à un canard en plastique.
Donc là, je sais si vous n'êtes pas habitué et que vous ne connaissez pas le concept,
ça fait un petit peu bizarre, mais je vous promets que je ne suis pas fou et ça fonctionne vraiment.
En réalité, quand on explique un problème technique à quelqu'un,
développeur ou non d'ailleurs,
on est obligé de vulgariser le système.
On vulgarise les entrées, les sorties, la logique qui est au milieu,
ce qu'on veut faire, ce qu'on a essayé de faire et le problème qu'on a.
Faut expliquer méthodiquement, passer ligne par ligne, rien oublier.
En gros, comme si on enseignait quelque chose à quelqu'un,
comme si on lui donnait un cours.
Et si on se réfère à la célèbre maximum,
on dit que la meilleure manière d'apprendre ou de comprendre, c'est d'enseigner.
C'est exactement ce qui se passe là.
Quand on va expliquer, quand on va enseigner,
on va aussi comprendre et apprendre de nos erreurs et surtout comprendre ce qu'on a fait.
C'est pour ça que la plupart du temps, quand vous demandez de l'aide à quelqu'un sur un problème de code,
en général, c'est vous qui trouvez la solution en premier.
Je pense que ça nous est tous déjà arrivé.
On explique notre problème.
Et puis, arriver au 2 tiers d'explication, on se dit,
je crois que j'ai trouvé, je crois que j'ai compris, l'erreur revient de là.
Il y a une raison très simple à ça, c'est que notre cerveau est en partie fait pour détecter le manque de logique,
le manque de cohérence.
Et quand vous exprimez à l'oral, ou elle écrit d'ailleurs, mais c'est plus flagrant à l'oral,
un problème en l'expliquant étape par étape, comme on a dit qu'on faisait tout à l'heure, presque ligne par ligne,
en fait, votre cerveau, quand vous allez le dire à haute voie,
il va être plus à même de détecter les différents problèmes dans votre raisonnement.
Il va trouver les failles, il va trouver instinctivement les choses qui manquent ou les choses qui ont trop.
Et donc, c'est pour ça que certains développeurs ou vos développeuses,
ils ont remplacé cette habitude de demander de l'aide à un autre être humain
par un canard en plastique posé sur leur bureau.
C'est pour ça qu'on appelle ça le rubber duck debugging,
c'est le debugging grâce à un canard en plastique.
Donc en vrai, la technique fonctionne avec n'importe quel interlocuteur inanimé,
ça peut être une plante verte, ça peut être un ours en plus, peu importe, une figurine.
Évidemment, si on peut faire moins de plastique et plus de plante verte, c'est toujours mieux.
Mais voilà, c'est une technique qui fonctionne vraiment,
évidemment, ça ne fonctionne pas à tous les coups,
mais si ça fonctionne déjà rien que pour 50% des fois où vous avez un problème
qui vous prend du temps, qui vous prend la tête et que vous n'arrivez pas à résoudre,
ça fait 50% de temps de gagner parce que vous ne vous déplacez pas,
vous n'allez pas en bête à un collègue ou une collègue, etc.
Ça ne veut pas dire qu'il ne faut jamais demander à ses collègues,
mais si on peut gagner en autonomie et gagner du temps avec ça,
honnêtement, ça marche vraiment.
Et moi, j'avoue que personnellement, je n'ai pas de canard en plastique posé sur mon bureau.
Par contre, m'exposer mon problème à haute voie,
le répéter à mon mur, à mon écran peu importe,
je le répète à haute voie, ça m'aide vraiment.
Ce qu'il faut retenir de ce truc-là,
c'est exprimer et expliquer calmement vos problèmes techniques à haute voie,
ça va vous permettre de les résoudre en autonomie et parfois plus rapidement.
Voilà, j'espère que cet article vous aura plu.
Vous pouvez le...
Enfin, cet épisode, on va dire,
mais vous pouvez retrouver la version écrite de cet article pour plus tard
ou pour le relire sur le blog.
Vous trouverez tout simplement le lien dans les notes du podcast de cet épisode.
Et puis moi, je vous souhaite une bonne journée, une bonne soirée, une bonne semaine et à très vite.