Towards a Taxonomy of Software Log Smells

Cette étude propose une taxonomie de neuf « odeurs » de journalisation (log smells) dérivées d'une revue de littérature, en les reliant aux outils existants pour identifier les lacunes actuelles et orienter les futures recherches vers l'amélioration de la qualité du code de journalisation.

L'essentiel

Imaginez que le code d'un logiciel est comme une cuisine très complexe. Pour que tout fonctionne bien, les chefs (les développeurs) doivent cuisiner, mais ils ont aussi besoin de tenir un carnet de recettes (les logs) pour savoir ce qui s'est passé : quel ingrédient a été ajouté, à quelle heure, et si quelque chose a brûlé.

Ce papier de recherche parle de ce qui se passe quand ce carnet de recettes est mal tenu. Les auteurs appellent ces erreurs des « odeurs de journal » (ou log smells). Tout comme une odeur de renfermé dans une maison vous dit qu'il y a un problème (un tuyau qui fuit, de la moisissure), une « odeur de journal » indique qu'il y a un problème dans la façon dont le logiciel enregistre ses activités.

Voici l'explication simple de ce que les chercheurs ont découvert :

1. Le Problème : Pourquoi les carnets de recettes sentent-ils mauvais ?

Les développeurs ne sont pas toujours d'accord sur la façon de noter les choses. Parfois, ils écrivent trop, parfois pas assez, et souvent, ils écrivent n'importe quoi. Les chercheurs ont classé ces mauvaises habitudes en 9 grandes catégories d'odeurs :

• Le Chaos de Format (Format turmoil) : C'est comme si chaque chef écrivait ses notes dans un style différent. L'un utilise des crayons, l'autre des stylos, un troisième écrit en arabe, un autre en chiffres romains. Résultat : impossible de lire le carnet d'un seul coup d'œil.
• L'Identité Cachée (Undercover identifier) : Imaginez un message qui dit « La soupe a brûlé », mais sans dire qui l'a faite. Est-ce le chef de la soupe ? Le cuisinier du dessert ? Sans savoir qui est responsable, on ne peut pas régler le problème.
• Le Niveau de Panique Flou (Mercurial logging level) : C'est comme si un chef criait « AU FEU ! » (Erreur critique) quand il a juste renversé un peu de sel (Avertissement), et qu'il chuchotait « Tout va bien » quand il a fait tomber un fourneau entier. On ne sait plus quand il faut vraiment s'inquiéter.
• Le Mensonge des Variables (Deceptive variable) : Le chef écrit « J'ai ajouté du sucre », mais en réalité, il a mis du sel. Ou alors, il écrit « J'ai ajouté 100g de sucre » alors qu'il n'a mis que 5g. Les notes ne correspondent pas à la réalité.
• La Folie des Messages (Message madness) : Des phrases incompréhensibles, pleines de fautes d'orthographe, ou qui se répètent 50 fois de suite. C'est comme lire un livre où chaque page dit la même chose avec des mots différents.
• Le Silence des Gardiens (Logging lost in the wind) : C'est le cas où le chef oublie d'écrire qu'il a cassé un plat. Plus tard, on cherche la cause de la casse, mais le carnet est vide pour ce moment-là.
• La Décharge de Poubelle (Landfill logs) : À l'inverse, c'est quand le chef écrit tout : « J'ai respiré », « J'ai cligné des yeux », « J'ai marché ». Le carnet est si rempli de détails inutiles qu'on ne trouve jamais l'information importante (comme le plat brûlé).
• Les Gardes Endormis (Sleeping guards) : C'est quand le chef écrit une note, mais qu'il la fait écrire même quand il ne cuisine pas. Cela gaspille de l'énergie et de l'espace pour rien.
• Le Squelette dans le Placard (Skeleton in the closet) : C'est le code lui-même qui est mal écrit, compliqué et illisible. C'est comme si la recette était écrite dans un langage secret que personne ne comprend, rendant la cuisine dangereuse.

2. Les Causes : Pourquoi ça arrive ?

Les chercheurs ont trouvé 5 raisons principales pour lesquelles ces odeurs apparaissent :

• Pas de règles claires : Chaque chef fait ce qu'il veut.
• Manque d'expérience : Les nouveaux cuisiniers ne savent pas quoi noter.
• Des outils incompatibles : Certains utilisent des stylos, d'autres des tablettes, et ça ne parle pas le même langage.
• Des équipes séparées : La cuisine du dessert et celle du plat principal ne se parlent pas.
• Négligence : On écrit les notes au début, mais on oublie de les mettre à jour quand la recette change.

