Se connecter ou ne pas se connecter?

Question

Je suis en train de construire un programme qui est un gestionnaire eBook, lecteur, organisateur et éditeur, qui est aussi un transfert eBook (à eReaders comme Kindle), mais je le développais et une question a surgi dans mon esprit: "Connectez-vous ou pas?"

Puis j'ai commencé à penser à la journalisation. Comme de nombreux programmes d'enregistrement des actions, j'ai commencé à chercher et voir comment ils se connectent les choses, alors je veux savoir:

• Il est bon de vous connecter des actions ou des choses qui happend dans les programmes (comme des erreurs)?
• Dans mon cas, c'est bon d'enregistrer des choses?
  • De quoi ai-je besoin pour me connecter? Quel est le meilleur moyen de consigner des choses (fichiers texte, bases de données ...)?
• Il existe un outil pour se connecter à Lazarus?

Answer 1

C'est essentiel. Log

1. toutes les erreurs avec des données connexes (args de méthode, etc.). Sinon, vous allez avoir une série de comportements liés aux bogues que vous ne pouvez pas analyser.
2. points d'entrée et de sortie principaux (quel est votre programme faire? Faut-il appeler ces méthodes à ce point?)
3. temps possibles méthodes/opérations consommation (entrée et sortie), de sorte que vous pouvez mesurer ce qui se passe et savoir ce que votre programme est en train de faire/où il est.
4. où vous chargez des configurations à partir de, le cas échéant. Cela signifie que vous pouvez dire comment votre programme se configure lui-même (quelle configuration utilise-t-il?)

Si vous avez raison, vous pouvez constater que vous passez de moins en moins de temps dans le débogueur. Je voudrais err sur la journalisation plus plutôt que peu, et enlever ou filtrer si/quand cela devient un problème (comme noté ci-dessous, logging Gbs par jour est probablement contre-productif). J'ai travaillé sur de nombreux systèmes où il a été décrété que la journalisation sera refusée ou supprimée après le développement, et cela ne se produira jamais, car c'est tellement utile. Certaines personnes s'opposent à la journalisation en raison de son impact sur les performances. Si tel est le cas, supprimez-le lorsque il est connu pour être un problème, pas avant.

Vous devriez être en mesure de trouver des cadres appropriés pour la journalisation (par exemple log4c pour C, log4j pour Java) pour votre plate-forme particulière qui permettent un filtrage et une sélection de destination appropriés. Cela signifie que vous pouvez vous connecter aux fichiers (et limiter la taille des journaux), les bases de données, les moniteurs distants, etc. et modifier cette décision à la volée (via un fichier de configuration ou des arguments de ligne de commande).Le cadre correct ne doit exiger que très peu de choses au départ, sauf l'insertion des instructions de journalisation appropriées. Vous ne devriez pas avoir à écrire beaucoup sur la gestion des fichiers ou d'autres codes de gestion de journaux.

Voici un useful blog entry sur ce sujet, avec d'autres directives.

Answer 2

Dans les premières phases du développement de composants, consignez tout. Habituellement, je fais tout mon développement sur la console de cette façon, je peux voir toute ma logique en sortie ligne par ligne si besoin est. Au fur et à mesure que vous avancez, les erreurs de journalisation sont toujours un must et les valeurs de consignation après une manipulation de données complexe peuvent également être utiles. Pensez aux désastres militaires dus aux arrondis flottants bientôt.

Je recommande de vous connecter à un fichier plat sur la base de données.

Answer 3

Consignez clairement les erreurs dans les fichiers plats formatés de façon cohérente afin de pouvoir les récupérer auprès de votre client et les lire dans Excel ou un db pour analyse si nécessaire.

Answer 4

La journalisation est essentielle et utile. Pourquoi? À des fins de traçage. Tant que vous développez sur une machine locale, vous pouvez rapidement déboguer, définir des points d'arrêt et déterminer où les choses tournent mal. Une fois que vous avez ensuite déployé en production votre client vous téléphonera, en disant qu'il n'a pas vu ce qu'il attendait (un message d'erreur est apparu quelque part). Croyez-moi, vous aurez du mal à comprendre ce qui s'est passé si vous n'avez pas de journaux.

Hmm ... La réponse de Brian vient à dire essentiellement sauté où je voulais continuer :)

Quoi qu'il en soit, vous pouvez envisager aussi des techniques Aspect Oriented. Ils sont plutôt adaptés à la consignation et vous gardez votre code propre. Peut être une option pour votre projet. En ce qui concerne le type de journalisation: Je travaille généralement très bien avec des fichiers texte (avec une certaine taille maximale), sauf si vous devez garder une trace de toutes les activités de votre utilisateur (raisons légales, peu importe). Dans ce cas, un journal DB serait probablement plus approprié.

Answer 5

