Accueil 🔺 🎲

Le Grand Art du Débogage (en cours de très longue rédaction)

Introduction

Le bogue a une grosse charge négative et survient sans que nous ne lui demandions: le diable vient sans être invité, dit-on. Le TDD permettrait de l'éviter et même d'après certains rendrait le débogage très rare.

Déboguer a comme une allure de sorcellerie. Nous réfléchissons rarement sur notre manière de guérir les anomalies.

Ce petit article se propose de mettre en lumière et de rendre conscient 'ce grand art du débogage'.

J'ai toujours été fort dans le domaine de la correction d'anomalie. Cet ouvrage me sera aussi utile personnellement pour mieux me comprendre en tant que développeur.

Impossibilité

Il ne sera jamais possible de créer un programme qui détecte tout bogue de n'importe quel programme que nous lui fournirions en entrée. C'est dû à l'indécidabilité du problème de l'arrêt qui est un théorème mathématique prouvé par Alan Turing. A fortiori, il n'y aura jamais de programme capable de corriger n'importe quelle anomalie d'un autre programme.

Définition du bogue

Selon le Larousse:
défaut de conception ou de réalisation d'un programme informatique, qui se manifeste par des anomalies de fonctionnement de l'ordinateur.

Pour moi, le bogue est un ami qui vous pose une devinette intellectuelle.

Typologie des bogues

Gravité

La gravité d'un bogue indique s'il impacte beaucoup une fonctionnalité. Un 'blocker' ainsi empêche complètement un bon comportement de se produire.

Compilation

Votre code ne compile pas. On pourrait considérer que ce n'est pas un vrai bogue, mais parfois il faut réfléchir pour le corriger:
  • Il peut manquer une parenthèse ou une accolade quelque part;
  • Vous utilisez une partie assez obscure de votre langage de programmation;
  • Une expression typée n'est pas du bon type.
Et c'est un 'blocker' puisque votre programme ne peut pas s'exécuter.

Typo

Un typo est juste un caractère en trop dans une ligne de code. Il intervient surtout pour les langages interprétés. Le programme ne s'exécute pas et vous ne l'apprendrez qu'à l'exécution du morceau incriminé.

Label

Il s'agit en général d'une faute d'orthographe ou d'une phrase qui ne correspond pas exactement à ce qui est spécifié. Les erreurs simples sur les labels sont parfois difficiles à bien corriger du premier coup.

NPE

La fameuse NullPointerException en java quand on déréférence un objet null. Sur une requête serveur, elle peut plier la transaction ou la requête courante mais elle ne tue pas le serveur. Celui-ci continue à tourner et à répondre aux autres utilisateurs. Ou même à l'utilisateur qui a fait se produire cette erreur.

Pour un langage comme le C, par contre, elle est mortelle et tue le processus en cours.

En java avec Spring par exemple, la NPE est une RuntimeException donc elle cause l'annulation de la transaction. Dans un batch, si celui-ci n'a qu'une seule transaction alors tous les changements de base de données du batch seront annulés.

Mauvaises performances

L'application répond trop lentement ou un traitement par lot n'est pas assez rapide. Ca peut énerver l'utilisateur final qui ne reviendra plus alors sur votre site.

Les erreurs de pixels

Un texte ou une image n'est pas placé exactement au bon endroit. Ou carrément est caché par autre chose.

Bien positionner vos éléments graphiques peut faire une grosse différence et donner une impression plus professionnelle.

Réseau

Un câble ou un matériel hors service et c'est tout Internet qui n'est plus accessible. Les équipements sont toutefois plus fiables à notre époque, mais on n'est pas à l'abri d'une section de fibre optique lors de travaux à l'extérieur. Ces bogues viennent en général du hardware, donc nous ne parlerons pas d'eux dans cet article.

Multi-tâche

Ces bogues interviennent quand il y a plusieurs exétrons en cours surtout sur les machines multi-processeur. Le CPU peut intervertir des sauvegardes en RAM, une même ressource peut être utilisée par plusieurs processeurs en même temps. Ou les différents processeurs logiques peuvent avoir des caches mémoire séparés et donc ne pas voir la même valeur pour une variable en mémoire centrale.

Ces bogues sont parfois très rares: ainsi j'avais fait un test de performances et le problème de multi-threading d'une variable très sollicitée n'était apparu qu'une fois en 10000 requêtes. Après on accuse la radioactivité ou les rayons cosmiques mais prosaïquement, c'est juste un bogue de multi-tâches.

Ces bogues sont TRES difficiles à reproduire.

Fuite mémoire

