Discussion :

[Amine Horseman]

Quelle est l’importance de la journalisation dans le débogage ?
Selon un sénior, « un bon programmeur ajoute beaucoup de logs à son programme »

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 ?

[MikeRowSoft]

Il n'a rien pris au sérieux. Sinon il serait passé de 1 à 8 niveau distinct de débogage au minimum.

[Angelsafrania]

Les logs dont monsieur le seigneur (euh sénior) nous parle sont des logs au cours d'exécution de la méthode (notez que je vais parler que de programmation objet).
Normalement une méthode n'a pas 50 milles trucs à faire, sinon on est dans un mauvais design (eq pas très bon développeur).
Donc si notre méthode est suffisamment bien construite alors juste le log des appels de méthode suffit. Un des cas d'école de la programmation par aspect.

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.

[dfiad77pro]

C'est assez différent dans la réalité,
Dans un développement d'entreprise ou de multiples mains passent sur un code, sans revues de code , on trouve souvent ce genre de chose :

Code C# :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
try{
 
// 200 lignes de code
 
}catch(Exception e){
 
//Rien
 
}

Donc une floppée de log qui ralentissent l'application ( log4J / Log.NET, etc...) n'est souvent utile que pour les appels aux services, requêtes ,etc.

De plus, pour le cas des module très complexes et liés ( moteur de calcul , etc) , il vaut mieux spécifier des logs compréhensifs ( en plus des automatiques) et faire des vrais tests unitaires mettant en oeuvre les règles de gestion métiers.

[Julien Bodin]

Il faut bien prendre conscience du fait qu'ajouter des logs permettra probablement de gagner du temps plus tard. C'est un peu lourd quand on code mais c'est vrai que c'est très important. L'AOP aide beaucoup mais on monte d'un cran en complexité. C'est un sujet qui, idéalement, devrait être pensé dès la conception.

Attention cependant à ne pas pénaliser les performances de l'application, il faut vraiment étudier l'ensemble des fonctionnalités proposées par son framework de logging et respecter les bonnes pratiques.

[markior]

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.

Je ne suis pas d'accord. Les logs ne sont pas là que pour déboguer un programme. Pour moi, pour une exécution sans problème, la log doit pouvoir être lue et comprise par n'importe qui ayant une connaissance du fonctionnel.

[captaindidou]

Je trouve cet article bien peu réfléchi et manquant de recul sur le sujet. Tout court.

[TiranusKBX]

Les log d'erreurs ne sont pas utile pour tous les programmes
pour les programmes serveur oui vus que l'on n'à pas d'interface d'affichage mais pour les programmes avec interface graphique tu affiche les erreurs !

[Saverok]

Les log d'erreurs ne sont pas utile pour tous les programmes
pour les programmes serveur oui vus que l'on n'à pas d'interface d'affichage mais pour les programmes avec interface graphique tu affiche les erreurs !

Pourquoi 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.

[miky55]

Les log d'erreurs ne sont pas utile pour tous les programmes
pour les programmes serveur oui vus que l'on n'à pas d'interface d'affichage mais pour les programmes avec interface graphique tu affiche les erreurs !

+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.

[dfiad77pro]

Pourquoi 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.

En parti d'accord avec une petite nuance

Cela est valable pour les exceptions contrôlées et correctement prise en charge ( message fonctionnel personnalisé).

Si un plantage se produit l'utilisateur doit être informé et l'erreur généraliste logué .

Dans le cadre d'un client lourd autonome on ne peut pas toujours tout loguer à distance ou sur le journal d'événement ( dans le cas de Windows).

Sur un plantage technique, si tu lui affiche que " Erreur technique" sans bouton détail ,
lorsque l'utilisateur ouvrira un ticket (il ne se souvient pas forcément de l'heure exacte de son plantage), il faut impérativement sur que le support puisse aller chercher rapidement les logs.
De plus si le plantage n'est pas reproductible, c'est pas évident.

[Logan Mauzaize]

Êtes-vous d’accord avec l’avis de Henrik Warne ?

Surtout pas à ce sujet :

Lorsque le programme fonctionne comme prévu, il n'y a souvent pas de différence dans la qualité des logs.

La qualité du log est justement indépendante du bon fonctionnement de l'application. Et d'ailleurs, je pense que le billet est basé sur cette idée biaisée que le log sert uniquement à comprendre un mauvais fonctionnement. Or les logs servent à la supervision de manière générale.
Et le dé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.

Il suffit de recouper les informations d'une même transaction "[XXXXXX]" pour comprendre que DUFFOUR a essayé d'ouvrir le fichier titi.txt mais qu'il n'a pas pu obtenir le 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 :

1. Le logiciel a rencontré une erreur fatale
2. Le logiciel n'a pas pu ouvrir le document
3. Le document est verrouillé
4. Le document est vérrouillé par un autre utilisateur
5. Le document est verrouillé par DUPONT

Ce point aussi me gêne un peu :

un bon programmeur ajoute beaucoup de logs à son programme

Autant il est utile d'ajouter des traces précises autant il faut éviter d'en balancer de trop. Au risque de saturer les espaces de stockage (ou voir de perdre de l'information à cause de système de débordement/roulement), de rallonger les temps de traitement (manuel ou automatique), voir même d'exposer des informations sensibles.

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).

À part la journalisation, quelles autres habitudes pourraient aider les développeurs lors du débogage ?

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 :

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 ».

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.

[Kdence]