3. Les Conséquences : Pourquoi c'est grave ?

Si on ignore ces odeurs, ça peut mener à de gros problèmes :

• Fuites d'informations : On peut écrire par erreur un mot de passe ou un numéro de carte bancaire dans le carnet, et tout le monde peut le lire.
• Confusion sur le temps : On ne sait plus si un événement s'est produit avant ou après un autre.
• Ralentissement du système : Écrire trop de notes ralentit la cuisine (le logiciel).
• Effets secondaires bizarres : Parfois, le fait d'écrire une note peut faire planter la machine.

4. La Solution : Des robots pour nettoyer ?

Les chercheurs ont cherché s'il existait des « robots » (des outils logiciels) capables de réparer ces odeurs.

• Le verdict : Il existe 16 outils qui peuvent aider, mais ils ne sont pas magiques.
• Ce qu'ils font bien : Ils sont excellents pour corriger le niveau de panique (dire « c'est une erreur, pas un avertissement ») ou pour trouver les messages manquants.
• Ce qui manque : Il n'y a presque aucun outil pour réparer le « Chaos de format » ou pour aider les « Gardes endormis ». C'est comme si on avait des robots pour ranger les assiettes, mais personne pour apprendre aux chefs à écrire proprement.

En résumé

Ce papier nous dit : « Arrêtez de négliger vos carnets de recettes ! »
Si vous voulez que votre logiciel fonctionne bien et soit facile à réparer quand il plante, il faut arrêter de laisser les développeurs écrire n'importe quoi. Il faut des règles, de l'entraînement et des outils pour s'assurer que les notes sont claires, utiles et honnêtes. Sinon, vous finirez par chercher une aiguille dans une botte de foin, ou pire, vous ne saurez jamais pourquoi votre logiciel a planté.

Résumé technique

Voici un résumé technique détaillé de l'article "Towards a Taxonomy of Software Log Smells" (Vers une taxonomie des "mauvaises odeurs" de logs logiciels), rédigé en français.

1. Problématique et Contexte

Le journaling (logging) est une composante critique du développement logiciel moderne, utilisée pour le débogage, la surveillance et l'assurance qualité. Cependant, produire des logs de haute qualité est une tâche complexe sujette à de nombreuses erreurs. Bien que le concept de "mauvaises odeurs" (smells) soit bien établi dans d'autres domaines de l'ingénierie logicielle (comme les code smells pour indiquer des problèmes de conception sous-jacents), il n'existe pas encore de définition ni de taxonomie complète spécifique aux log smells (mauvaises odeurs de logs).

Les travaux existants se concentrent souvent sur des aspects spécifiques (comme les messages dupliqués ou les niveaux de log incorrects) sans offrir une vue d'ensemble. De plus, la distinction entre les problèmes affectant le code de journalisation et ceux affectant les fichiers de logs générés n'est pas toujours claire. L'objectif de cette étude est de combler ce vide en définissant une taxonomie complète des log smells, en identifiant leurs causes et conséquences, et en cartographiant les outils existants capables de les réparer.

2. Méthodologie

Les auteurs ont mené une enquête de littérature (survey) plutôt qu'une revue systématique de la littérature (SLR) complète, en raison de contraintes de ressources, tout en suivant les meilleures pratiques possibles.

• Sources de données : Recherche effectuée sur Google Scholar, IEEE Xplore, Scopus et la bibliothèque numérique ACM.
• Critères de sélection : 51 articles pertinents ont été retenus parmi 475 résultats initiaux. Les critères d'inclusion portaient sur des articles en anglais publiés depuis 2000, traitant des problèmes de journalisation logicielle.
• Processus d'analyse :
  1. Codage ouvert (Open Coding) : Extraction des problèmes de journalisation rapportés dans la littérature.
  2. Tri de cartes (Card Sorting) :
     • Tri ouvert : Pour regrouper les problèmes et définir des catégories initiales.
     • Tri fermé : Pour classer les problèmes dans trois catégories finales : Causes, Log Smells (les problèmes eux-mêmes), et Conséquences.
  3. Cartographie des outils : Identification et classification des outils automatisés capables de détecter ou de réparer ces problèmes.

3. Contributions Clés

L'article apporte trois contributions majeures :

