Lorsque j’ai obtenu mon nouveau poste de défenseur des développeurs, l’une des premières choses que j’ai demandées était les livres. Beaucoup de livres. Certains d’entre eux couvrent mon nouveau travail et d’autres parlent de débogage. Je débogue depuis des décennies, mais j’ai l’impression que la théorie autour du débogage est un peu vague. Mon objectif était de renforcer la terminologie utilisée par les universitaires et les pairs. Un objectif secondaire est de voir comment les autres enseignent des idées liées au débogage.
Le premier livre que j’ai reçu était « Pourquoi les programmes échouent – un guide de débogage systématique » (deuxième édition) d’Andreas Zeller. Je pense que ce livre n’est que la moitié de l’équation, l’autre moitié est le merveilleux site Web d’Andreas debuggingbook.org. J’ai aimé les deux même si je ne fais pas exactement partie du groupe démographique cible pour l’un ou l’autre. Andreas est professeur à l’Université de la Sarre et, à ce titre, a écrit un livre et un site Web, tous deux conçus comme matériel de cours. Ils sont toujours agréables sans suivre de cours. Je nuancerai que les deux sont (pour la plupart) principalement destinés aux débutants.
J’ai principalement utilisé le mot car le livre comprend des concepts plus intermédiaires et peut être difficile pour les novices complets. Ma critique se concentre sur le livre car le site Web est une cible mouvante et vous pouvez probablement le consulter plus rapidement que vous ne pouvez le lire.
De quoi s’agit-il?
Je cherchais surtout un livre de débogage. Ce n’est pas un livre de débogage. Du moins pas comme je l’espérais, en fait, son site Web est plus proche de ce que je cherchais en premier lieu. Le livre traite de la prévention des échecs, en empêchant/en réduisant les bogues. Il classe et organise les termes que nous utilisons pour définir un bogue tels que :
- Défaut – c’est un bogue dans le code
- Infection – état incorrect du programme
- Échec – comportement incorrect observable
Ces définitions peuvent sembler sémantiques et liées. Après tout, un défaut sera généralement la cause d’une infection/d’une défaillance ou des deux. Mais je vois son point. Je vois que les développeurs corrigent souvent l’infection au lieu du défaut ou corrigent le défaut sans traiter l’infection.
Je vais donner un exemple, disons que nous avons un défaut dans le code qui provoque la transmission de valeurs « non définies » dans l’application. C’est une infection. Il est entré dans la base de données qui a maintenant de nombreuses cellules avec comme valeur « undefined »… C’est un échec qu’un utilisateur peut voir dans l’interface utilisateur. Une mauvaise solution sera d’avoir un cas spécial pour la chaîne « non définie » qui ne ferait que masquer le problème. Ou arrêter la valeur non définie avant qu’elle n’entre dans la base de données. Nous devons corriger le défaut racine.
Mais cela ne suffit pas, maintenant que nous avons une infection, nous devons également nettoyer les mauvaises données. Le livre ne s’arrête pas là, il parle de reproductibilité et approfondit les tests, l’observabilité, les anomalies, etc. Le livre passe beaucoup de temps sur le processus entourant le débogage réel. Suivi des problèmes, tests, journalisation et pratiques de codage défensif.
Ce que j’ai aimé
Le livre est rempli d’anecdotes et d’histoires que j’ai adorées. Beaucoup d’entre eux sont bien connus (premier bug, F16, etc.) mais pour le public cible, ils pourraient être nouveaux. Au fur et à mesure que le livre progresse, il y a des histoires plus personnelles et moins connues qui étaient mes préférées. L’histoire de base sur le Commodore 64 m’a fait rire aux éclats. L’accident de Lufthansa Varsovie était un parfait exemple de solution de contournement à un défaut de conception. Je pense que je pourrais l’utiliser dans de futurs entretiens, très intéressant.
Les explications dans le livre et la déduction sont de premier ordre. J’ai particulièrement aimé la discussion sur le découpage de la logique du programme pour trouver le coupable en cas d’échec. C’est une excellente façon d’expliquer un processus aussi élaboré. Le processus de tranchage est divisé de manière très méthodique. Le processus a beaucoup de sens et je pense que j’ai intuitivement utilisé un processus similaire lors du débogage, mais je n’ai jamais réellement suivi un chemin clair comme celui-ci.
Je pense que les sections sur le processus sont particulièrement importantes pour les débutants. Habituellement, lorsque nous embauchons des diplômés universitaires, nous devons expliquer les outils et ils finissent par comprendre la théorie qui se cache derrière cela. Ce livre pourrait expliquer la théorie à l’avance afin qu’ils puissent choisir les outils plus facilement.
Ce que je n’ai pas aimé
Je voudrais nuancer cela en disant que j’aime le livre. Je pense que la plupart des problèmes que j’ai eu à me rapporter. Je ne suis pas un étudiant et je cherchais un livre sur le débogage. Il y a cependant un problème objectif à propos du livre : il n’est pas à jour. Ce n’est pas trop mal. Cela montre à quel point tout reste le même à certains égards. Chaque fois que le livre parle d’outils (Bugzilla n’importe qui ?), cela ressemble un peu à une explosion du passé.
Alors que les concepts de base en termes de développeurs sont étonnamment similaires à ceux du livre… L’industrie a beaucoup changé. Les secteurs SRE, DevOps et QA ont complètement changé notre façon de gérer les régressions et de suivre les problèmes. Les APM modernes, les outils de traitement des journaux, les outils d’observation continue, etc. constituent un changement sismique dans notre industrie.
Sommaire
Si vous souhaitez apprendre le débogage en tant que débutant, consultez ce site et également debuggingbook.org qui semble être une excellente ressource pour apprendre le débogage. Ce livre fournit l’infrastructure théorique dont vous avez besoin pour parcourir l’ensemble du processus de qualité. Vu sous cet objectif comme un tutoriel, c’est plutôt bien. Le contenu est quelque peu obsolète, mais cela n’a pas beaucoup d’importance si la population cible est constituée d’étudiants.
Si vous souhaitez le lire pour en savoir plus sur ces processus, je vous suggère de le renforcer avec des livres plus récents qui couvrent une réflexion plus récente sur ces sujets. Alternativement, une 3ème édition peut probablement revisiter beaucoup de chapitres et revitaliser ce livre. En espérant que cela arrivera à un moment donné.