Apprendre le Slow Debug, ça peut vous ouvrir des portes !

Sur les bons conseils de Thomas Pierrain j'ai lu récemment « Debugging: The 9 Indispensable Rules » de David J. Agans.

Son argument c'est que dans le métier, il y a des personnes douées pour le debug, qui souvent sans le savoir appliquent certaines règles… et les autres, qui perdent beaucoup de temps.

Celles qui sont douées sans savoir pourquoi seraient encore plus efficaces si elles formalisaient leurs « règles » tacites - Agans conseille d'ailleurs de commencer par se poser la question « comment tu debug » ? C'est bien ce que j'avais cherché à faire avec le « Manifeste du Slow Debug… »

Apprendre sans pratiquer, c'est gaspiller

Donc j'ai voulu mettre en pratique. J'ai associé ça avec un de nos onboardings à CodeWorks - apprendre, pratiquer ET transmettre en même temps, c'est le top.

Cerise sur le gâteau, on a mis ça en oeuvre sur un projet fun et utile d'un autre CodeWorker, intitulé « Sesam Bot ».

« Sesam Bot » est l'oeuvre d'Alexis Ragot, c'est un Raspberry Pi sur lequel on fait tourner un petit serveur Express (sous Node) qui parle à la messagerie Slack d'un côté, et de l'autre à un circuit qui commande un relais électrique, lequel est relié à notre porte d'entrée. Le résultat c'est un portier automatisé, quand on arrive au bureau et qu'on a oublié notre badge (ou juste pour s'amuser), on se fait ouvrir en envoyant un message sur notre Slack.

C'est sympa… mais c'est juste un proto, donc il y a des bugs.

En particulier, ça marche bien quand on vient de brancher le Pi, mais au bout de quelques heures ça ne marche plus: le bot boude, il ignore nos demandes d'ouverture…

Pour moi, l'essence du debug méthodique, donc lent, c'est la prise de note. (N°6, « Keep an audit trail ».)

• On commence donc par ouvrir une page dans notre Notion interne, pour noter tout ce qu'on fait
• On lit le code source pour comprendre le fonctionnement du système (N° 1, « Understand the System »)
• On décrit le fonctionnement de bout en bout, pour savoir à quel endroit du système on veut concentrer nos efforts (N° 4, « Divide and conquer »)
• Puis on part à la chasse aux observations utiles (N° 3, « Quit thinking and look »).

Au final, la surprise de cette session c'est… qu'il n'y a pas de surprise : l'hypothèse qu'on avait privilégiée au départ, un timeout de la connexion entre notre serveur et Slack, est confirmée.

Est-ce qu'on a perdu notre temps ?

Non, parce qu'on a maintenant une compréhension de bout en bout du système qui nous intéressait; on a vu ensemble des techniques utiles, des outils de la ligne de commande (netstat, ps) qui vont resservir très souvent;

on s'est entraînés à documenter et à la prise de notes; et enfin on sait exactement ce qu'on va faire pour vérifier si notre correctif est efficace…

(En com', les liens vers le Manifeste, le bouquin et la journalisation de notre session. Et la série Advent of Code ? Elle reprend bientôt !)

Et vous, quelles sont vos règles de debug ?

‍