Dans un langage où il y a un ramasse-miettes, ce genre de bogue est moins courant mais peut quand même apparaître. En C, si vous faites un malloc puis ne faites jamais de free sur le pointeur renvoyé alors que celui-ci ne sert plus à rien, alors vous avez une fuite mémoire. Les octets non utilisés vont rester là à occuper de la RAM pour rien.

Certaines fuites mémoire sont tellement violentes qu'elles peuvent faire grossir un process à toute allure et le faire occuper toute la mémoire. Si le système d'exploitation n'est pas blindé vis-à-vis du manque de RAM, il peut alors carrément crasher.

Dans des langages comme java, la fuite mémoire peut se cacher par exemple dans une Map dans un champ statique qui grossit sans arrêt car elle n'est pas purgée.

Configuration

Un fichier de configuration n'est pas à jour ou contient des erreurs. Par exemple, il pointe sur la mauvaise base de données.

Une fois, il m'est arrivé qu'une propriété manque carrément et le bogue était une déconnexion de l'application au bout de 5 minutes.

"Face à face avec la divinité"

Je parle ici de bogues qui semblent venir de l'obscurité d'une librairie boîte noire. Pire encore, une anomalie venant d'une dépendance transitive que vous ne connaissez même pas. Dans ce cas, effectivement, vous vous retrouvez "seul face à la divinité" car la correction de cette défectuosité va se révéler difficile. Ou exiger de mettre à jour le code importé avec les risques associés.

Origine des bogues

There must be a scape-goat comme dirait Lucy dans Snoopy.😊😊😊 Mais la recherche d'un coupable est rarement utile. Même si ça peut aider une personne à progresser quand on lui indique son erreur. Cependant, il est délicat de dire à quelqu'un qu'il a fauté: il le prendra peut-être mal.

Nouvelle version d'un composant

Vous avez mis à jour une librairie. Vous avez plusieurs cas:
  • Ça ne compile plus: dans le meilleur des cas, c'est juste peut-être une méthode dépréciée qui a été supprimée;
  • Un test unitaire fait une erreur: vous avez de la chance qu'il soit détecté à ce moment-là;
  • À l'exécution, il y a un problème; c'est le pire des cas car vous pouvez le détecter très tard.

Mauvaise interprétation d'une spécification

Vous avez lu rapidement une spécification et vous l'avez mal comprise. Si c'est sur un cas d'usage habituel de cette spécification, ce sera rapidement découvert. Sinon, si c'est plus rare, l'anomalie risque d'apparaître très tard dans le cycle de vie du logiciel.

Cas aux limites

Vous avez oublié le cas 'null', zéro, chaîne vide, collection vide ou infini et ça bogue dans ces cas-là. Normalement, les tests unitaires doivent tester ces cas aux limites et donc vous éviter ce genre d'anomalie.

Mauvaise compréhension d'une API, de l'usage d'une librairie

Vous avez lu rapidement la documentation et vous n'avez pas bien compris celle-ci. Et bien sur en développement sur vos cas d'usage à vous, ça marche.

Recopie de code provenant d'Internet

Vous avez recopié un morceau de code de Stack Overflow sans avoir bien lu la documentation des composants utilisés.

Mauvaise compréhension des principes de base d'un langage ou d'un framework

Par exemple, vous ne savez pas que le Javascript de base est mono-threadé. Ainsi, vous ne comprenez pas les principes du code asynchrone en Javascript.

Le framework que vous utilisez est "magique" pour vous et vous n'avez aucune idée de la façon dont il marche.

Environnement de déploiement différent de celui de développement

Vous écrivez du code sur votre poste et celui-ci s'exécute dans un environnement qui peut avoir l'une de ces différences:
  • le système d'exploitation n'est pas le même;
  • la version du système d'exploitation ou du serveur d'application est différente;
  • le déploiement est fait sur un cluster et vous avez testé sur votre poste.

L'erreur de conscience

Vous n'êtes pas conscient de quelque chose. Vous recopiez un code écrit ailleurs dans l'application et vous ne voyez pas qu'il n'est pas raccord avec ce que vous voulez faire.

Les typos sont aussi des erreurs de conscience: vous écrivez un nom de variable et celui-ci est mal orthographié. Vous ne vous en apercevez pas car vous voyez votre code globalement.

Vous changez du code dans un coin et vous ne conscientisez pas qu'il a des impacts ailleurs.

Tous les bogues sont en fait des erreurs de conscience. Si vous en étiez conscient, vous pourriez les corriger.

Correction des bogues

Cycle de vie

Les émotions

Parler d'émotions ici? Dans ce qui semble être du pur intellect? Alors que les ordinateurs n'en ont pas? Eh bien oui car vous allez en ressentir que vous le vouliez ou non! Ressentez-les consciemment, ne les laissez pas inconsciemment vous distraire.

