Suivez une méthode en 4 étapes
Le débugging est une compétence précieuse pour tous les développeurs. Il s’agit de la méthodologie à suivre pour trouver et éliminer les bugs de son programme. Le mot-clé est « méthodologie ». On ne débug pas au petit bonheur la chance, il faut de la méthode et un état d’esprit de détective. 🤠 C’est d’autant plus vrai qu’un programme qui plante cache la plupart du temps plusieurs bugs. Voici ci-dessous une méthodologie efficace que je vous propose de suivre.
Étape 1 : Décrivez le problème le plus clairement possible
Ici vous devez décrire correctement le « quoi » et le « quand » du problème. Imaginez que vous avez un problème avec votre voiture. 🚘 La recherche du « quoi » et du « quand » consistera à se demander :
Est-ce que le problème vient des pneus (crevaison, sous-gonflage, jantes voilées) ou du moteur (batterie déchargée, le démarreur ne fonctionne plus) ?
Quand est-ce que le problème apparaît et quand est-ce qu’il n'apparaît pas ?
Donc dire « Ça ne marche pas » n’est pas suffisant. Voici quelques questions à se poser :
Qu’est ce qui a vraiment planté ?
Avez-vous une idée de la zone dans laquelle se situe le nœud du problème ?
Avez-vous remarqué que ce bug revenait souvent ?
Vous êtes d’ailleurs aidé par votre interpréteur Python, qui vous envoie un message d’erreur plus explicite qu’il n’y paraît (nous y reviendrons dans les chapitres suivants). Si votre description du problème n’est pas claire, vos collègues ou Google ne pourront pas vous aider.
Voici deux exemples de demandes d’aides. Laquelle décrit le mieux le « quoi » du problème ? :
« Mon programme a planté, est-ce que quelqu’un peut m’aider ? Ci-dessous le code… »
« J’essaie de récupérer des informations de l’API de Twitter depuis cette adresse [url] en utilisant le module requests version 2.25.1. Il me renvoie le message d’erreur suivant au bout de quelques secondes, mais je n’arrive pas à le comprendre. Est-ce que quelqu’un pourrait m’aider ? Ci-dessous le code… »
Alors, vous avez trouvé ? Ok, c’était facile mais, croyez-moi, ça aide énormément à bien formuler son problème.
Étape 2 : Définissez un test
Un de mes anciens managers me disait ceci : « Ce qui n’est pas testé ne marche pas ». Cette phrase est pleine de bon sens. Réfléchissez, si vous aviez testé les éléments de votre programme qui étaient le plus susceptible de planter, vous auriez probablement évité le bug, n’est-ce pas ?
Un test permet de reproduire un contexte ou un cas d’utilisation pour s’assurer que le programme fonctionne correctement. Le test est donc particulièrement utile en amont. Il permet de cerner et anticiper les potentiels bugs.
Un test est également utile en aval. Grâce aux tests, nous pouvons nous assurer que la réparation que nous allons effectuer résout bel et bien le problème sans en créer un autre.
Étape 3 : Proposez des théories
C’est ici que le détective en vous doit se réveiller pour brainstormer sur des hypothèses à l’origine du bug. Cette étape a pour but de vous permettre d’éclairer votre connaissance du « quoi » et du « quand » (étape 1) par la réponse au « pourquoi ». Cette étape de questionnement est importante pour trouver la cause première derrière le bug. En effet, votre objectif n’est pas de traiter uniquement les effets, les symptômes, auquel cas le problème se reproduirait. Vous devez identifier la vraie cause pour que votre solution ait un caractère définitif.
En rapport avec notre programme qui n’arrive pas à récupérer les données de l’API de Twitter, on pourrait se demander :
Est-ce que l’url est correcte ?
Est-ce que l’API est toujours fonctionnelle ?
Est-ce que la mise à jour récente du module requests implique une utilisation différente ?
Est-ce que j’ai bien récupéré l’access token ?
La vraie cause doit se trouver parmi vos questions. Vous n’avez plus qu’à tester tout ça dans l’étape suivante.
Étape 4 : Résolvez le bug
Maintenant que vous avez formulé des hypothèses à la fois pertinentes et exhaustives sur l’origine du bug, il est temps de le résoudre en implémentant la solution. La résolution dépendra du type de bug comme vu dans le chapitre précédent. Il vous faudra par exemple :
Faire des modifications dans le code ou dans sa structure ;
Mettre à jour des modules ou des logiciels ;
Relancer l’IDE ou le programme (oui ça marche aussi parfois).
Néanmoins, tout comme il existe plusieurs causes possibles à un bug, il peut également exister plusieurs solutions possibles. Par conséquent, résoudre le bug implique d’en implémenter au moins une.
Évidemment, il est très probable que vous deviez effectuer les 4 étapes plusieurs fois, en fait autant de fois qu’il sera nécessaire pour que votre programme fonctionne correctement. Avec l’expérience, vous le ferez de plus en plus vite et de mieux en mieux.
Maintenant que nous avons défini une méthode scientifique de résolution des bugs, je vous propose de la perfectionner en utilisant deux techniques très efficaces de résolution de problèmes applicables dans l’informatique et ailleurs.
Appliquez la méthode des cinq « pourquoi »
La méthode des 5 pourquoi est très utile pour aller à la racine d’un problème. Elle consiste, comme son nom l’indique, à se demander non pas une, mais plusieurs fois « pourquoi », cinq étant plus une convention utile pour nous obliger à approfondir notre analyse.
Par exemple, un développeur pourrait penser que s’il travaillait depuis la plage plutôt que dans des bureaux il serait plus heureux et productif au travail. C’est peut-être la conclusion à laquelle il est arrivé en se demandant « pourquoi je ne suis pas heureux et productif » une seule fois. Mais des études sérieuses ont montré que ce n’est pas si binaire. Dans ce cas pourquoi n’est-il pas heureux ? Il faut reposer la question « pourquoi » plusieurs autres fois pour découvrir la cause réelle.
Quand nous appliquons la méthode des cinq pourquoi nous obtenons une chaîne de causes qui peut être linéaire, sous forme d’arbre ou encore circulaire. En voici quelques exemples :
Linéaire
C’est la configuration classique quand on utilise la méthode des cinq pourquoi.
Pourquoi est-ce que je suis en retard ? Parce que je ne me suis pas levé à temps.
Pourquoi ? Parce que je me suis couché tard.
Pourquoi ? Parce que je regardais Top Chef...
En arbre
Chaque branche correspond à une cause. Il faut limiter les branches aux explications les plus pertinentes pour ne pas se perdre.
Pourquoi est-ce que la voiture n’a plus de carburant ?
Branche 1 : Parce que ni moi et ni ma femme n’avons pensé à en mettre. Pourquoi ? Parce que chacun pensait que l’autre allait le faire…
Branche 2 : Parce qu’il n'y en avait plus à la station service. Pourquoi ? Parce que le camion-citerne qui était censé ravitailler la station service a eu un accident...
Circulaire
Dans ce cas de figure, la chaîne de causes fait un tour. Il faut casser le cercle pour trouver la solution au problème.
Pourquoi je n’arrive pas à m’endormir ? Parce que je suis stressé.
Pourquoi ? Parce que je n’arrive pas à m’endormir.
Pourquoi ? Parce que je suis stressé...
Reprenons notre exemple d’appel à l’API de Twitter et essayons de répondre aux cinq pourquoi...
Pourquoi a-t-il planté ? Parce que je n’ai pas récupéré l’access token.
Pourquoi ? Parce que je n’ai pas lu la documentation de l’API qui stipulait qu’il était obligatoire.
Pourquoi ? Parce que je ne connais pas les mots techniques en anglais pour chercher dans la documentation.
Pourquoi ? Parce que je ne suis pas encore très à l’aise avec l’anglais technique et que la traduction de Google Translate n’est pas toujours très claire.
Pourquoi ? Parce que j’ai tendance à chercher uniquement des ressources en français et à zapper quand elles sont en anglais.
Que remarquez-vous ? Il y a plusieurs sous-problèmes, parmi lesquels la capacité à lire une documentation. En effet dans votre carrière vous allez devoir lire beaucoup de docs pour savoir comment utiliser une API, un module, un framework, un objet, etc. Et il s’avère qu’un grand nombre sont uniquement in english. 😝
Par conséquent, le développeur doit s’occuper des différentes causes trouvées, mais surtout du problème de fond, sinon ce genre de bug va inévitablement se reproduire. Du coup, je vous pose la question : pourquoi votre programme a planté la dernière fois ? Faites l’exercice de répondre à cette question en vous demandant plusieurs fois « pourquoi ».
Utilisez le principe du 80-20
Le principe du 80-20, ou le principe de Pareto, explique le phénomène que 80% des résultats sont dûs à 20% des causes. Ce principe a du succès parce qu'il s’applique à de très nombreux domaines.
Appliqué à la résolution de bugs, le principe de Pareto suggère que 20% des causes classiques de bugs génèrent 80% des bugs. Il vous faut donc non seulement lister les potentielles causes à l’origine de votre bug, mais également les classer par fréquence d’apparition.
Dans une entreprise vous pouvez par exemple mener une petite enquête en proposant un sondage pour la question « Quels sont les bugs que vous avez le plus souvent rencontré, et quand ? »
Vous pouvez aussi regarder les questions les plus communes sur un site de questions/réponses comme Stack Overflow (en anglais) pour découvrir où se cachent les 80% des bugs les plus fréquents.
Si vous gardez cela à l’esprit et vous concentrez sur les 20% de causes des bugs les plus communes et plausibles, vous gagnerez non seulement du temps et de l’argent, mais vous préserverez aussi votre santé mentale.
En résumé
Le débugging est une méthodologie qui permet de trouver et d’éliminer les bugs. Il se compose de quatre étapes :
Décrivez clairement le quoi et le quand en rapport avec votre bug.
Créez un test qui permet de vérifier que le programme ou une partie du programme fonctionne correctement.
Proposez des hypothèses à l’origine du bug, en gardant à l’esprit qu’il peut y avoir plus d’une cause.
Résolvez le bug en ciblant la cause réelle et non pas juste une de ses conséquences.
La méthode des cinq pourquoi permet d’aller à la racine du problème en répondant plusieurs fois à la question « pourquoi » en rapport avec un bug.
Le principe de Pareto implique que 80% des bugs sont la conséquence d’environ 20% des actions du programmeur.
Maintenant que vous avez ces informations clés en tête, passons à la pratique en installant notre environnement de débugging. Prêt ?
