Code au rapport d’enregistrement?

Quel est le code idéal pour le rapport de journalisation? Je n’ai pas l’habitude d’écrire des logs car la plupart des applications que j’ai développées n’ont pas beaucoup consigné.

Récemment, j’ai changé de travail et j’ai remarqué que vous ne pouviez pas voir le code de l’application pour les appels à log4net. J’apprécie le fait que cela soit utile, mais avoir trop de déclarations de débogage est aussi mauvais que de ne pas en avoir du tout?

Des instructions de journalisation vous indiquent quand chaque méthode démarre et se termine et ce qu’elles renvoient. et quand à peu près tout est fait.

Ne serait-il pas plus facile d’avoir un addon qui utilise la reflection pour append les instructions de journalisation au moment de la compilation afin qu’elles ne gênent pas la lecture du code?

En outre, à l’époque des puissants IDE et du débogage à distance, est-ce que la journalisation est vraiment inutile?

Il y a en fait une bibliothèque intéressante à append à la connexion après le fait, comme vous le dites, PostSharp . Il vous permet de le faire via une programmation basée sur des atsortingbuts, parmi de nombreuses autres choses très utiles au-delà de la simple journalisation.

Je suis d’accord que ce que vous dites est un peu excessif pour l’exploitation forestière.

D’autres évoquent de bons points, notamment le scénario bancaire et d’autres applications critiques. Cela peut être nécessaire pour une journalisation extrême, ou du moins pour pouvoir l’activer ou la désactiver si nécessaire, ou pour régler différents niveaux.

Comme log4net fait un excellent travail pour ne pas encombrer les ressources, j’ai tendance à être un peu prolixe sur la journalisation car lorsque vous devez passer en mode débogage, plus vous avez d’informations, mieux c’est. Voici ce que je connecte généralement:

Niveau DEBUG

  • Tous les parameters passés dans la méthode
  • Toute ligne compte des jeux de résultats que je récupère
  • Toutes les lignes de données pouvant contenir des données suspectes lors de leur transmission à la méthode
  • Tout chemin de fichier, chaîne de connexion ou toute autre valeur “générée” qui pourrait être récupéré par l’environnement.

Niveau INFO

  • Le début et la fin de la méthode
  • Le début et la fin de toute boucle majeure
  • Le début de toute instruction majuscule / commutateur

Niveau d’erreur

  • Exceptions traitées
  • Tentatives de connexion incorrectes (si la sécurité pose problème)
  • Mauvaises données que j’ai interceptées pour rapport

Niveau FATAL

  • Exceptions non gérées.

Le fait d’avoir beaucoup de détails de journalisation m’empêche également de demander à l’utilisateur ce qu’il faisait quand il a reçu le message d’erreur. Je peux facilement le reconstituer.

Les fichiers journaux complets sont incroyablement utiles. Considérez une situation où votre application est déployée quelque part comme une banque. Vous ne pouvez pas aller là-bas et le déboguer à la main et ils ne vont certainement pas vous envoyer leurs données. Ce que vous pouvez obtenir est un journal complet qui peut vous indiquer où le problème est survenu. Avoir un certain nombre de niveaux de journalisation est très utile. Normalement, l’application s’exécuterait dans un mode tel qu’elle ne signale que les erreurs fatales ou graves. Lorsque vous devez le déboguer, un utilisateur peut activer la sortie de débogage ou de trace et obtenir beaucoup plus d’informations.

Le type de journalisation que vous voyez semble excessif, mais je ne peux pas vraiment le dire avec certitude sans en savoir plus sur l’application et son déploiement éventuel.

En outre, à l’époque des puissants IDE et du débogage à distance, est-ce que la journalisation est vraiment inutile?

Oui, absolument, bien que l’erreur commise par de nombreux développeurs non qualifiés soit d’essayer de corriger les bogues en utilisant la mauvaise méthode, généralement vers la journalisation lorsqu’ils devraient être débogués. Il y a une place pour chacun, mais il y a au moins quelques zones où l’exploitation forestière sera presque toujours nécessaire:

  • Pour examiner les problèmes en code temps réel, une pause avec le débogueur affecterait le résultat du calcul (accordée, la consignation aura un léger impact sur la synchronisation dans un processus en temps réel comme celui-ci, mais cela dépend beaucoup du logiciel)
  • Pour les versions envoyées à des bêta-testeurs ou à d’autres collègues qui n’ont peut-être pas access à un débogueur
  • Pour transférer des données sur le disque, il peut être difficile à afficher dans un débogueur. Par exemple, certains IDE qui ne peuvent pas parsingr correctement les structures STL.
  • Pour avoir un “ressenti” du déroulement normal de votre programme
  • Pour rendre le code plus lisible en plus de commenter, comme ceci:
 // Ouvrez maintenant le fichier de données
 fp = fopen ("data.bin", "rb");

