Utilité des bibliothèques de logging

[Bktero]

Devant un tel excès de mauvaise fois et devant la stérilité de notre discussion, je me demande si c'est encore la peine de répondre. Tu ne changeras pas d'avis ne serait-ce que d'un iota donc je ne vois pas vraiment l'utilité de continuer à "débattre" de ce sujet.

[souviron34]

Envoyé par Melem

Mon métier est tout simplement celui du développeur logiciel. Je n'ai jamais lu ce qu'il y a dans les logs que je génère au boulot, car je n'en ai rien à f**tre.

Donc ça ne te sert pas de debug

Envoyé par Melem

Je me contente juste de les générer à la demande de notre admin sys, qui dit qu'il en a besoin.

OK. cela veut dire que ton admin sys a eu le pouvoir d'influer sur la fonctionalité du logiciel.

N'en tire simplement pas une conclusion que cela est normal et devrait se passer partout..

Envoyé par Bktero

Devant un tel excès de mauvaise fois et devant la stérilité de notre discussion, je me demande si c'est encore la peine de répondre. Tu ne changeras pas d'avis ne serait-ce que d'un iota donc je ne vois pas vraiment l'utilité de continuer à "débattre" de ce sujet.

Si c'est à moi que c'est adressé (ce qui n'est pas clair ), je ne fais pas preuve de mauvaise foi du tout..

Il est simplement impensable dans un projet sérieux que un logiciel ne soit pas testé sur une config équivalente à celle du client, surtout si elle est plus faible que celle du dev.. Enfin, c'est mon point de vue de ce que doit être un logiciel professionnel. Et si on ne peut pas tester parce qu'on ne connaît pas, alors on indique les limites d'utilisations (vous savez, les petits trucs "xxx Mo de RAM.." qu'on lit sur les notices)

Les arguments que tu donnes par rapport à la machine cible et aux bugs révélés ou non sont donc caduques dans un projet sérieux..

Maintenant, en ce qui concerne les bugs "random", franchement déjà il faut cerner l'endroit, et en ça éventuellement des logs peuvent être utiles, mais la simplicité de maintenance fait que soit un flag général de lancement (pour éviter que cela ne pénalise le runtime normal) suivi d'une fonction comme celle indiquée plus haut (un bête printf dans un fichier) suffit. Et d'autre part cela ne fait que CERNER...

[Melem]

Envoyé par souviron34