1. Une définition formelle du "Log Smell" : Un choix de conception médiocre ou un problème impactant la qualité qui peut entraîner des problèmes plus graves, affectant le code de log, le fichier de log, ou les deux.
2. Une taxonomie de 9 Log Smells : Une classification hiérarchique divisant les problèmes selon qu'ils affectent le code (boîte blanche) ou l'artefact de log (fichier/entrée).
3. Une cartographie des outils de réparation : Une analyse de 16 outils existants et de leur capacité à adresser les facettes spécifiques de chaque smell.

4. Résultats Principaux

A. La Taxonomie des Log Smells (9 catégories)

Les auteurs ont identifié 9 log smells, divisés en deux grands groupes :

I. Affectant le Code de Journalisation (Invisible ou Transparent aux logs)

• LS8 : Sleeping guards (Gardes dormantes) : Absence ou mauvaise configuration des conditions protégeant l'exécution du code de log, entraînant des surcoûts de performance inutiles.
• LS9 : Skeleton in the closet (Squelette dans le placard) : Problèmes de qualité du code lui-même (code dupliqué, longueurs excessives, mauvaise lisibilité) liés à la création des logs. C'est un "meta-smell".

II. Affectant les Artefacts de Log (Fichiers et Entrées)

• LS1 : Format turmoil (Tourmente de format) : Incohérence, incomplétude ou absence de formats de log standardisés, rendant l'analyse difficile.
• LS2 : Undercover identifier (Identifiant caché) : Absence ou erreur dans les identifiants de composant/thread, empêchant de tracer l'origine d'un événement.
• LS3 : Mercurial logging level (Niveau de log changeant) : Niveaux de log (INFO, WARN, ERROR) manquants, incorrects ou incohérents pour un même type d'événement.
• LS4 : Deceptive variable (Variable trompeuse) : Variables manquantes, incorrectes, mal formées ou à granularité variable dans les messages de log.
• LS5 : Message madness (Folie de message) : Messages statiques imprécis, ambigus, dupliqués, avec des erreurs grammaticales ou des traductions incorrectes.
• LS6 : Logging lost in the wind (Log perdu dans le vent) : Absence de logs là où ils sont nécessaires (manque d'instructions de log ou niveau de verbosité trop bas).
• LS7 : Landfill logs (Décharge de logs) : Trop de logs inutiles, redondants ou trop détaillés, saturant le stockage et masquant les informations critiques.

B. Causes et Conséquences

• 5 Causes directes : Manque de guidelines, expérience/domaine des développeurs, bibliothèques de log hétérogènes, composants développés séparément, maintenance insuffisante du code de log.
• 4 Conséquences directes : Fuite d'informations sensibles (Information leak), incohérence temporelle, impact sur la performance du système, effets secondaires accidentels (modifications de l'état du logiciel).

C. État de l'art des Outils de Réparation

Sur les 16 outils identifiés :

• Couverture partielle : Les outils couvrent 6 des 9 smells, mais seulement 14 des 30 facettes identifiées.
• Points forts : Le smell "Mercurial logging level" (LS3) est le mieux couvert (7 outils).
• Vides critiques : Aucun outil n'existe spécifiquement pour réparer le "Format turmoil" (LS1), les "Sleeping guards" (LS8) ou les problèmes de code ("Skeleton in the closet", LS9).
• Limites : La plupart des outils se concentrent sur la correction des entrées de log (niveaux, messages) plutôt que sur la structure du code de log.

5. Signification et Impact

Cette étude est fondamentale pour la communauté de l'ingénierie logicielle car elle :

1. Structure le domaine : Elle passe d'une vision fragmentée des problèmes de log à une taxonomie unifiée, permettant aux chercheurs et praticiens de parler un langage commun.
2. Met en lumière les lacunes de la recherche : Elle révèle que malgré l'abondance d'outils d'analyse de logs, peu d'outils automatisés existent pour réparer les problèmes de conception (smells) avant qu'ils ne dégradent la qualité des logs.
3. Guide le développement futur : En identifiant les smells non couverts (notamment LS1, LS8, LS9), l'article oriente les futures recherches vers le développement d'outils de refactoring et de génération de code de log plus robustes.
4. Améliore la qualité logicielle : Comprendre ces smells aide les développeurs à éviter des problèmes coûteux tels que la perte de débogage, les fuites de données et la dégradation des performances.

En conclusion, les auteurs soulignent que les log smells sont omniprésents à toutes les étapes du cycle de vie du logiciel et que leur mitigation nécessite une approche combinant meilleures pratiques, guidelines claires et outils automatisés plus avancés.