Débogage

Une bonne partie du travail d’un programmeur consiste à déboguer. Il nous faut donc savoir comment le faire efficacement.

D’abord, qu’est-ce que c’est le débogage. Il s’agit de trouver la cause de problème et le corriger d’une façon permanente. Pour y arriver, on a besoin de tester des hypothèses dans le but de trouver des causes du problème.

J’ai lu le livre «The Complete Software Developer’s Career Guide: How to Learn Programming Languages Quickly, Ace Your Programming Interview, and Land Your Software Developer Dream Job» de John SONMEZ. Il croit que le débogueur doit être un outil de dernier recours. Pourquoi? Il faut avoir une idée de la cause du problème avant d’utiliser le débogueur. Beaucoup de bogues peuvent être corrigés sans jamais utiliser le débogueur. Steve McConnel est d’accord avec Sonmez sur la nécessité d’une hypothèse. Je parlerai du débogueur une autre fois.

Dans mon projet sur le web scraping, j’ai procédé à la correction des bogues la méthode suivante: 1) Contrôle de versions avec Git pour gérer les versions et de sauvegarder une version qui a franchi une étape importante; 2) utiliser flake8 qui est un outil d’analyse statique et un vérificateur de style de code; 3) La journalisation pour suivre de déroulement du code.

Flake8

Au début, je ne savais pas comment me servir de flake8 dans Vim. En conséquence, je devais exécuter le code pour trouver des erreurs. Je n’ai pas besoin de vous dire que c’est une méthode beaucoup plus longe et ardue que de me servir de flake8. Voici un illustration de flake8 dans Vim.

Vous voyez la carré rouge en bas à droit avec une description de l’erreur. C’est bien commode. Il faut installer le plugin «Airline» dans Vim pour avoir la ligne d’état en bas. Bien sur, vous pouvez configurer cette ligne à votre goût dans Vim. Mais ce n’est pas le but de ce poste d’expliquer comment configurer Vim.

Git

Un logiciel de contrôle de versions, à mon avis, est un outil indispensable. J’en ai parlé dans un autre blog. J’en parlerai ici dans le contexte de débogage. Avec Git, je peux toujours revenir à une ancienne version lorsque je me perds. Il n’y a donc pas de gène à faire des changements. Par exemple, dans mon projet sur le web scraping, j’avais un problème avec une boucle «for» et une liste. Mais dans une ancienne version, j’avais réussi à l’exécuter correctement. J’ai tout simplement regarder l’ancienne pour savoir où j’ai fait mon erreur. La capacité de rétablir une ancienne version est un outil précieux.

Ensuite, avec un logiciel de gestion de versions comme Git, on sauvegarde les versions qui ont franchi une étape importante dans le développement du logiciel. On peut toujours créer une nouvelle branche pour ajouter des nouvelles fonctionnalités, corriger des bogues et explorer des nouvelles idées.

Journalisation

Je n’ai jamais utilisé le déboguer dans le programme dans le blog de «Web Scraping». Pourquoi? Parce que monsieur Sonmez¹a écrit que le débogueur est un outil de dernier recours. Je ne suis pas convaincu que monsieur Sonmez a raison. Mais je suis d’accord avec lui sur l’importance d’utiliser la journalisation. En effet, la journalisation m’a beaucoup aidé. Voici des avantages d’utiliser la journalisation: 1) On peut placer une déclaration dans un endroit stratégique et l’adapter la sortie aux données qu’on désire; 2) Les déclarations de journalisation sont permanentes qui est avantageux lorsqu’on travaille en équipe; 3) Les déclarations de journalisation sont faciles à filtrer et modifier. On voit un très bon exemple dans mon programme de Web Scraping. Les déclarations de journalisation sont différents à l’écran que sur le fichier de journalisation. En plus, on peut facilement choisir quel niveau de journalisation qu’on veut avoir.²

Corey Schafer explique bien comment faire la journalisation en python dans ses vidéos sur YouTube.

J’ai déjà utilisé le débogueur par la passée. Je n’étais pas un expert avec le débogueur, mais je peux vous dire que j’ai trouvé cet outil laissait à désiré pour les raisons mentionnées ci-haut. J’aime mieux la permanence des résultats affichées dans le ficher log. Les résultats affichés par le débogueur sont trop éphémères.

Avec le trois outils mentionnés ci-haut, je n’avais pas besoin d’utiliser le débogueur. J’ai réussis très bien à régler les problèmes sans son usage. Mon expérience confirme donc les conseils de Sonmez.

Conseils de Steve McConnel

La méthode scientifique de débogueur
Steve McConnel³ explique la méthode scientifique. Puis, il l’adapte au débogage. Les étapes sont trop importantes pour ne pas le mentionner. Les voici:

