IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Débats sur le développement - Le Best Of Discussion :

Quelle est l’importance de la journalisation dans le débogage ?


Sujet :

Débats sur le développement - Le Best Of

  1. #21
    Membre expérimenté
    Homme Profil pro
    Développeur .NET
    Inscrit en
    février 2007
    Messages
    863
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 37
    Localisation : Canada

    Informations professionnelles :
    Activité : Développeur .NET

    Informations forums :
    Inscription : février 2007
    Messages : 863
    Points : 1 485
    Points
    1 485
    Par défaut
    Imaginons un système de batch, j'ai sûrement envie de savoir dans mes logs, le temps qu'à pris un gros batch, quelques infos sur les fichiers reçus (genre la taille et qui les envoie)...
    Dans ce cas ce n'est pas des logs mais de l'audit de perfmances, dans ce cas un fichier specialiser pour les performances peut etre utile ou carrement une table/base de donnees propre a l'audit qui peut etre requetee.

  2. #22
    Membre extrêmement actif Avatar de ddoumeche
    Homme Profil pro
    Ingénieur recherche et développement
    Inscrit en
    octobre 2007
    Messages
    1 440
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Singapour

    Informations professionnelles :
    Activité : Ingénieur recherche et développement

    Informations forums :
    Inscription : octobre 2007
    Messages : 1 440
    Points : 2 507
    Points
    2 507
    Par défaut
    Citation Envoyé par Angelsafrania Voir le message
    Les logs dont monsieur le seigneur (euh sénior) nous parle sont des logs au cours d'exécution de la méthode (notez que je vais parler que de programmation objet).
    Normalement une méthode n'a pas 50 milles trucs à faire, sinon on est dans un mauvais design (eq pas très bon développeur).
    Donc si notre méthode est suffisamment bien construite alors juste le log des appels de méthode suffit. Un des cas d'école de la programmation par aspect.

    Tout ça pour dire que si le code est bien construit aucun log ne devrait être écrit. Mais bon on est pas parfait et donc on doit en mettre quand même de temps en temps.
    Dans un monde parfait, on ferait de la programmation par contrat et les méthodes ne planteraient pas.
    La joie de l'âme est dans la planification -- Louis Hubert Liautey

  3. #23
    Membre éprouvé
    Avatar de EpiTouille
    Homme Profil pro
    Étudiant
    Inscrit en
    mai 2009
    Messages
    372
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Étudiant

    Informations forums :
    Inscription : mai 2009
    Messages : 372
    Points : 917
    Points
    917
    Par défaut
    Je signale juste une typo dans le titre de l'article (enfin dans le fils des actualités) :

    Nom : typo.png