Le commentaire ci-dessus pourrait aussi bien être placé dans un appel de consignation:

 const char * kDataFile = "data.bin";
 log ("Ouvrir maintenant le fichier de données% s", kDataFile);
 fp = fopen (kDataFile, "rb");

Cela dit, vous êtes à certains égards correct. L’utilisation du mécanisme de journalisation comme enregistreur de trace de stack glorifié générera des fichiers journaux de très mauvaise qualité, car il ne fournit pas un sharepoint défaillance suffisamment utile pour que le développeur puisse l’examiner. La clé ici est évidemment l’utilisation correcte et prudente des appels de consignation, ce qui, à mon avis, revient à la discrétion du développeur. Vous devez considérer que vous faites essentiellement les fichiers journaux pour vous-même ; vos utilisateurs ne se soucient pas d’eux et interpréteront généralement leur contenu de manière grossière, mais vous pouvez au moins les utiliser pour déterminer pourquoi votre programme s’est mal comporté.

De plus, il est assez rare qu’un fichier journal vous indique la source directe d’un certain bogue. D’après mon expérience, cela donne généralement un aperçu de la manière dont vous pouvez répliquer un bogue, puis, soit en le répliquant, soit en le déboguant, recherchez la cause du problème.

Que beaucoup de consignation n’est pas nécessaire. Il n’y a aucune raison (en production) de savoir quand chaque méthode commence et se termine. Peut-être avez-vous besoin de cela sur certaines méthodes, mais le fait d’avoir beaucoup de bruit dans les fichiers journaux les rend pratiquement impossibles à parsingr efficacement.

Vous devez enregistrer les événements importants tels que les erreurs, les connexions utilisateur (journal d’audit), les transactions démarrées, les données importantes mises à jour, etc. Si vous ne parvenez pas à identifier un problème dans les journaux, vous pouvez en append si nécessaire … mais uniquement si nécessaire.

De plus, juste pour votre information, l’ajout de la connexion à la compilation serait un exemple de ce que l’on appelle la programmation orientée aspect . L’exploitation forestière serait la “préoccupation transversale”.

Lorsque vous avez un scénario client (c.-à-d. Une machine dont vous n’avez pas access physiquement), les seules choses qui “consumnt trop” sont les fonctions de repeindre et presque tout ce qui est appelé (ce qui devrait être presque nul). Ou d’autres fonctions appelées 100 fois par seconde pendant le fonctionnement (le démarrage du programme est correct, cependant, pour avoir 100 appels pour obtenir / définir des routines consignées parce que, selon mon expérience, c’est la plupart des problèmes qui surviennent).

Sinon, vous ne ferez que vous-même lorsque vous manquez un sharepoint journal clé qui vous dira définitivement quel est le problème sur la machine de l’utilisateur.

(Remarque: je fais référence à la journalisation qui se produit lorsque le mode trace est activé pour les journaux orientés développeur, et non vers les journaux d’opérations normaux orientés utilisateur).

Lorsque vous rencontrez un bogue lors de la version bêta de votre application et que vous ne pouvez pas le reproduire, vous savez que vous devriez avoir effectué une journalisation excessive. De la même manière, si un client signale un bogue mais que vous ne pouvez pas le reproduire, une fonctionnalité de journalisation excessive peut vous faire gagner du temps.

Je pense que “log to code ratio” est une mauvaise compréhension du problème.

Dans mon travail, j’ai parfois une situation où un bogue dans un programme Java ne peut pas être reproduit en dehors de l’environnement de production et où le client NE veut PAS que cela se reproduise.

Ensuite, TOUTES les possibilités dont vous disposez pour corriger le bogue sont les informations que vous avez vous-même insérées dans les fichiers journaux. Pas de sessions de débogage (ce qui est interdit dans les environnements de production de toute façon) – pas d’attaque sur les données d’entrée – rien!

Donc, les journaux sont votre machine de temps quand le bogue est arrivé, et comme vous ne pouvez pas prédire à l’avance quelles informations vous aurez besoin pour corriger un bogue encore inconnu – sinon vous pourriez simplement corriger le bogue – vous devez vous connecter beaucoup de choses…

Exactement ce qui dépend du scénario, mais fondamentalement suffisant pour vous assurer que vous ne doutez jamais de ce qui se passe où 🙂

Naturellement, cela signifie que BEAUCOUP de journalisation se produira. Vous allez ensuite créer deux journaux: un avec tout ce qui est conservé assez longtemps pour que vous n’en ayez pas besoin, et l’autre avec des informations non sortingviales qui peuvent être conservées plus longtemps.