1) Recueillir des données en répétant des expériences.
2) Développer une hypothèse qui explique des données pertinentes
3) Concevoir une expérience qui met à l’épreuve l’hypothèse.
4) Prouver ou réfuter l’hypothèse.
5) Répéter au besoin.

Vous pouvez mieux comprendre pourquoi la journalisation peut jouer un rôle important dans le débogage. Celle-ci nous aider à recueillir des données. Puis, vous pouvez tester votre hypothèse avec la journalisation. La logiciel de contrôle de versions contribue à tester des hypothèses aussi. Flake8, vous aide à formuler votre hypothèse. Et les testes unitaires servent à toutes les étapes.

Qu’est qu’on fait quand on n’a pas d’hypothèse? Cela peut arriver pour un débutant n’est pas? Réponse: suivre les conseils de Sonmez et McConnel et en développer une. Par exemple, je travaillais sur une exercice de testes unitaires et le programme ne voulait pas s’exectuer à cause d’un bogue. Flake8 affichais une erreur de syntaxe. J’ai regardé dans le livre que je lisait et le code que j’écrivais suivais ce qui était écrit dans le livre. Je me suis dit: «C’est un problème avec mon ordinateur ou l’interpréteur de Python ou bien que les nouvelles versions de python ont fait des modifications qui font en sort que le code ne marche plus.» J’ai donc copié le code d’un autre programme qui utilisait code similaire et j’ai réussi de l’exécuter. Ainsi, j’étais capable de prouver que mon hypothèse s’avérait incorrect.

Une fois que j’ai écarté cette hypothèse, j’ai dû développé une autre. Puis, j’ai continué avec le méthode scientifique jusqu’à ce que j’ai trouvé la source du problème.

Voici d’autres conseils de Steve McConnel qui s’appliquent à mon expérience ((limitée) en programmation. Le programmeur doit tenir pour acquis qu’il est responsable pour l’erreur, pas le compilateur ou l’ordinateur. Cela s’est avéré exact pour moi. Il m’arrive de ne pas savoir ce qui cause l’erreur et j’ai tendance de penser que l’ordinateur cause l’erreur. Mais quand flake8 indique qu’il y une erreur de syntaxe, c’est parce que il y en a un.

Prendre des pauses

McConnel l’a écrit et cela correspond à mon expérence aussi. Le fait de prendre un recul, permet le cerveau d’aborder le problème d’une autre angle lorsqu’on revient.

Lorsque je suis dans un cul-de-sac dans le débogage, je réussis mieux à trouver une piste de solution lorsque je prends du recul. En fait, lorsque ça bloque, je parviens rarement à trouver une solution devant l’écran de l’ordinateur. Je développe des pistes à explorer en réfléchissant ailleurs.

Madame Barbara Oakley explique pourquoi dans son livre «A Mind for Numbers: How to Excel at Math and Science (Even if you flunked Algebra)».⁴ Madame Oakley parle de diffuse-mode (en anglais) pour le cerveau. Celui-ci arrive lorsqu’on se repose et on laisse vagabonder le mental, après avoir concentré sur le problème. Ce repos permet au cerveau de trouver de la perspicacité.

Réécrire le code au lieu de passer trop de temps à résoudre le problème

Un conseil très important de McConnel. Lorsque je tourne en ronde, car mes hypothèses ne me permettent pas à avancer, je suis mieux de réécrire le code autrement. Passer trop de temps à trouver une solution devient une perte de temps. Je suis mieux d’apprendre d’autres façons d’écrire le code. Une excellent exemple est le code pour le web scraping. J’ai dû abandonner le regex pour ajouter les jours de la semaine aux dates. Les listes se sont révélées beaucoup plus efficaces.

Monsieur McConnel donne beaucoup d’excellents conseils. Cela dit le but de ce blog est d’expliquer comment j’apprends la matière, pas de répéter ce que les autres ont déjà écrit. En conséquence, j’explique ce qui a bien marché pour moi. J’avoue aussi je ne n’ai pas mis en pratique tout ce que McConnel a écrit.

Je pense que j’ai écrit assez pour un blog sur le débogage. Mais c’est loin d’être complet. Par exemple, je n’ai pas parlé de mes expériences avec des testes unitaires qui jouent un rôle important dans le débogage. J’aurai sûrement d’autres expériences à partager sur ce sujet à fur et à mesure.

1. The Complete Software Developer’s Career Guide: How to Learn Programming Languages Quickly, Ace Your Programming Interview, and Land Your Software Developer Dream Job» John SONMEZ
2. «Effective Debugging: 66 Specific Ways to Debug Software and Systems» Diomidis SPINELLIS
3. «Code Complete: A Practical Handbook of Software Construction, Second Edition, Steve McCONNELLl
4. «A Mind for Numbers: How to Ewxcel at Math and Science (Even if you flunked Algebra)» OAKLEY, Barbara