Le décryptage du débogage

23 août 2022, 20:59:54

Pour ce premier article je vais commencer par vous expliquer ce qu'est le débogage, et comment il se passe.

Qu'est ce le débogage?

C'est un partie importante du codage, bien sur on peut imaginer que le développeur à tout dans la tête et qu'il ne fait appel qu'à sa mémoire et à son cerveau pour écrire du code sans erreur. Ceci est utopique que de l'imaginer en continu. Les problèmes ne viennent pas forcément du développeur, mais de l'environnement où le programme est exécuté, du changement de règles de fonctionnement ou bien des données.

Quand survient-il?

A chaque partie de la vie de l'application tant qu'elle est maintenue et utilisée.

Pendant la phase de développement de l'application pour que les fonctions correspondent à ce qui est prévu.
Pendant la bêta, Erreurs liés à un autre outils, vérification de ce qui est attendu. Erreurs passée à la trappe etc.
Pendant la vie du logiciel, problème de saisie, de mise à jour, problème lié aux données.

Quel est son temps de résolution?

C'est vrai qu'il est tentant de dire que le bug va être résolu en 10 minutes par ce qu'il s'agit d'un problème d'affichage, enfin côté développeur. On pourrait établir un temps de résolution en fonction du problème, partir sur une moyenne en fonction du type d'erreur. Mais attention en fonction de l'origine des problèmes les temps peuvent être largement supérieur.

Je me souvient que pour régler un problème de couleur dans une application juste pour un champ, il m'a fallut 1 jour de recherche pour savoir à quel endroit placer le correctif pour que ce dernier soit celui pris en compte.

Les étapes

1-Pouvoir reproduire le bug

Pour savoir si il existe un bug il faut absolument savoir comment il se produit, et donc être capable de reproduire le problème. Un problème non reproduisible est très difficilement corrigeable.

2-Localiser le problème

Ce n'est pas parce que le message d'erreur indique que l'erreur apparaît à la ligne 53 (par exemple) que le problème se situe à la ligne 53. Il existe 2 méthodes.

Attention certains problèmes ne sont pas reproduisibles en environnement sécurisé qu'est le mode de travail du développeur.

2-1 L'utilisation du mode pas à pas

C'est une méthode qui permet en surveillant les variables de savoir à partir de quel moment le système déraille, Attention il arrive des cas ou la méthode pas à pas ne fonctionne pas car le problème ne survient qu'à vitesse réelle.

Cette méthode n'est toutefois pas forcément aisé sur certain langages.

2-2 L'envoi de message dans la console, ou l'écriture dans un fichier texte

Cette méthode donne une vue partielle des variables présentes mais permet de suivre le parcours dans l'erreur.

3-Résolution de l'erreur

Là effectivement on peut commencer à réparer le code, attention toutefois le code peut être appelé de plusieurs endroit et donner un résultat cohérent.
Oui ça demande de l'expertise pour savoir limiter l'impact de la réparation. Cela peut revenir à enlever une brique de jenga.

4-Existe-t-il un bug après la correction?

Oui un bug peut en cacher un autre, ou le correctif supposé peut déclencher d'autre bugs.

4-1 Si encore un bug

Retour à l'étape 1

4-2 Bug Résolu.

5-Faire valider la correction

Cette étape est facultative au niveau des développeurs (surtout en phase de développement). Mais elle devrait être tester avant une mise en production, et être mise dans les parties qui vont être contact des nouveaux utilisateurs.

Ce qu'il faut retenir

Un bug a une durée de résolution difficile à estimer.
Un bug doit être reproduisible pour pouvoir être corrigé:
Ce qui explique de bien préciser les conditions amenant à l'erreur. Une simple copie d'écran n'est pas forcément suffisante et si l'on vous indique d'autres informations relatif au bug merci de les envoyer à votre service compétent, si vous voulez ne plus rencontrer le problème.
Un bug peut en cacher un autre.
Un bug dans un cas peut ne pas être un bug dans un autre.

Envie de réagir à cet article ? Déposez un commentaire :

Prénom et Nom

E-mail

Message

Captcha