Discussion :

[GeoffreyOnRails]

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

[mikrethor]

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.

[mermich]

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.

[Bousk]

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.

[sekaijin]

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