À quelle étape ajoutez-vous la journalisation et le traçage dans OO?

Question

Je suis intéressé à quelle étape de votre développement ajoutez-vous la journalisation et/ou le traçage à vos applications?

Je travaille avec une pile .Net et log4net (via commons.logging). Généralement, en adoptant une approche TDD pour le développement, bien que ce ne soit pas 100%, je sais parfois que je saisis sans couverture de test. Mon application est tout assise côté serveur, par ex. services Web, service Windows qui consomment des messages à partir d'un bus, asp.net mvc applications d'administration d'entreprise.

Je me suis trouvé des méthodes de décoration dans mes services applicatiosn avec descriptive logger.INFO "Obtenir des gâteaux à partir du référentiel". certains travaux .. "Got 5 gâteaux de dépôt.", puis un gestionnaire d'expcetion non gérée pour l'application doamin à logger.FATAL pour les excpetions inattendues qui bouillonnent.

Cependant, je finis généralement par revenir en arrière et les appliquer vers la fin du développement plutôt qu'au début du développement et je pourrais en avoir une douzaine ou deux seulement. Je trouve que je décore rarement les classes de niveau inférieur telles que l'implémentation de ICakeRepository avec des éléments de journalisation, car cela semble inutile. Pour le traçage, qui est activé via la configuration, je pense à intercepter les appels de méthode et la création d'instance en utilisant le framework IOC, et cela devrait prendre en charge la recherche de dérangement sur site plutôt que sur les traces lourdes.

Answer 1

Mon logiciel est en couches, avec une API bien définie entre chaque couche. J'ai tendance à implémenter la journalisation de ces API dès le début, de sorte que pour une transaction donnée, je peux voir comment cela aboutit à un appel API sur chacune des couches sous-jacentes: s'il y a une erreur, cela aidera à la réduire couche. L'enregistrement aidera également à reproduire un problème en montrant un journal de toutes les activités normales précédentes qui ont mené au problème. J'ai également ajouter des assertions dans chaque couche où je peux, et enregistrer les échecs d'assertion. Un fichier journal montre donc souvent une séquence d'appels aux API publiques, avec un message d'erreur généré depuis l'intérieur: c'est souvent suffisant pour diagnostiquer le problème. Au-delà, j'ajoute la journalisation au niveau du débogage selon les besoins: pour déboguer des problèmes spécifiques pendant le développement et/ou après la publication.

Mon raisonnement pour se soucier de l'exploitation forestière s'explique en partie dans les domaines suivants:

• Separate ‘debug’ and ‘release’ builds?
• Should one test internal implementation, or only test public behaviour?

Pour résoudre un bogue dans le logiciel sorti, je dépends du fichier journal; et il en va souvent de même pour les logiciels en cours de développement.

---

Vous avez dit,

Je trouve que je décore rarement des classes de niveau inférieur telles que la mise en œuvre de ICakeRepository avec des trucs de l'enregistreur comme il semble inutile.

je l'ai dit,

Mon logiciel est en couches, avec une API bien définie entre chaque couche. J'ai tendance à implémenter la journalisation pour ces API dès le début ...

Je pense que je ferais mieux d'expliquer ce que je veux dire par "couches", qui peuvent être ou ne pas être les mêmes que vos classes "de niveau inférieur" .

Par exemple, mon système pourrait avoir les couches suivantes:

• UI
• couche d'affaires (règles de manipulation de données)
• de couche d'accès aux données (pour la base de données E/S)
• Base de données

Dans ce cas, j'aurais les interfaces ou API suivantes, qui pourraient mériter la journalisation:

• Entre l'utilisateur et l'interface utilisateur (c.-à-d. les événements de l'interface utilisateur, souris et clavier)
• entre l'interface utilisateur et la couche d'affaires (voir « boîte de dialogue Humble »)
• Entre la couche d'affaires et le DAL
• Entre le DAL et la base de données

Alternativement, le système pourrait être une chaîne de composants reliant deux points d'extrémité homologues (moins évidemment avec les couches "supérieure" et "inférieure").

En tout cas, ce que je vous connecter est l'API qui est façade publique de chaque composant, ce qui est bon pour l'exploitation forestière pour plusieurs raisons:

• Pas trop compliquée (la façade a tendance à être plus simple que le sous-jacent/implémentation interne)
• Bonne couverture (si je connecte toute la façade, et si le seul chemin dans le composant est via sa façade, alors je sais que j'ai connecté tout ce qui va dans le composant)
• Fonctionne bien avec Conway's Law: lors du débogage d'un système avec plusieurs composants, chacun développé par une équipe différente , l'une des questions récurrentes est, "Quel composant est en faute, et donc quelle équipe doit déboguer?"

Answer 2

Je ne dirais pas que "Obtenir des gâteaux du référentiel" convient mieux à INFO. C'est plus approprié pour DEBUG ou même TRACE. Habituellement, vous souhaitez utiliser INFO pour enregistrer des éléments fonctionnels, par ex. "Il n'y a plus de gâteaux pour l'utilisateur A". Les choses non fonctionnelles et le flux technique devraient être de moindre gravité IMHO. Je n'utiliserais pas FATAL pour les exceptions de journalisation, sauf si vous arrivez au point où l'application est complètement morte. Il serait assez déroutant de voir FATAL et le système est toujours en vie. ERROR est un meilleur choix, parfois même WARNING, dépend de la gravité de l'exception. En ce qui concerne les intercepteurs AOP, la dernière fois que j'ai vérifié - ces choses affectent grandement les performances. C'est un concept cool et sexy, mais qui n'était pas pratique dans mon cas, pas sûr qu'il ne soit pas plus que des démos et des exemples triviaux de livres et d'articles expliquant les avantages de l'AOP. Donc, je vérifie avant de m'en remettre complètement.

Answer 3

Nous sommes TDD donc nous ne faisons plus beaucoup de journalisation. Peut-être juste dans les gestionnaires d'exception de niveau supérieur et quelques endroits stratégiques.

Answer 4

La diagraphie et le traçage devraient être des préoccupations transversales. Vous pouvez les ajouter/les supprimer à tout moment de manière déclarative si vous utilisez une programmation orientée aspect.