Le rejet de la journalisation comme étant excessif est généralement effectué par ceux qui n’ont pas eu à corriger un bogue avec rien d’autre à passer 🙂

Combien de ces lignes se connectent par défaut? J’ai travaillé sur un système qui ressemble beaucoup à ce que vous décrivez – le simple fait de le démarrer entraînerait l’écriture de plus de 20 Mo de journaux si la journalisation était augmentée, mais même le débogage n’a pas été optimisé pour tous les modules . Par défaut, il enregistre un module de code et des événements système majeurs. C’était génial pour le débogage, car QA pouvait simplement attacher un journal à un ticket, et même si ce n’était pas reproductible, vous pouviez voir ce qui se passait quand le problème est arrivé. Si vous avez un multithreading sérieux, la journalisation est encore meilleure que celle de tout IDE ou débogueur avec lequel j’ai travaillé.

Je trouve que la journalisation est beaucoup moins nécessaire depuis que j’ai commencé à utiliser TDD. Il est beaucoup plus facile de déterminer où se trouvent les bogues. Cependant, je trouve que les instructions de journalisation peuvent aider à comprendre ce qui se passe dans le code. Bien sûr, les débogueurs aident à vous donner une idée de bas niveau de ce qui se passe. Mais je trouve plus facile de faire correspondre une ligne de sortie à une ligne de code si je veux avoir une vue d’ensemble de ce qui se passe.

Cependant, une chose que je devrais append est la suivante: assurez-vous que vos instructions de journal incluent le module dans lequel se trouve l’instruction de journal! Je ne peux pas compter le nombre de fois où j’ai dû retourner et trouver où se trouve une déclaration de journal.

Je crois personnellement que tout d’abord, il n’y a pas de règle ssortingcte. J’ai des applications qui enregistrent un LOT, dans et hors des méthodes, et des mises à jour d’état par le milieu. Ces applications sont des processus planifiés, exécutez-les et les journaux sont analysés par une autre application qui stocke les succès / échecs.

J’ai constaté que dans la réalité, de nombreuses applications utilisateur n’ont pas besoin de beaucoup de consignation, car en réalité, si des problèmes surviennent, vous devrez déboguer pour y retrouver les valeurs. De plus, vous n’avez généralement pas besoin des frais de connexion.

Cependant, cela dépend vraiment du projet.

Dans mon travail, j’écris beaucoup de services Windows. Pour moi, l’exploitation forestière n’est pas un luxe; c’est en fait ma seule interface utilisateur. Lorsque nous déployons nos activités en production, nous perdons l’access au débogage et même aux bases de données sur lesquelles nos services écrivent et sans nous connecter, nous n’aurions aucun moyen de connaître les détails des problèmes qui surviennent.

Cela dit, je pense qu’un style de journalisation concis est la meilleure approche. Les messages de journalisation ont tendance à se limiter à la logique métier de l’application, par exemple “message reçu du compte xxx” à “fonction entrée yyy”. Nous enregistrons les exceptions, les threads démarrent, font écho aux parameters d’environnement et aux timings. Au-delà de cela, nous nous tournons vers le débogueur pour identifier les erreurs logiques dans les phases de développement et d’assurance qualité.

Je dois avouer que lorsque j’ai commencé à programmer, j’ai plus ou moins consigné tous les détails comme décrit par “Dillie-O”.

Croyez-moi … Cela a beaucoup aidé pendant les premiers jours du déploiement de la production, où nous avons beaucoup compté sur les fichiers journaux pour résoudre des centaines de problèmes.

Une fois que le système est devenu stable, j’ai lentement commencé à supprimer les entrées de journal à mesure que leur valeur ajoutée commençait à diminuer. (Pas de Log4j à ce moment-là.)

Je pense que le ratio des entrées de code à journal dépend du projet et de l’environnement et qu’il n’est pas nécessaire qu’il soit constant.

Aujourd’hui, nous avons beaucoup de flexibilité dans la journalisation avec des packages tels que Log4j, l’activation dynamic du niveau de journalisation, etc.

Mais si les programmeurs ne l’utilisent pas correctement, par exemple quand utiliser, quand ne pas utiliser INFO, DEBUG, ERROR etc. ainsi que des détails dans les messages du journal (j’ai vu un message comme: “Bonjour X, Bonjour XX Bonjour XXX, etc. “que seul le programmeur peut comprendre”, le ratio continuera à être élevé avec moins de ROI .

Je pense qu’un autre facteur est le jeu d’outils / la plate-forme utilisée et les conventions qui l’accompagnent. Par exemple, la journalisation semble être très répandue dans le monde J (2) EE, alors que je ne me souviens pas avoir écrit une instruction de journal dans une application Ruby on Rails.