Quelle est l'importance de la journalisation dans le débogage ?
Selon un sénior, « un bon programmeur ajoute beaucoup de logs à son programme »
Le 2015-05-20 03:46:29, par Amine Horseman, Expert éminent sénior
Dans un billet de blog, Henrik Warne -blogueur et développeur multiplateformes- nous explique son point de vue sur l’importance des fichiers journaux dans le débogage.
« Une des différences entre un bon programmeur et un mauvais programmeur est que le bon programmeur ajoute des logs et des outils qui facilitent le débogage du programme en cas d’erreur », déclare Henrik Warne. « Lorsque le programme fonctionne comme prévu, il n'y a souvent pas de différence dans la qualité des logs. Cependant, dès que le programme échoue, ou dès qu’on obtient un résultat erroné, on peut distinguer immédiatement les bons programmeurs des mauvais ».
Selon lui, il y aurait trois grandes raisons qui pousseraient de nombreux programmeurs à ne pas écrire un « code déboggable ». Premièrement, ils ne sont pas « assez humbles » pour réaliser qu’il y aura toujours des cas où leur code ne fonctionnera pas comme prévu. Deuxièmement, ils ne testent pas leur code « à fond » ; en effet, lorsqu’on teste notre code on s’assure qu’il fonctionne dans un grand nombre de scénarios différents, or « si vous ne testez pas tous les cas, vous êtes moins susceptible d'ajouter des fichiers journaux ». Troisièmement, ils ne dépannent pas assez souvent leur « propre code dans les systèmes de production » ; en effet, lorsqu’on rencontre un problème dans notre système et que les fichiers journaux ne nous aident pas à connaître la cause de la panne : nous serons incités à ajouter des logs pour nous aider à trouver rapidement le problème lors d’une situation similaire.
Henrik Warne donne aussi un exemple concret d’une mauvaise habitude de débogage : « Un testeur était venu [un jour] me voir avec un cas d'appel qui n'a pas fonctionné. Nous avons regardé les fichiers journaux et vus que le problème venait d’un module voisin : un appel à l'autre module pour obtenir une liste des valeurs nous a retourné un "null". Lorsque nous avons activé les logs dans le module voisin et refait le cas de test, il n'y avait pas plus d'informations disponibles, on n’avait aucun indice sur la raison pour laquelle le "null" à été renvoyé ». La solution proposée par le développeur du code était de créer « une version de débogage pour voir ce qui se passait », chose qui aurait pu « être évitée si une journalisation détaillée avait été établie ».
Comme conclusion, l’auteur du blog affirme qu’il y a naturellement des cas où même les bons messages de journalisation ne nous permettent pas de savoir pourquoi quelque chose a échoué. « Vous pouvez toujours avoir à faire une version de débogage, mais une journalisation régulière devrait quand même vous donner des indications sur la nature du problème ».
Source : Henrik Warne Blog
Et vous ?
Êtes-vous d’accord avec l’avis de Henrik Warne ?
À part la journalisation, quelles autres habitudes pourraient aider les développeurs lors du débogage ?
« Une des différences entre un bon programmeur et un mauvais programmeur est que le bon programmeur ajoute des logs et des outils qui facilitent le débogage du programme en cas d’erreur », déclare Henrik Warne. « Lorsque le programme fonctionne comme prévu, il n'y a souvent pas de différence dans la qualité des logs. Cependant, dès que le programme échoue, ou dès qu’on obtient un résultat erroné, on peut distinguer immédiatement les bons programmeurs des mauvais ».
Selon lui, il y aurait trois grandes raisons qui pousseraient de nombreux programmeurs à ne pas écrire un « code déboggable ». Premièrement, ils ne sont pas « assez humbles » pour réaliser qu’il y aura toujours des cas où leur code ne fonctionnera pas comme prévu. Deuxièmement, ils ne testent pas leur code « à fond » ; en effet, lorsqu’on teste notre code on s’assure qu’il fonctionne dans un grand nombre de scénarios différents, or « si vous ne testez pas tous les cas, vous êtes moins susceptible d'ajouter des fichiers journaux ». Troisièmement, ils ne dépannent pas assez souvent leur « propre code dans les systèmes de production » ; en effet, lorsqu’on rencontre un problème dans notre système et que les fichiers journaux ne nous aident pas à connaître la cause de la panne : nous serons incités à ajouter des logs pour nous aider à trouver rapidement le problème lors d’une situation similaire.
Henrik Warne donne aussi un exemple concret d’une mauvaise habitude de débogage : « Un testeur était venu [un jour] me voir avec un cas d'appel qui n'a pas fonctionné. Nous avons regardé les fichiers journaux et vus que le problème venait d’un module voisin : un appel à l'autre module pour obtenir une liste des valeurs nous a retourné un "null". Lorsque nous avons activé les logs dans le module voisin et refait le cas de test, il n'y avait pas plus d'informations disponibles, on n’avait aucun indice sur la raison pour laquelle le "null" à été renvoyé ». La solution proposée par le développeur du code était de créer « une version de débogage pour voir ce qui se passait », chose qui aurait pu « être évitée si une journalisation détaillée avait été établie ».
Comme conclusion, l’auteur du blog affirme qu’il y a naturellement des cas où même les bons messages de journalisation ne nous permettent pas de savoir pourquoi quelque chose a échoué. « Vous pouvez toujours avoir à faire une version de débogage, mais une journalisation régulière devrait quand même vous donner des indications sur la nature du problème ».
Source : Henrik Warne Blog
Et vous ?
-
SaverokExpert éminentPourquoi choisir ??
Tu fais les 2 et chaque log n'a pas la même utilité.
Les erreurs affichées sur l'interface sont destinées aux utilisateurs : ils sont orientés fonctionnel.
Les logs écrits dans les journaux sont techniques et sont destinés à la TMA pour analyse et statistique.le 20/05/2015 à 12:01 -
Logan MauzaizeRédacteur/ModérateurSurtout pas à ce sujet :
Envoyé par Henrik Warne
Et ledébogageanalyse d'incident n'est qu'une part de l'activité qui repose sur l'analyse des logs.
Je vais prendre un cas très "con" mais qui illustre bien le problème. Imaginons des serveurs Web en grappe. Ce sont deux serveurs Web dupliqués avec répartition de charge. Le choix d'une telle architecture n'est pas la charge mais simplement la disponibilité. Donc si un seul serveur fonctionne, il n'y a pas d'incidence pour les utilisateurs et donc à priori pas d'incident. Sauf que l'absence de logs "normaux" sur l'un des serveurs indiquent bien un problème. Mais c'est peut-être simplement l'infrastructure de la grappe qui est en cause (répartiteur, relance automatique, etc.). Sans des logs d'information "basique", impossible de savoir ce qui se passe.
On peut même étendre le raisonnement à un composant (ex: service) particulier de l'application. Si je n'ai pas de logs de fonctionnement normal d'un service, c'est peut-être que j'ai oublié de configurer le démarrage du composant.
Enfin un exemple "contraire", celle où l'application ne semble pas fonctionner mais fonctionne pourtant. Imaginons les logs suivants :
22/12/2011 13:57:01 INFO [00001] Connexion de l'utilisateur DUPONT
22/12/2011 13:57:01 INFO [00002] Connexion de l'utilisateur DUFFOUR
22/12/2011 13:57:01 INFO [00001] Ouverture du document titi.txt
22/12/2011 13:57:01 INFO [00002] Ouverture du document titi.txt
22/12/2011 13:57:01 INFO [00002] Echec de la pause du verrou.
Pour avoir ce niveau de log, c'est bien au-délà de la gestion des erreurs. Le problème c'est que cela ne s'arrête pas à la gestion des logs mais également à la gestion des retours à l'utilisateur. Que préférez-vous parmis les retours possible pour l'utilisateur :
- Le logiciel a rencontré une erreur fatale
- Le logiciel n'a pas pu ouvrir le document
- Le document est verrouillé
- Le document est vérrouillé par un autre utilisateur
- Le document est verrouillé par DUPONT
Ce point aussi me gêne un peu :Envoyé par Henrik Warne
Pour le reste, comme d'habitude ce sont surtout des redîtes de bonnes pratiques qu'il est toujours facile de vendre dans la théorie mais la réalité est un peu différente. Je veux pas dire que c'est impossible en pratique, juste que parmi les milliers de petits détails qui tournent autour du code (documentation, test, couverture, qualimétrie, etc.) on finit nécessairement par négligé un paramètre et parfois ce sont les logs car il n'y a pas de piqûre de rappel (ex: Sonar).
Sans quitter le domaine de la journalisation, je trouve dommage qu'un billet traitant de ce sujet n'aborde même pas la notion de distinction entre les traces fonctionnelles et les traces techniques. Idem pour les notions de traçabilité, c'est-à-dire attribuer des identifiants (UUID) aux acteurs (utilisateurs, systèmes externes), aux erreurs (numéro que l'on remonte à l'utilisateur pour le suivi de l'anomalie), aux transactions (idem que précédemment), etc.
De manière plus générale, je pense à ce qui tourne autour de la robustesse. Je ne parles pas uniquement de la capacité d'un logiciel à résister aux erreurs mais aussi de sa capacité à fournir des informations détaillées, utiles et pertinentes ! Que ce soit pour le développeur mais également pour toutes les "parties prenantes" (utilisateur, AMO, équipe système, etc.). Car le maximum d'information on peut collecter et meilleure (rapidité, solutions proposées) sera l'analyse.
Sinon je voudrais revenir sur ce sujet : Viens alors le problème de tester les logs ! S'ils prennent une place importante, ils sont donc des "output" à vérifier lors de l'exécution du morceau de code.le 20/05/2015 à 14:35 -
markiorMembre habituéTout ça pour dire que si le code est bien construit aucun log ne devrait être écrit. Mais bon on est pas parfait et donc on doit en mettre quand même de temps en temps.le 20/05/2015 à 10:14
-
miky55Membre averti+1 à Saverok: l'utilisateur final n'en à rien à carrer que ton appel d'api à foirer ou de ton buffer overflow, tu lui affiche qu'une erreur est survenue et tu écris dans le log le trace. Les logs servent avant tout pour des applis en production dans le but d'analyser des situations qui n'ont pas été couvertes par les tests ou simplement pour le support technique.le 20/05/2015 à 12:54
-
DonQuicheExpert confirméEt les contrats représenteraient 90% du code, les coûts de développement seraient dix fois importants, la compilation durerait une minute, et les programmeurs débogueraient les contrats.
Les contrats, comme les tests ou les spécifications, sont avant tout une autre façon, peu compacte et partielle mais intentionnelle et plus compréhensible, d'exprimer le programme. C'est avant tout la redondance de ces modes d'expression qui entraîne la fiabilité. Une bonne solution dans les domaines où l'on a besoin de garanties fortes mais une solution coûteuse et fastidieuse.le 22/05/2015 à 14:47 -
captaindidouInactifJe trouve cet article bien peu réfléchi et manquant de recul sur le sujet. Tout court.le 20/05/2015 à 11:13
-
air-dexMembre expertUn bon debug va de pair avec une bonne pose des marques de debug, breakpoints ou logs (du printf à l'arrache en dev local au journal de logs). Donc des logs bien placés dans l'application facilitent forcément et grandement le débogage. Après il faut aussi faire attention au niveau de détails. Avoir des logs pour tout et n'importe quoi devient rapidement contre-productif. On passe son temps à chercher l'information importante parmi une palanquée d'informations toutes plus inutiles les unes que les autres.le 20/05/2015 à 22:47
-
Logan MauzaizeRédacteur/ModérateurC'est pour ca que le maximum de logs doivent être pensés en amont et être détaillé dans une spécification technique (ex: dossier de conception) ET fonctionnelle. Chaque type doit pouvoir être clairement distingué (ex: tables distinctes ou colonne de marquage) et il ne doit pas y avoir plus que marquer dans les spécifications.
Libre ensuite de rajouter d'autres types ou d'autres sources pour stocker des traces complémentaires ajoutés par les dev (ex: fichiers de log)
Rien n'empêche de faire redescendre les logs fonctionnels dans les logs techniques puis dans les traces pour avoir une source qui contient tous les "types".le 21/05/2015 à 11:15 -
BouskRédacteur/ModérateurDès que t'utilises une API externe, logger les codes retours erronés est vraiment un minimum à faire.le 21/05/2015 à 11:40
-
BouskRédacteur/ModérateurEntre autre à savoir que le flow normal ne s'est pas déroulé à cause d'une erreur de leur côté et non du tien. Et ça n'a rien à voir avec la validité des entrées.le 25/05/2015 à 9:42