Rapport entre le code et l'exploitation forestière ?

Question

Quel est le rapport idéal entre le code et l'exploitation forestière ? Je n'ai pas l'habitude d'écrire des journaux, car la plupart des applications que j'ai développées ne comportaient pas beaucoup de journaux.

Récemment, j'ai changé de travail et j'ai remarqué qu'on ne peut pas voir le code de l'application pour les appels à log4net. Je comprends que c'est utile, mais avoir trop de déclarations de débogage est sûrement aussi mauvais que de ne pas en avoir du tout ?

Il existe des déclarations de journalisation qui vous indiquent quand chaque méthode commence et finit et ce qu'elle renvoie. et quand à peu près tout est fait.

Ne serait-il pas plus facile d'avoir un addon qui utilise la réflexion pour ajouter les déclarations de journalisation au moment de la compilation, de sorte qu'elles ne se retrouvent pas dans le chemin lorsque vous essayez de regarder le code ?

De plus, à l'heure des IDE puissants et du débogage à distance, une telle journalisation est-elle vraiment nécessaire ?

Answer 1

Étant donné que log4net fait un excellent travail en n'encombrant pas les ressources, j'ai tendance à être un peu verbeux sur la journalisation car lorsque vous devez passer en mode débogage, plus vous avez d'informations, mieux c'est. Voici ce que j'enregistre généralement :

Niveau DEBUG

• Tous les paramètres passés dans le méthode
• Tous les comptes de lignes des ensembles de résultats que je récupère
• Tous les flux de données qui peuvent contenir des données suspectes lorsqu'ils sont transmis à la méthode.
• Tous les chemins de fichiers "générés", les chaînes de connexion ou d'autres valeurs qui pourraient être mélangées lors de leur assemblage par l'environnement.

Niveau INFO

• Le début et la fin de la méthode
• Le début et la fin de toute boucle importante
• Le début d'une affaire ou d'une déclaration importante.

Niveau ERROR

• Gestion des exceptions
• Tentatives de connexion invalides (si la sécurité est un problème)
• Les mauvaises données que j'ai interceptées pour le reportage

Niveau FATAL

• Exceptions non gérées.

De plus, le fait de disposer d'un grand nombre de détails de journalisation m'empêche de demander à l'utilisateur ce qu'il faisait lorsqu'il a reçu le message d'erreur. Je peux facilement le reconstituer.

Answer 2

De plus, à l'heure où l'on dispose d'IDE puissants et d'un débogage à distance, un tel niveau de journalisation est-il vraiment nécessaire ?

Oui, tout à fait, même si l'erreur que commettent de nombreux développeurs non qualifiés est d'essayer de corriger les bogues en utilisant la mauvaise méthode, en tendant généralement vers la journalisation alors qu'ils devraient déboguer. Il y a une place pour chacun, mais il y a au moins quelques domaines où la journalisation sera presque toujours nécessaire :

• Pour l'examen de problèmes dans un code en temps réel, lorsqu'une pause avec le débogueur aurait un effet sur le résultat du calcul (il est vrai que la journalisation aura un léger impact sur le temps dans un processus en temps réel comme celui-ci, mais l'ampleur de cet impact dépend beaucoup du logiciel).
• Pour les constructions envoyées aux bêta-testeurs ou à d'autres collègues qui n'ont peut-être pas accès à un débogueur.
• Pour vider sur le disque des données qui ne sont pas toujours faciles à visualiser dans un débogueur. Par exemple, certains IDE ne peuvent pas analyser correctement les structures STL.
• Pour avoir une idée du déroulement normal de votre programme.

• Pour faire du code plus de lire et de commenter, comme ça :

  // Now open the data file fp = fopen("data.bin", "rb");

Le commentaire ci-dessus pourrait tout aussi bien être placé dans un appel à l'enregistrement :

const char \*kDataFile = "data.bin";
log("Now opening the data file %s", kDataFile);
fp = fopen(kDataFile, "rb");

Cela dit, vous avez raison à certains égards. L'utilisation du mécanisme de journalisation en tant que traceur de pile glorifié générera des fichiers de journalisation de très mauvaise qualité, car il ne fournit pas un point de 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 journalisation, qui, je pense, se résume à la discrétion du développeur. Vous devez prendre en compte le fait que vous créez essentiellement les fichiers journaux pour vous-même Vos utilisateurs ne s'y intéressent pas et interpréteront de toute façon mal leur contenu, mais vous pouvez les utiliser pour déterminer au moins pourquoi votre programme s'est mal comporté.

En outre, il est assez rare qu'un fichier journal vous indique la source directe d'un certain bogue. D'après mon expérience, il fournit généralement un aperçu de la manière dont vous pouvez reproduire un bogue, puis, soit en le reproduisant, soit en le déboguant, trouver la cause du problème.

Answer 3

Les fichiers journaux complets sont étonnamment utiles. Considérez une situation où votre application est déployée dans un endroit comme une banque. Vous ne pouvez pas y aller et la déboguer à la main et ils ne vont certainement pas vous envoyer leurs données. Ce que vous pouvez obtenir, c'est un journal complet qui peut vous indiquer où le problème est survenu. Il est très utile de disposer de plusieurs niveaux de journal. Normalement, l'application fonctionne dans un mode tel qu'elle ne signale que les erreurs fatales ou les erreurs graves. Lorsque vous avez besoin de déboguer l'application, 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 l'affirmer sans en savoir plus sur l'application et l'endroit où elle pourrait être déployée.

Answer 4

Il existe en fait une bibliothèque intéressante pour ajouter la journalisation après coup, comme vous le dites, PostSharp . Il vous permet de le faire par le biais de la programmation basée sur les attributs, parmi de nombreuses autres choses très utiles au-delà de la simple journalisation.

Je reconnais que ce que vous dites est un peu excessif pour l'exploitation forestière.

D'autres personnes ont soulevé de bons points, en particulier le scénario bancaire et d'autres applications critiques. Il peut être nécessaire de procéder à une journalisation extrême, ou au moins de pouvoir l'activer et la désactiver si nécessaire, ou de définir différents niveaux.

Answer 5

Que beaucoup de journalisation n'est pas nécessaire. Il n'y a pas de raison (à la production) de savoir quand chaque méthode commence et se termine. Vous devez peut-être que sur certaines méthodes, mais avoir autant de bruit dans les fichiers journaux les rend presque impossibles à analyser de manière efficace.

Vous devez vous connecter quand se produire des choses importantes, telles que les erreurs, les connexions de l'utilisateur (journal d'audit), les opérations ont commencé, d'importantes données mises à jour... ainsi de suite et ainsi de suite. Si vous avez un problème que vous ne pouvez pas comprendre à partir des journaux, alors vous pouvez ajouter plus si nécessaire... mais seulement si nécessaire.

Aussi, juste pour votre information, l'ajout de connexion au moment de la compilation serait un exemple de ce qu'on appelle la Programmation Orientée Aspects. La journalisation serait la "croix de coupe de préoccupation".