La journalisation est toujours essentielle, car des erreurs peuvent survenir en production et des informations doivent être fournies sur ce qui s'est passé. En dehors des erreurs, cependant, que vous enregistriez les points d'entrée et de sortie des touches, les méthodes/opérations qui prennent du temps, etc. dépendent de l'application et de l'environnement. Si vous n'avez pas intégré l'analyse des performances dans votre système, vous devez soit vous connecter, soit être en mesure d'activer la journalisation détaillée, afin de détecter les problèmes de performances. De même, si vous n'avez pas d'outils de débogage en temps réel, vous devez vous connecter ou être en mesure d'activer la journalisation pour les points d'entrée/sortie de clé. Si le système gère des millions de transactions, chacune avec des millions d'opérations, alors vous ne voulez pas avoir ce niveau de journalisation tout le temps sur chaque sous-système/processus, sinon votre application remplit rapidement tout l'espace disque disponible - C'est un problème.

Pour les systèmes simples et de petite taille, il est probablement suffisant d'avoir un niveau de journalisation par défaut pour la production et un niveau de débogage pour la résolution des problèmes.

Answer 6

Ceci est une question très générale ... Pour commencer, je dirais que vous devriez avoir plusieurs niveaux de journalisation. Au niveau de la trace, consignez tout ce que vous avez en tête. Au niveau des erreurs, ne notez que les erreurs de type sever. Permet de choisir le niveau de journalisation à l'exécution, bien que la sélection ne soit pas disponible pour les utilisateurs finaux. Aussi, gardez à l'esprit que si vous mettez vos journaux à la disposition de personnes autres que vous (votre équipe de support, par exemple), assurez-vous que vos messages sont lisibles par l'homme et pas seulement quelque chose que vous pouvez comprendre.

Il existe de nombreuses infrastructures de journalisation, regardez autour de vous pour voir ce qui convient à votre environnement de développement. Il pourrait être plus facile d'utiliser une infrastructure bien testée que d'inventer quelque chose de votre propre.

Answer 7

• Il est bon de vous connecter des actions ou des choses qui happend dans les programmes (comme des erreurs)?

Oui, vous devez toujours avoir un moyen de trouver ce qui est erroné notre. Vous devez également les classer afin de pouvoir désactiver ultérieurement la consignation d'une certaine classe de messages de journal (par exemple, lorsque vous développez des messages de débogage, après avoir envoyé votre application, vous ne tenez compte que des erreurs et des avertissements).

• Dans mon cas, il est bon de se connecter les choses?

voir ci-dessus.

 o What I need to log? 

• Chaque erreur (app/fonction ne fonctionne pas)
• Avertissement Chaque (app/fonction fonctionne toujours, mais il est utile de garder un record de celui-ci)
• information (quelque chose agréable d'avoir)
• Debug (choses que seul un développeur se soucie)

Avec ever class, vous devez également enregistrer les données pertinentes.

• Quelle est la meilleure façon de connecter les choses (fichiers texte, bases de données ...)?

Je préfère les fichiers, car ils sont faciles à lire et peuvent être partagés facilement avec les autres. Mais tant que vous pouvez accéder aux journaux, le support est le plus petit problème.

Je recommande d'utiliser un cadre de journalisation, car la connexion est une partie essentielle de votre application et de nombreuses personnes ont déjà trouvé de très bonnes solutions. De cette façon, vous n'inventez pas la roue encore et encore et vous avez plus de temps pour développer votre application.

Answer 8

La journalisation pendant le développement n'a pas vraiment d'importance - faites-le si cela vous aide; arrête de le faire quand il arrête d'aider.

Les bonnes bûches deviennent importantes pendant la production. Dressez la liste des problèmes que vous rencontrerez et consignez les informations dont vous avez besoin pour résoudre ces problèmes. Serez-vous poursuivi pour violation de copyright? Ensuite, connectez-vous à ce dont vous avez besoin pour vous défendre. Les gens vont-ils signaler des bugs à leurs lecteurs et demander de l'aide? Enregistrez ensuite ce dont vous avez besoin pour répondre aux questions et réduire vos coûts d'assistance.

Il est facile de consigner trop d'informations (inutiles). Si vous n'en avez pas besoin, ne le connectez pas. Les serveurs vont-ils échouer? Les réseaux vont-ils échouer? Voulez-vous manquer de stockage? Oui, et vous pouvez vous connecter pour aider à diagnostiquer ces problèmes, mais c'est principalement un travail de surveillance, pas de journalisation.

Syslog offre une très bonne gestion et un contrôle centralisé. Il existe de nombreux cadres de journalisation qui fonctionnent à peu près de la même façon: c'est vraiment la préférence personnelle que vous utilisez. J'utilise un format de journal structuré et interrogeable sur le dessus de syslog.Tous les journaux de développement ad hoc sont supprimés avant leur mise en ligne.