Dorénavant, j'exagère les réactions émotionnelles qui peuvent varier en intensité selon tout un chacun. Déjà la première réaction est la (mauvaise) surprise. Puis vous stressez et cela tout le long du processus: cette anomalie est-elle grave, peut-elle être corrigée? Ensuite si ce n'est pas vous "l'auteur" du bogue, vous allez vous énerver vis-à-vis de cette personne. Son code ne vous plaira peut-être pas et vous en ressentirez du dégoût.

Puis si vous trouvez une solution, il faudra la tester ce qui peut prendre du temps et votre impatience peut vous agacer. Quand vous découvrez la réponse à l'énigme, vous ressentez de la joie. Et quand tout est fini, vous êtes soulagé.

La découverte

On se réveille un matin et quelque chose a pété dans une construction de nuit:
  • Un outil d'analyse tel que Dependency track a découvert de nouveaux bogues de sécurité dans des dépendances;
  • Vous utilisez 'npm install' et à cause d'une obscure dépendance transitive, il ne compile plus;
  • Un test unitaire a échoué parce que vous êtes le 29 février, proche de la fin d'un mois ou d'une année.
En cours de journée, vous avez des bogues en continu dans votre travail de développement: compilation qui échoue, test unitaire qui échoue, spécification dont vous vous apercevez que vous la suivez incorrectement ou même que vous la comprenez mal.

Un QA ou un gentil collègue vous remonte une anomalie.

Pire, le problème vient du client ou pire encore, de la production.

L'analyse

Il va falloir comprendre d'où vient le bogue. Déjà, si vous arrivez à le reproduire sur votre PC en local, c'est bien, ça vous facilitera la compréhension.

Si vous n'arrivez pas à le reproduire, vous êtes dans la panade.

Savoir de quelle partie du code l'anomalie provient.

Comprendre le scénario, les données en entrée du bogue.

La réparation

Les outils

Le débogueur

Les journaux

Ils sont intéressants à lire et analyser. Savoir à quelle heure a eu lieu un problème permet de mieux cerner l'endroit des journaux à regarder prioritairement.

En général il y a un niveau de message (TRACE, DEBUG, INFO, WARN, ERROR, FATAL) qui permet d'indiquer si c'est grave ou non. L'application active un niveau à partir duquel une trace est écrite.

Le niveau du message est intéressant par lui-même. À partir de ERROR, on peut considérer que quelque chose ne fonctionne pas. Si c'est FATAL, alors c'est vraiment la catastrophe.

En java, sur le serveur, les journaux permettent de voir des traces de la pile et de vous indiquer de quel type est l'erreur. Et vous avez même le numéro de ligne en faute et toutes les méthodes appelantes. Si vous avez accès au code source, vous pouvez mieux comprendre ce qui se passe.

Si le problème est facilement reproductible vous pouvez faire que les journaux affichent des messages de niveau inférieur. Mais souvent ça demande de relancer l'application, donc ce n'est souvent pas pratique.

Traces de la pile

En java, elles sont particulièrement utiles car elles indiquent précisément l'endroit où a eu lieu le problème. Elles indiquent aussi le code appelant. Parfois, elles ont un message d'erreur qui peut vous en dire plus. De toute façon, elles sont dans les journaux et ceux-ci peuvent vous indiquer d'autres choses.

Votre cerveau!

En lisant le code par vous-même autour de l'endroit vous pourriez reproduire le bogue dans votre tête. Le meilleur interpréteur de code, le plus puissant du monde reste votre cerveau. Même s'il est très lent... Imaginer ce qui pourrait coincer aide forcément dans la correction.

La documentation

On n'y pense pas toujours, on se jette sur le Web pour trouver une réponse mais parfois, c'est la mauvaise utilisation d'une API qui est en jeu. Et lire la documentation peut vous permettre de résoudre votre anomalie.

RTFM: Read The Fucking Manual. Lisez la documentation d'abord et ensuite cherchez sur Internet.

Recherche sur Internet

Vous pouvez faire des recherches sur Internet en choisissant bien vos mots-clés ou en soumettant le message de l'exception débarassé de ce qui est local à votre problème comme une clé primaire ou un identifiant.

En général, si votre recherche ne donne rien de rien, c'est que vous avez fait une grosse erreur.

Reproduction

Appel à l'aide

Quelques fois, lorsque vous êtes bloqué disons depuis plus d'une heure sur un problème qui semble mineur, vous pouvez "faire appel à un ami" comme dans "qui veut gagner des millions". Il peut avoir une vision plus objective du problème ou avoir une intuition instantanée qui résout votre problème.

Conclusion

N'oubliez jamais que le plus puissant débogueur reste votre cerveau aux immenses ressources.
🢁 🎲