Si c'est à moi que c'est adressé (ce qui n'est pas clair ), je ne fais pas preuve de mauvaise foi du tout..

Si quand même, si. J'ai plusieurs fois répété que les logs étaient un outil des admin sys et non des développeurs, mais tu fais exprès de ne pas entendre et de tout mélanger.

- Quand dans ta boîte des gens ont besoin de logs, tu logges.

- Quand dans ta boîte personne n'a besoin de logs, tu ne logges pas.

C'est aussi simple que cela, mais tu préfères te borner à ta vision du monde où personne n'a besoin de logs.

Pour ce qui est de log maison vs lib standard de log, c'est une fois de pus très simple : Les logs sont pour qui ?

- Pour toi-même ? Utilise ce que tu veux.

- Pour d'autres personnes, des professionnels du logs, etc. ? Utilise une lib standard.

Pourquoi vouloir à tou prix imposer ton propre style ?

[souviron34]

Envoyé par Melem

Si quand même, si. J'ai plusieurs fois répété que les logs étaient un outil des admin sys et non des développeurs, mais tu fais exprès de ne pas entendre et de tout mélanger.
...
- Pour d'autres personnes, des professionnels du logs, etc. ? Utilise une lib standard.

Pourquoi vouloir à tou prix imposer ton propre style ?

Je ne dis que 2 points :

• a priori (mais dans ton cas ce n'est peut-être pas vrai) un admin sys n'est pas un utilisateur : le logiciel n'est pas développé pour satisfaire ses besoins. On en revient au Cahier des Charges : si cela fait partie du CdC, alors OK. Sinon, on n'a pas à modifier le CdC.. Il y a des outils systèmes pour ça.
  
  
• les problèmes de manitenance / pérennité / lourdeur / dépendances

Prenons un exemple : dans l'aviation, il y a des "boîtes noires" qui enregistrent toutes les conversations et une (grande) partie des évènements qui se passent. Cela correspond à ta biblothèque de logs. PARCE QUE cela figure dans le CdC, que cela a été identifié comme un besoin PAR LES UTILISATEURS eux-même (les pilotes) pour comprendre, en cas de crash ou de malfonction, pourquoi cela s'est passé. L'EXPLOITATION de ces "boîtes noires" se passe AVEC des utlisateurs (pilotes) ET avec des techniciens.

Maintenant, prenons un logiciel de jeu. Pour un utilisateur, ce qui compte c'est la rapidiité de réaction du soft. Sa consommation de mémoire, son nombre d'accès disques, ou le nombre de Page Faults qui advient, il s'en contrefiche. Si il joue dans une salle de type "arcade", il est possible que le gestionnaire/administrateur de cette salle ait besoin de savoir ces informations. Il les obtiendra par des outils adaptés, SANS perturber le temps de réponse de l'utilisateur.

Ce cas est semblable à 99% des cas d'utilisation de logiciels.. C'est tout ce que je dis..


Et finalement, là où effectivement je reste sur ma position, parce que je l'ai (malheureusement) trop vu, c'est qu'une fois qu'on est pris avec un système lourd imbriqué dans un autre, alors que c'était une petite fonctionalité, on se traîne des casse-têtes ayant de lourdes implications en termes de délais et de coûts pour revenir en arrière, alors qu'un mininum au départ aurait évité tout ça.. SI c'est une petite fonctionalité... Et pour moi un log est une petite fonctionalité., qui ne vaut pas la peine d'alourdir un soft avec des dépendances étrangères..



NB: pour info, la discussion où j'avais référencée celle-ci est L’orientation vers plusieurs outils pour une application est-elle mauvaise ? , et vous pourrez constater que je ne suis pas le seul (de loin) à reprocher ce genre de comportements..

[bountykiler]

Plusieurs choses:
Il y a différents types de logs qui existent, avec chacun leur utilité.
On a par exemple les logs de "débug", qui servent à comprendre les erreurs qui surviennent. Typiquement, ceux-ci ne font pas parti du cahier des charges, mais on les génère quand même.
Ensuite on a les logs qui font parti du cahier des charges. Là, on a pas le choix, on doit les générer, avec un format qui respecte le cdc.

Je me contente juste de les générer à la demande de notre admin sys, qui dit qu'il en a besoin.

Comme dis Souviron, on peut donc cosidérer que ton sys admin influence le cdc. (Même si cela se fait de façon informelle).


Sinon pour ce qui est de l'utilité des librairies de log... désolé Souviron mais je te trouve pour le moins fermé.
Comme pour n'importe quelle lib, le fait d'utiliser ou non une lib existante ou non (et laquelle) est un choix (je serai tenté de rajouter technique ici).
Dans ton cas, tu considère que cela impose trop de contraintes/dépendances et que cela nuit à la maintenabilité du logiciel, et que le gain est trop faible. C'est ton droit (même si je pense que tu exagères un peu ces problèmes)

Perso, le fait j'utilise des lib externes dans différents projets.
Au niveau maintenabilité, je dirai que le cout est proche de 0. ça marche, et le seul cout est celui d'intégration de la lib, mais là encore, c'est simple.
Et cela me permet de ne pas avoir à coder moi même des trucs du style lecture du fichier de conf pour savoir quelles infos doivent être loggées et dans quel fichier. Car oui, on passe par un fichier de conf, essentiellement pour les logs de debug quand quelque chose plante en pré-prod (voir en prod, même si c'est peu heureusement peu fréquent.).
Après j'aurais très bien pu recoder cela moi-même. Seulement :
- cela m'aurai pris du temps de dev
- aucune valeur ajoutée
- risque de bug dans mon code, alors que celui des libs que j'utilise est (censé être) éprouvé.

Maintenant, une petite remarque quand même:
je suis perso assez insatisfait des libs que j'utilse pour logger en C++. La seule lib qui me donne entière satifaction au niveau fonction est log4cxx. Le problème est qu'elle implique trop de dépendances (telle que apr et apr-util par exemple), et que du coup je ne me vois pas l'utiliser dans tous mes projets.
Pour les autres lib C++ que j'ai utilisé, j'ai déjà eu des problèmes de portabilité (lib faite pour du UNIX qui ne marche pas à 100% sous windows), ou alors j'ai du moi-même modifier la lib en question pour des besoins fonctionnels.

Cela ne remet pas en cause le fait qu'avoir une librairie de log a en soi son utilté, simplement dans ce domaine je n'ai pas encore trouvé de lib qui me convienne et me satisfasse à 100% (si qqun en connait une bien, je suis preneur )