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. #1
    Expert éminent sénior

    Homme Profil pro
    Développeur informatique
    Inscrit en
    septembre 2014
    Messages
    194
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Algérie

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : Enseignement

    Informations forums :
    Inscription : septembre 2014
    Messages : 194
    Points : 12 283
    Points
    12 283
    Par défaut Quelle est l’importance de la journalisation dans le débogage ?
    Quelle est l’importance de la journalisation dans le débogage ?
    Selon un sénior, « un bon programmeur ajoute beaucoup de logs à son programme »

    Dans un billet de blog, Henrik Warne -blogueur et développeur multiplateformes- nous explique son point de vue sur l’importance des fichiers journaux dans le débogage.

    « Une des différences entre un bon programmeur et un mauvais programmeur est que le bon programmeur ajoute des logs et des outils qui facilitent le débogage du programme en cas d’erreur », déclare Henrik Warne. « Lorsque le programme fonctionne comme prévu, il n'y a souvent pas de différence dans la qualité des logs. Cependant, dès que le programme échoue, ou dès qu’on obtient un résultat erroné, on peut distinguer immédiatement les bons programmeurs des mauvais ».

    Selon lui, il y aurait trois grandes raisons qui pousseraient de nombreux programmeurs à ne pas écrire un « code déboggable ». Premièrement, ils ne sont pas « assez humbles » pour réaliser qu’il y aura toujours des cas où leur code ne fonctionnera pas comme prévu. Deuxièmement, ils ne testent pas leur code « à fond » ; en effet, lorsqu’on teste notre code on s’assure qu’il fonctionne dans un grand nombre de scénarios différents, or « si vous ne testez pas tous les cas, vous êtes moins susceptible d'ajouter des fichiers journaux ». Troisièmement, ils ne dépannent pas assez souvent leur « propre code dans les systèmes de production » ; en effet, lorsqu’on rencontre un problème dans notre système et que les fichiers journaux ne nous aident pas à connaître la cause de la panne : nous serons incités à ajouter des logs pour nous aider à trouver rapidement le problème lors d’une situation similaire.

    Henrik Warne donne aussi un exemple concret d’une mauvaise habitude de débogage : « Un testeur était venu [un jour] me voir avec un cas d'appel qui n'a pas fonctionné. Nous avons regardé les fichiers journaux et vus que le problème venait d’un module voisin : un appel à l'autre module pour obtenir une liste des valeurs nous a retourné un "null". Lorsque nous avons activé les logs dans le module voisin et refait le cas de test, il n'y avait pas plus d'informations disponibles, on n’avait aucun indice sur la raison pour laquelle le "null" à été renvoyé ». La solution proposée par le développeur du code était de créer « une version de débogage pour voir ce qui se passait », chose qui aurait pu « être évitée si une journalisation détaillée avait été établie ».

    Comme conclusion, l’auteur du blog affirme qu’il y a naturellement des cas où même les bons messages de journalisation ne nous permettent pas de savoir pourquoi quelque chose a échoué. « Vous pouvez toujours avoir à faire une version de débogage, mais une journalisation régulière devrait quand même vous donner des indications sur la nature du problème ».

    Source : Henrik Warne Blog

    Et vous ?

    Êtes-vous d’accord avec l’avis de Henrik Warne ?
    À part la journalisation, quelles autres habitudes pourraient aider les développeurs lors du débogage ?

  2. #2
    MikeRowSoft
    Invité(e)
    Par défaut
    Il n'a rien pris au sérieux. Sinon il serait passé de 1 à 8 niveau distinct de débogage au minimum.

  3. #3
    Membre confirmé

    Homme Profil pro
    Développeur Java
    Inscrit en
    février 2007
    Messages
    179
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 33
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Développeur Java
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : février 2007
    Messages : 179
    Points : 649
    Points
    649
    Par défaut Et avec la programmation par aspect ?
    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.
    L'expérience est une lanterne que l'on porte sur le dos et qui n'eclaire jamais que le chemin parcouru.

    La nature fait les choses sans se presser, et pourtant tout est accompli.

  4. #4
    Membre expérimenté Avatar de dfiad77pro
    Homme Profil pro
    (Ingénieur dev.) lead technique
    Inscrit en
    décembre 2008
    Messages
    521
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 33
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : (Ingénieur dev.) lead technique
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : décembre 2008
    Messages : 521
    Points : 1 646
    Points
    1 646
    Par défaut
    C'est assez différent dans la réalité,
    Dans un développement d'entreprise ou de multiples mains passent sur un code, sans revues de code , on trouve souvent ce genre de chose :

    Code C# : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    try{
     
    // 200 lignes de code
     
    }catch(Exception e){
     
    //Rien
     
    }

    Donc une floppée de log qui ralentissent l'application ( log4J / Log.NET, etc...) n'est souvent utile que pour les appels aux services, requêtes ,etc.

    De plus, pour le cas des module très complexes et liés ( moteur de calcul , etc) , il vaut mieux spécifier des logs compréhensifs ( en plus des automatiques) et faire des vrais tests unitaires mettant en oeuvre les règles de gestion métiers.

  5. #5
    Membre éclairé Avatar de Julien Bodin
    Homme Profil pro
    Devops
    Inscrit en
    février 2009
    Messages
    473
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 35
    Localisation : France, Calvados (Basse Normandie)

    Informations professionnelles :
    Activité : Devops
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : février 2009
    Messages : 473
    Points : 831
    Points
    831
    Par défaut
    Il faut bien prendre conscience du fait qu'ajouter des logs permettra probablement de gagner du temps plus tard. C'est un peu lourd quand on code mais c'est vrai que c'est très important. L'AOP aide beaucoup mais on monte d'un cran en complexité. C'est un sujet qui, idéalement, devrait être pensé dès la conception.

    Attention cependant à ne pas pénaliser les performances de l'application, il faut vraiment étudier l'ensemble des fonctionnalités proposées par son framework de logging et respecter les bonnes pratiques.

  6. #6
    Membre habitué

    Homme Profil pro
    Développeur Java
    Inscrit en
    avril 2012
    Messages
    14
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Développeur Java
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : avril 2012
    Messages : 14
    Points : 131
    Points
    131
    Par défaut
    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.
    Je ne suis pas d'accord. Les logs ne sont pas là que pour déboguer un programme. Pour moi, pour une exécution sans problème, la log doit pouvoir être lue et comprise par n'importe qui ayant une connaissance du fonctionnel.

  7. #7
    Inactif  
    Profil pro
    Inscrit en
    août 2008
    Messages
    238
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : août 2008
    Messages : 238
    Points : 622
    Points
    622
    Par défaut
    Je trouve cet article bien peu réfléchi et manquant de recul sur le sujet. Tout court.

  8. #8
    Expert confirmé
    Avatar de TiranusKBX
    Homme Profil pro
    Développeur C, C++, C#, Python, PHP, HTML, JS, Laravel, Vue.js
    Inscrit en
    avril 2013
    Messages
    1 476
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 32
    Localisation : France, Seine et Marne (Île de France)

    Informations professionnelles :
    Activité : Développeur C, C++, C#, Python, PHP, HTML, JS, Laravel, Vue.js
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : avril 2013
    Messages : 1 476
    Points : 4 746
    Points
    4 746
    Billets dans le blog
    6
    Par défaut
    Les log d'erreurs ne sont pas utile pour tous les programmes
    pour les programmes serveur oui vus que l'on n'à pas d'interface d'affichage mais pour les programmes avec interface graphique tu affiche les erreurs !
    Rien, je n'ai plus rien de pertinent à ajouter

  9. #9
    Expert éminent
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    août 2007
    Messages
    2 158
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : août 2007
    Messages : 2 158
    Points : 7 878
    Points
    7 878
    Par défaut
    Citation Envoyé par TiranusKBX Voir le message
    Les log d'erreurs ne sont pas utile pour tous les programmes
    pour les programmes serveur oui vus que l'on n'à pas d'interface d'affichage mais pour les programmes avec interface graphique tu affiche les erreurs !
    Pourquoi choisir ??
    Tu fais les 2 et chaque log n'a pas la même utilité.
    Les erreurs affichées sur l'interface sont destinées aux utilisateurs : ils sont orientés fonctionnel.
    Les logs écrits dans les journaux sont techniques et sont destinés à la TMA pour analyse et statistique.

  10. #10
    Membre averti
    Profil pro
    Inscrit en
    octobre 2010
    Messages
    183
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : octobre 2010
    Messages : 183
    Points : 407
    Points
    407
    Par défaut
    Citation Envoyé par TiranusKBX Voir le message
    Les log d'erreurs ne sont pas utile pour tous les programmes
    pour les programmes serveur oui vus que l'on n'à pas d'interface d'affichage mais pour les programmes avec interface graphique tu affiche les erreurs !
    +1 à Saverok: l'utilisateur final n'en à rien à carrer que ton appel d'api à foirer ou de ton buffer overflow, tu lui affiche qu'une erreur est survenue et tu écris dans le log le trace. Les logs servent avant tout pour des applis en production dans le but d'analyser des situations qui n'ont pas été couvertes par les tests ou simplement pour le support technique.

  11. #11
    Membre expérimenté Avatar de dfiad77pro
    Homme Profil pro
    (Ingénieur dev.) lead technique
    Inscrit en
    décembre 2008
    Messages
    521
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 33
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : (Ingénieur dev.) lead technique
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : décembre 2008
    Messages : 521
    Points : 1 646
    Points
    1 646
    Par défaut
    Citation Envoyé par Saverok Voir le message
    Pourquoi choisir ??
    Tu fais les 2 et chaque log n'a pas la même utilité.
    Les erreurs affichées sur l'interface sont destinées aux utilisateurs : ils sont orientés fonctionnel.
    Les logs écrits dans les journaux sont techniques et sont destinés à la TMA pour analyse et statistique.
    En parti d'accord avec une petite nuance

    Cela est valable pour les exceptions contrôlées et correctement prise en charge ( message fonctionnel personnalisé).

    Si un plantage se produit l'utilisateur doit être informé et l'erreur généraliste logué .

    Dans le cadre d'un client lourd autonome on ne peut pas toujours tout loguer à distance ou sur le journal d'événement ( dans le cas de Windows).

    Sur un plantage technique, si tu lui affiche que " Erreur technique" sans bouton détail ,
    lorsque l'utilisateur ouvrira un ticket (il ne se souvient pas forcément de l'heure exacte de son plantage), il faut impérativement sur que le support puisse aller chercher rapidement les logs.
    De plus si le plantage n'est pas reproductible, c'est pas évident.

  12. #12
    Rédacteur/Modérateur
    Avatar de Logan Mauzaize
    Homme Profil pro
    Architecte technique
    Inscrit en
    août 2005
    Messages
    2 894
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 36
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Architecte technique
    Secteur : Transports

    Informations forums :
    Inscription : août 2005
    Messages : 2 894
    Points : 7 195
    Points
    7 195
    Par défaut
    Citation Envoyé par Amine Horseman Voir le message
    Êtes-vous d’accord avec l’avis de Henrik Warne ?
    Surtout pas à ce sujet :
    Citation Envoyé par Henrik Warne
    Lorsque le programme fonctionne comme prévu, il n'y a souvent pas de différence dans la qualité des logs.
    La qualité du log est justement indépendante du bon fonctionnement de l'application. Et d'ailleurs, je pense que le billet est basé sur cette idée biaisée que le log sert uniquement à comprendre un mauvais fonctionnement. Or les logs servent à la supervision de manière générale.
    Et le débogageanalyse d'incident n'est qu'une part de l'activité qui repose sur l'analyse des logs.

    Je vais prendre un cas très "con" mais qui illustre bien le problème. Imaginons des serveurs Web en grappe. Ce sont deux serveurs Web dupliqués avec répartition de charge. Le choix d'une telle architecture n'est pas la charge mais simplement la disponibilité. Donc si un seul serveur fonctionne, il n'y a pas d'incidence pour les utilisateurs et donc à priori pas d'incident. Sauf que l'absence de logs "normaux" sur l'un des serveurs indiquent bien un problème. Mais c'est peut-être simplement l'infrastructure de la grappe qui est en cause (répartiteur, relance automatique, etc.). Sans des logs d'information "basique", impossible de savoir ce qui se passe.

    On peut même étendre le raisonnement à un composant (ex: service) particulier de l'application. Si je n'ai pas de logs de fonctionnement normal d'un service, c'est peut-être que j'ai oublié de configurer le démarrage du composant.

    Enfin un exemple "contraire", celle où l'application ne semble pas fonctionner mais fonctionne pourtant. Imaginons les logs suivants :
    22/12/2011 13:57:01 INFO [00001] Connexion de l'utilisateur DUPONT
    22/12/2011 13:57:01 INFO [00002] Connexion de l'utilisateur DUFFOUR
    22/12/2011 13:57:01 INFO [00001] Ouverture du document titi.txt
    22/12/2011 13:57:01 INFO [00002] Ouverture du document titi.txt
    22/12/2011 13:57:01 INFO [00002] Echec de la pause du verrou.
    Il suffit de recouper les informations d'une même transaction "[XXXXXX]" pour comprendre que DUFFOUR a essayé d'ouvrir le fichier titi.txt mais qu'il n'a pas pu obtenir le verrou.
    Pour avoir ce niveau de log, c'est bien au-délà de la gestion des erreurs. Le problème c'est que cela ne s'arrête pas à la gestion des logs mais également à la gestion des retours à l'utilisateur. Que préférez-vous parmis les retours possible pour l'utilisateur :
    1. Le logiciel a rencontré une erreur fatale
    2. Le logiciel n'a pas pu ouvrir le document
    3. Le document est verrouillé
    4. Le document est vérrouillé par un autre utilisateur
    5. Le document est verrouillé par DUPONT



    Ce point aussi me gêne un peu :
    Citation Envoyé par Henrik Warne
    un bon programmeur ajoute beaucoup de logs à son programme
    Autant il est utile d'ajouter des traces précises autant il faut éviter d'en balancer de trop. Au risque de saturer les espaces de stockage (ou voir de perdre de l'information à cause de système de débordement/roulement), de rallonger les temps de traitement (manuel ou automatique), voir même d'exposer des informations sensibles.

    Pour le reste, comme d'habitude ce sont surtout des redîtes de bonnes pratiques qu'il est toujours facile de vendre dans la théorie mais la réalité est un peu différente. Je veux pas dire que c'est impossible en pratique, juste que parmi les milliers de petits détails qui tournent autour du code (documentation, test, couverture, qualimétrie, etc.) on finit nécessairement par négligé un paramètre et parfois ce sont les logs car il n'y a pas de piqûre de rappel (ex: Sonar).


    Citation Envoyé par Amine Horseman Voir le message
    À part la journalisation, quelles autres habitudes pourraient aider les développeurs lors du débogage ?
    Sans quitter le domaine de la journalisation, je trouve dommage qu'un billet traitant de ce sujet n'aborde même pas la notion de distinction entre les traces fonctionnelles et les traces techniques. Idem pour les notions de traçabilité, c'est-à-dire attribuer des identifiants (UUID) aux acteurs (utilisateurs, systèmes externes), aux erreurs (numéro que l'on remonte à l'utilisateur pour le suivi de l'anomalie), aux transactions (idem que précédemment), etc.

    De manière plus générale, je pense à ce qui tourne autour de la robustesse. Je ne parles pas uniquement de la capacité d'un logiciel à résister aux erreurs mais aussi de sa capacité à fournir des informations détaillées, utiles et pertinentes ! Que ce soit pour le développeur mais également pour toutes les "parties prenantes" (utilisateur, AMO, équipe système, etc.). Car le maximum d'information on peut collecter et meilleure (rapidité, solutions proposées) sera l'analyse.


    Sinon je voudrais revenir sur ce sujet :
    Citation Envoyé par Amine Horseman Voir le message
    Deuxièmement, ils ne testent pas leur code « à fond » ; en effet, lorsqu’on teste notre code on s’assure qu’il fonctionne dans un grand nombre de scénarios différents, or « si vous ne testez pas tous les cas, vous êtes moins susceptible d'ajouter des fichiers journaux ».
    Viens alors le problème de tester les logs ! S'ils prennent une place importante, ils sont donc des "output" à vérifier lors de l'exécution du morceau de code.
    Java : Cours et tutoriels - FAQ - Java SE 8 API - Programmation concurrente
    Ceylon : Installation - Concepts de base - Typage - Appels et arguments

    ECM = Exemple(reproduit le problème) Complet (code compilable) Minimal (ne postez pas votre application !)
    Une solution vous convient ? N'oubliez pas le tag
    Signature par pitipoisson

  13. #13
    Futur Membre du Club
    Profil pro
    Inscrit en
    février 2013
    Messages
    16
    Détails du profil
    Informations personnelles :
    Localisation : Suisse

    Informations forums :
    Inscription : février 2013
    Messages : 16
    Points : 5
    Points
    5
    Par défaut
    Pas tout a fait d'accord...
    Si le développeur est seul a travailler sur son code, que le programme n'est pas trop complexe, qu'il est correctement architecturé (architecture MVC, méthodes courtes, etc...) je pense qu'il n'est pas forcément nécessaire de journaliser les appels. Personnellement, je n'en ai jamais eu besoin pour debogguer mon code. Après, si quelqu'un passe après moi et qu'il y a un bug, il mettra certainement plus de temps à trouver la source de ce dernier. Mais dans mon cas (autodidacte solitaire, développeur de mon propre CMS) ce n'est absolument pas utile. Quand je sais qu'un scenario pourrait m'échapper, de simples "Try/Catch" me suffisent amplement.

    Mais comme je l'ai dit, quand on est plusieurs a taffer sur le code, alors il vaut mieux journaliser.

  14. #14
    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
    Les logs c'est comme les commentaires:
    • Un code bien ecrit va tester les input et renvoyer des exceptions si incorrects pour l'exemple cite
    • Comme les commentaires, les textes ne sont pas maintenus
    • Comme les commentaires, les logs sont plus ou moins ecris par developpeurs
    • Comme les commentaires, cela poulle la lecture du code
    • Comme les commentaires on va mettres des logs pour expliquer du code mal ecrit




    Les seuls logs utiles sont:
    • Pour les execptions pour avoir une trace a exploiter en prod/devs a envoyer par mail pour les client lourd
    • Pour l'audit de perfomances par exmples
    • Pour remplir du disque dur


    Bref, clean code a tout dit il sufffisait de remplacer commentaire par log

    Le seul probleme on bosse tous en ssii, ou en equipes a la bourre, donc on fait du taff de merde (moi compris ofc), on controle pas les entree/sorties donc on mets des logs a l'arrache avec de preference un bon gros objet dto de 40 proprietes.

  15. #15
    Membre expert Avatar de air-dex
    Homme Profil pro
    Inscrit en
    août 2010
    Messages
    1 621
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 33
    Localisation : France

    Informations forums :
    Inscription : août 2010
    Messages : 1 621
    Points : 3 644
    Points
    3 644
    Par défaut
    Un bon debug va de pair avec une bonne pose des marques de debug, breakpoints ou logs (du printf à l'arrache en dev local au journal de logs). Donc des logs bien placés dans l'application facilitent forcément et grandement le débogage. Après il faut aussi faire attention au niveau de détails. Avoir des logs pour tout et n'importe quoi devient rapidement contre-productif. On passe son temps à chercher l'information importante parmi une palanquée d'informations toutes plus inutiles les unes que les autres.
    "Ils ne savaient pas que c'était impossible alors ils l'ont fait." Mark Twain

    Mon client Twitter Qt cross-platform Windows et Linux. (en cours de développement).

  16. #16
    Rédacteur/Modérateur
    Avatar de Logan Mauzaize
    Homme Profil pro
    Architecte technique
    Inscrit en
    août 2005
    Messages
    2 894
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 36
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Architecte technique
    Secteur : Transports

    Informations forums :
    Inscription : août 2005
    Messages : 2 894
    Points : 7 195
    Points
    7 195
    Par défaut
    Citation Envoyé par mermich Voir le message
    Le seul probleme on bosse tous en ssii, ou en equipes a la bourre, donc on fait du taff de merde (moi compris ofc), on controle pas les entree/sorties donc on mets des logs a l'arrache avec de preference un bon gros objet dto de 40 proprietes.
    C'est pour ca que le maximum de logs doivent être pensés en amont et être détaillé dans une spécification technique (ex: dossier de conception) ET fonctionnelle. Chaque type doit pouvoir être clairement distingué (ex: tables distinctes ou colonne de marquage) et il ne doit pas y avoir plus que marquer dans les spécifications.
    Libre ensuite de rajouter d'autres types ou d'autres sources pour stocker des traces complémentaires ajoutés par les dev (ex: fichiers de log)

    Rien n'empêche de faire redescendre les logs fonctionnels dans les logs techniques puis dans les traces pour avoir une source qui contient tous les "types".
    Java : Cours et tutoriels - FAQ - Java SE 8 API - Programmation concurrente
    Ceylon : Installation - Concepts de base - Typage - Appels et arguments

    ECM = Exemple(reproduit le problème) Complet (code compilable) Minimal (ne postez pas votre application !)
    Une solution vous convient ? N'oubliez pas le tag
    Signature par pitipoisson

  17. #17
    Rédacteur/Modérateur


    Homme Profil pro
    Network game programmer
    Inscrit en
    juin 2010
    Messages
    6 790
    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 790
    Points : 31 092
    Points
    31 092
    Billets dans le blog
    4
    Par défaut
    Dès que t'utilises une API externe, logger les codes retours erronés est vraiment un minimum à faire.
    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.

  18. #18
    Membre du Club

    Profil pro
    Java/Jee
    Inscrit en
    juillet 2008
    Messages
    25
    Détails du profil
    Informations personnelles :
    Localisation : Canada

    Informations professionnelles :
    Activité : Java/Jee

    Informations forums :
    Inscription : juillet 2008
    Messages : 25
    Points : 61
    Points
    61
    Billets dans le blog
    1
    Par défaut
    C'est essentiel de journaliser les différents traitements du code pour pouvoir analyser ce qui se passe sur la plateforme de production.
    Voir le cheminement d'un traitement permet de comprendre ce qui se passe.

    Il faut bien sûr faire attention aux performances mais maintenant, il existe beaucoup de framework de journalisation qui limitent leur impact sur l'éxecution du code.

  19. #19
    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
    ouais franchement :

    C'est essentiel de journaliser les différents traitements du code pour pouvoir analyser ce qui se passe sur la plateforme de production.
    Quand t'as une appli web avec plus de 100 utilisateurs simultanes, lire les logs va etre un veritable plaisir.

    Voir le cheminement d'un traitement permet de comprendre ce qui se passe.
    Sur une quinzaine de niveaux avec differents threads c'est lisible.

    Dès que t'utilises une API externe, logger les codes retours erronés est vraiment un minimum à faire.
    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).

    C'est pour ca que le maximum de logs doivent être pensés en amont et être détaillé dans une spécification technique (ex: dossier de conception) ET fonctionnelle. Chaque type doit pouvoir être clairement distingué (ex: tables distinctes ou colonne de marquage) et il ne doit pas y avoir plus que marquer dans les spécifications.
    Libre ensuite de rajouter d'autres types ou d'autres sources pour stocker des traces complémentaires ajoutés par les dev (ex: fichiers de log)

    Rien n'empêche de faire redescendre les logs fonctionnels dans les logs techniques puis dans les traces pour avoir une source qui contient tous les "types".
    Du coup avec cela le taff du dev est triple: mettre des commentaires et les maintenir, mettre des logs avec du vrai texte et les maintenir/ et faire son taff(tester les entree sorties) et le maintenir. Au final les applis ressemblent a des soupes de commentaires + logs pour ne garder que peu de lignes utiles A force de parcourirdu code mal ecrit j'ai developpe une competence qui me permet de ne jamais 'voir' voir les commentaires/logs ecris dans un code car trop souvent pas maintenus ou juste faux.

    Comme je le dis aux autres developpeurs : Contrairements aux commentaires/logs le code ne ments pas.

    Le plus drole c'est lorsque le developpeur joue avec les niveau de log, ca devient ridicule :on logge l'entree en debug et la sortie en info et paf surprise on ne voit plus les logs de sorties.

  20. #20
    Membre confirmé

    Homme Profil pro
    Consultant en architecture
    Inscrit en
    décembre 2013
    Messages
    82
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Consultant en architecture
    Secteur : Conseil

    Informations forums :
    Inscription : décembre 2013
    Messages : 82
    Points : 558
    Points
    558
    Billets dans le blog
    1
    Par défaut
    L'auteur marque un point : il est vrai qu'on a rapidement tendance a oublier la problématique des logs, tout simplement car cela sera surtout utile aux équipes de production (plus qu'aux devs), et que le client ne le verra absolument pas.

    En revanche, les logs ne servent pas qu'à investiguer en cas d'incident comme on peut le penser en lisant l'article, mais à une valeur aussi en fonctionnement normal. Outre l'intérêt fonctionnel déjà évoqué, même en fonctionnement normal les logs ont un intérêt technique pour les équipes de prod.

    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)... J'ai peut-être aussi envie d'utiliser mes logs si jamais un utilisateur externe essaie de faire n'importe quoi, même si il n'a rien cassé (sécurité). Je m'éloigne de mon domaine mais il semblerait que l'analyse de logs soit utilisés pour améliorer le référencement d'un site web.
    Bref, les logs font partie de l'application, et pas uniquement pour les erreurs ou le deboggage.

    En recherchant un peu les bonnes pratiques, je suis tombé sur cet article, que je vous conseille. Il ne dit pas quoi logger, mais comment créer de bons logs, je pense que c'est aussi utile.
    http://www.javacodegeeks.com/2011/01...n-logging.html

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