Pas tout a fait d'accord...
Si le développeur est seul a travailler sur son code, que le programme n'est pas trop complexe, qu'il est correctement architecturé (architecture MVC, méthodes courtes, etc...) je pense qu'il n'est pas forcément nécessaire de journaliser les appels. Personnellement, je n'en ai jamais eu besoin pour debogguer mon code. Après, si quelqu'un passe après moi et qu'il y a un bug, il mettra certainement plus de temps à trouver la source de ce dernier. Mais dans mon cas (autodidacte solitaire, développeur de mon propre CMS) ce n'est absolument pas utile. Quand je sais qu'un scenario pourrait m'échapper, de simples "Try/Catch" me suffisent amplement.

Mais comme je l'ai dit, quand on est plusieurs a taffer sur le code, alors il vaut mieux journaliser.

[mermich]

Les logs c'est comme les commentaires:

• Un code bien ecrit va tester les input et renvoyer des exceptions si incorrects pour l'exemple cite
• Comme les commentaires, les textes ne sont pas maintenus
• Comme les commentaires, les logs sont plus ou moins ecris par developpeurs
• Comme les commentaires, cela poulle la lecture du code
• Comme les commentaires on va mettres des logs pour expliquer du code mal ecrit

Les seuls logs utiles sont:

• Pour les execptions pour avoir une trace a exploiter en prod/devs a envoyer par mail pour les client lourd
• Pour l'audit de perfomances par exmples
• Pour remplir du disque dur

Bref, clean code a tout dit il sufffisait de remplacer commentaire par log

Le seul probleme on bosse tous en ssii, ou en equipes a la bourre, donc on fait du taff de merde (moi compris ofc), on controle pas les entree/sorties donc on mets des logs a l'arrache avec de preference un bon gros objet dto de 40 proprietes.

[air-dex]

Un 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.

[Logan Mauzaize]

Le seul probleme on bosse tous en ssii, ou en equipes a la bourre, donc on fait du taff de merde (moi compris ofc), on controle pas les entree/sorties donc on mets des logs a l'arrache avec de preference un bon gros objet dto de 40 proprietes.

C'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".

[Bousk]

Dès que t'utilises une API externe, logger les codes retours erronés est vraiment un minimum à faire.

[mikrethor]

C'est essentiel de journaliser les différents traitements du code pour pouvoir analyser ce qui se passe sur la plateforme de production.
Voir le cheminement d'un traitement permet de comprendre ce qui se passe.

Il faut bien sûr faire attention aux performances mais maintenant, il existe beaucoup de framework de journalisation qui limitent leur impact sur l'éxecution du code.

[mermich]

ouais franchement :

C'est essentiel de journaliser les différents traitements du code pour pouvoir analyser ce qui se passe sur la plateforme de production.

Quand t'as une appli web avec plus de 100 utilisateurs simultanes, lire les logs va etre un veritable plaisir.

Voir le cheminement d'un traitement permet de comprendre ce qui se passe.

Sur une quinzaine de niveaux avec differents threads c'est lisible.

Dès que t'utilises une API externe, logger les codes retours erronés est vraiment un minimum à faire.

Cela ca t'avances a quoi de plus que verifier les entrees sorties et envoyer une exeption, de plus un api externe devrait toujours etre imbriquee dans un autre conteneur (cf clean code ou code complete pour plus de details et explications).

C'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".

Du coup avec cela le taff du dev est triple: mettre des commentaires et les maintenir, mettre des logs avec du vrai texte et les maintenir/ et faire son taff(tester les entree sorties) et le maintenir. Au final les applis ressemblent a des soupes de commentaires + logs pour ne garder que peu de lignes utiles A force de parcourirdu code mal ecrit j'ai developpe une competence qui me permet de ne jamais 'voir' voir les commentaires/logs ecris dans un code car trop souvent pas maintenus ou juste faux.

Comme je le dis aux autres developpeurs : Contrairements aux commentaires/logs le code ne ments pas.

Le plus drole c'est lorsque le developpeur joue avec les niveau de log, ca devient ridicule :on logge l'entree en debug et la sortie en info et paf surprise on ne voit plus les logs de sorties.

[GeoffreyOnRails]

L'auteur marque un point : il est vrai qu'on a rapidement tendance a oublier la problématique des logs, tout simplement car cela sera surtout utile aux équipes de production (plus qu'aux devs), et que le client ne le verra absolument pas.

En revanche, les logs ne servent pas qu'à investiguer en cas d'incident comme on peut le penser en lisant l'article, mais à une valeur aussi en fonctionnement normal. Outre l'intérêt fonctionnel déjà évoqué, même en fonctionnement normal les logs ont un intérêt technique pour les équipes de prod.

Imaginons un système de batch, j'ai sûrement envie de savoir dans mes logs, le temps qu'à pris un gros batch, quelques infos sur les fichiers reçus (genre la taille et qui les envoie)... J'ai peut-être aussi envie d'utiliser mes logs si jamais un utilisateur externe essaie de faire n'importe quoi, même si il n'a rien cassé (sécurité). Je m'éloigne de mon domaine mais il semblerait que l'analyse de logs soit utilisés pour améliorer le référencement d'un site web.
Bref, les logs font partie de l'application, et pas uniquement pour les erreurs ou le deboggage.

En recherchant un peu les bonnes pratiques, je suis tombé sur cet article, que je vous conseille. Il ne dit pas quoi logger, mais comment créer de bons logs, je pense que c'est aussi utile.
http://www.javacodegeeks.com/2011/01...n-logging.html