#Décembre 1/2 - L'art du débogage
J'ai ré-écrit cette newsletter plusieurs fois. Ma 1ère idée était de vous faire un tutoriel complet sur le débogage. Je pense que je ne vous aurais pas appris grand chose. J’ai alors orienté mon propos autour de ce qui me semble important de savoir plutôt que la maîtrise d’un outil. Pour moi, c’est du bon sens. Est-ce que ça l’est pour vous ?
Le débogage
La situation
Vous avez un bug en production. Comment vous est-il remonté ? Email ? A la machine à café ? Oralement ? Ticket ?
L'idéal est d'avoir un processus de remontée de bug avec un système de priorisation ainsi qu'une bonne façon de créer un ticket. Cela demande un bon outil et surtout une formation des personnes qui font cette remontée. La confiance doit régner. C'est toujours plus agréable et plus facile d'avoir une remontée avec une description et une vidéo attachée plutôt qu’un "ça ne marche pas".
Contexte
Avant d'essayer de reproduire, on se pose quelques minutes et on réfléchit à ce qui a été déployé ces derniers jours. Vous devez connaître le contexte de l'application sur laquelle vous travaillez. La connaissance générale est primordiale. Vous l'engrangerez lors des dailys. Vous devez maintenant relier les points.
Reproduction
Ne tombez pas dans le panneau du service informatique VS les utilisateurs. Si vous n'arrivez pas à reproduire le bug, cela ne veut pas dire qu'il n'existe pas. Dans ce cas là, je pense que c'est indispensable de discuter pour récupérer des informations supplémentaires.
C’est ensuite que la véritable investigation commence.
Comprenez-vous le code de vos collègues ?
Ne partez pas tête baissée avec des console.log("coucou") ou autres print("efjzaesknjzel"). Cela ressemble plus à un appel à l’aide qu’à du débogage. Lisez le code. Vous êtes développeurs. Je ne vois pas comment vous pourrez résoudre le problème si vous ne comprenez pas le code. Si ce n’est pas votre code, c’est alors d’autant plus important de lire, relire et re-relire.
Refaites le parcours entier du code, du début de l'action utilisateur jusqu'à la fin. C'est en lisant et en débogant le code des autres que vous vous améliorerez et pour plusieurs raisons :
Connaissance fonctionnelle : vous allez apprendre exactement ce que fait l'application
Connaissance technique : l'architecture de votre application n'aura plus de secret pour vous
Bonnes pratiques : vos collègues codent peut être d'une manière différente de la vôtre en bien ou en mal, nous ne sommes pas là pour juger. Vous allez découvrir des façons de faire ingénieuses que vous ignoriez. Et inversement... vous allez apprendre ce qu'il ne faut pas faire car trop compliqué à comprendre. Vous vous en inspirerez et vous deviendrez meilleurs.
Lire du code
Je ne vous ferais pas de formation à l'utilisation des débogueurs. Vous devez savoir les utiliser cependant, ce ne sont que des outils qui vous permettront de connaître la valeur de vos variables à un instant T. Ils vous permettront de tracer l'exécution de votre code une fois que vous l'aurez compris.
Je pense que la meilleure façon de monter en compétence dans une entreprise est de lire et comprendre le code des autres.
Quand j'entre dans un nouveau job ou que j'ai un nouveau client, le challenge n'est pas la technologie mais la compréhension du fonctionnel, de l'architecture et surtout du code.
Et maintenant ?
Rien du tout. J’utilise rarement le débogueur et encore moins des prints que j’oublierais de supprimer avant mon commit. J’applique toujours les mêmes règles :
Contexte : récupération d’un maximum d’informations
Liaison des points : d’où pourrait venir le problème, connaissance fonctionnelle obligatoire
Reproduction
Reverse engineering : est-ce que selon moi, le code que je lis fait ce qu’il devrait faire ?
Le problème est normalement ciblé, trouvé et réglé dans la foulée
Si non, je fais appel à un ami pour jouer le canard en plastique et je recommence
Easy ? Pas tant que ça…
Quelques articles
How Google Work ?
Je me suis souvent demandé comment travaillaient les équipes de Google. Quels outils utilisent-ils ? Comment se passent les reviews de code ? Les remontées de bugs ? J'ai maintenant ma réponse.
Apple et processeur
Apple a sorti il y a quelques semaines de nouvelles versions de ses ordinateurs avec un processeur tout nouveau. Cette nouvelle architecture s'appelle Apple Silicon et son "processeur" le M1. Savez-vous seulement pourquoi ce virage de la part d'Apple fait autant parler ? C'est le moment rêvé pour vous intéresser au fonctionnement de votre ordinateur :
Why is apple's M1 chip so fast ?
Notes aux fanboys de la pomme : l'architecture change donc toutes les applications doivent être recompilées pour fonctionner. C'est comme si on avait changé de langage pour discuter avec la machine. A l'heure où j'écris ces lignes, Docker n'est pas compatible avec le Apple M1.
L'avis de Stackoverflow sur la construction d'un CV
De bons tuyaux à prendre avec un peu de recul pour ceux qui sont encore à la recherche d'un poste :
How to write an effective developer resume, advice from a hiring manager