Affichages : 195
Taille : 6,2 Ko

  4. #24
    Expert confirmé Avatar de DonQuiche
    Inscrit en
    septembre 2010
    Messages
    2 741
    Détails du profil
    Informations forums :
    Inscription : septembre 2010
    Messages : 2 741
    Points : 5 459
    Points
    5 459
    Par défaut
    Citation Envoyé par ddoumeche Voir le message
    Dans un monde parfait, on ferait de la programmation par contrat et les méthodes ne planteraient pas.
    Et les contrats représenteraient 90% du code, les coûts de développement seraient dix fois importants, la compilation durerait une minute, et les programmeurs débogueraient les contrats.


    Les contrats, comme les tests ou les spécifications, sont avant tout une autre façon, peu compacte et partielle mais intentionnelle et plus compréhensible, d'exprimer le programme. C'est avant tout la redondance de ces modes d'expression qui entraîne la fiabilité. Une bonne solution dans les domaines où l'on a besoin de garanties fortes mais une solution coûteuse et fastidieuse.

  5. #25
    Rédacteur/Modérateur


    Homme Profil pro
    Network game programmer
    Inscrit en
    juin 2010
    Messages
    6 736
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 34
    Localisation : Canada

    Informations professionnelles :
    Activité : Network game programmer

    Informations forums :
    Inscription : juin 2010
    Messages : 6 736
    Points : 30 703
    Points
    30 703
    Billets dans le blog
    4
    Par défaut
    Citation Envoyé par mermich Voir le message
    Cela ca t'avances a quoi de plus que verifier les entrees sorties et envoyer une exeption, de plus un api externe devrait toujours etre imbriquee dans un autre conteneur (cf clean code ou code complete pour plus de details et explications).
    Entre autre à savoir que le flow normal ne s'est pas déroulé à cause d'une erreur de leur côté et non du tien. Et ça n'a rien à voir avec la validité des entrées.
    Pensez à consulter la FAQ ou les cours et tutoriels de la section C++.
    Un peu de programmation réseau ?
    Aucune aide via MP ne sera dispensée. Merci d'utiliser les forums prévus à cet effet.

  6. #26
    Membre émérite
    Inscrit en
    janvier 2011
    Messages
    805
    Détails du profil
    Informations personnelles :
    Localisation : Autre

    Informations forums :
    Inscription : janvier 2011
    Messages : 805
    Points : 2 931
    Points
    2 931
    Par défaut
    Citation Envoyé par ddoumeche Voir le message
    Dans un monde parfait, on ferait de la programmation par contrat et les méthodes ne planteraient pas.
    Sauf celles qui font de l'I/O quand l'I/O est défaillant Et les erreurs de programmation genre récursion infinie.

    Mais je suis plutôt d'accord avec le billet de blog. Pour moi il y a deux grandes sortes de log : les logs d'erreur et les journaux applicatifs.

    Dans certains domaines, il est obligatoire (légalement ou par politique interne) de journaliser les actions les plus importantes qui surviennent. Des transactions sont mêmes mises en place pour assurer l'atomicité de (exécution de l'opération + logging). Si on ne peut pas logger, on ne fait pas l'action.

    J'aime bien les approches comme Event Sourcing, la partie journalisation est "gratuite" car la couche persistance stocke déjà une suite d'événements plutôt qu'un état en base de données. On a toute la frise chronologique du runtime, il n'y a plus qu'à exploiter les données.

    De manière générale, je pense aussi qu'il faut faire basculer un maximum de choses du monde des exceptions vers le monde des événements business normaux dans la vie d'une application. Les exceptions sont en général plus coûteuses en termes de performances, plus fragilisantes pour l'exécution et plus difficiles à exploiter correctement. Avec une bonne analyse métier, il est souvent facile de changer une exception (sur des accès concurrents par exemple) en un déroulement applicatif normal qui peut s'inspirer de ce qui se passe dans la vie réelle (file d'attente, retry, etc.) Ca se retrouve aussi dans les logs mais c'est moins disruptif.

  7. #27
    Expert éminent
    Avatar de sekaijin
    Homme Profil pro
    Urbaniste
    Inscrit en
    juillet 2004
    Messages
    4 176
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 57
    Localisation : France, Yvelines (Île de France)

    Informations professionnelles :
    Activité : Urbaniste
    Secteur : Santé

    Informations forums :
    Inscription : juillet 2004
    Messages : 4 176
    Points : 8 643
    Points
    8 643
    Par défaut
    Quand je lis que lorsque on a fait un bon design alors le log des appels de méthode suffit je me marre.

    nos amis de la Business Machine nous on pondu un tel truc
    effectivement super facile de localiser l'endroit où se produit l'erreur.

    J'avais (oui on à fini par les mettre à la porte et à développer sérieusement) tous le cheminement des appels successif jusqu'à l'erreur.
    Je pouvais donc savoir où mais comme je n'avais que ça impossible de savoir pourquoi.

    supposant que nous ayons disons 5 classes avec chacun 4 méthodes. et que pour toutes ces méthode nous aillons été très rigoureux et traçons chaque appel.
    tout cela est plutôt simple. mais voilà le système instancie des milliers d'exemplaire de ces classes assure des centaines de traitement en parallèle le tout pour traiter des millions de données différentes.
    du coup dans les logs les appels simultanés à ces quelque classes se retrouve dispersés.

    et voila comment sur une simple exécution d'une requête on sait qu'on a à la ligne 35 de la méthode toto de la classe Titi une erreur SQL "Table or View dose not exist"
    Mais on ne sais pas qu'elle table parmi les quelques dizaines de milliers qui sont présente dans les quelques centaine de bases, pas plus q'on ne sait quelle requête ni pour quelle donnée. ne riez pas c'est IBM qui a produit ça.

    Alors on a envie de mettre des log bien plus précis et on se retrouve avec des fichier de log qui font plus d'une rotation par minute. et comment ils sont encore une fois inexploitable.

    bref si les log permettaient à eux seul de faire du debug ça se saurait depuis longtemps.

    A+JY

Discussions similaires

  1. Quelle est la place d’un développeur dans le monde de la robotique ?
    Par Stéphane le calme dans le forum Robotique
    Réponses: 7
    Dernier message: 13/08/2016, 01h07
  2. Réponses: 3
    Dernier message: 10/07/2012, 11h48
  3. Réponses: 20
    Dernier message: 06/07/2009, 13h46
  4. Réponses: 1
    Dernier message: 09/06/2006, 12h04
  5. Réponses: 1
    Dernier message: 07/05/2005, 17h06

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo