Io per il logging ho una regoletta molto semplice che dice: 1. logga tutto quello che il tuo servizio riceve come input, e quello che rispondiamo 2. quando vai a interrogare un servizio esterno, logga quello che gli abbiamo mandato e quello che ci ha risposto 3. logga tutte le eccezioni inaspettate, ma solo al livello piu' esterno del call stack 4. non loggare nient'altro
Magari ci possono essere occasionali eccezioni alla regola 4, e le regole 1 e 2 devono evitare di loggare dati sensibili, ma con questo sistema sei in grado di fare sia analisi dei guasti, sia di osservare che cosa fa il tuo sistema in generale. Domanda per Uberto: ma se tu passi il monitor che riceve gli eventi giu giu giu fino agli oggetti di dominio, non ti da fastidio aggiungere un parametro extra a tutti i costruttori? Od ho sbagliato io a capire? Il giorno ven 9 nov 2018 alle ore 08:50 Simone Bordet [email protected] [it-torino-java-jug] < [email protected]> ha scritto: > > > Ciao, > > > > On Thu, Nov 8, 2018 at 11:53 PM Uberto Barbini [email protected] > [it-torino-java-jug] <[email protected]> wrote: > > in questo modo i log entrano a far parte del dominio, specifiche e tutto > il resto. Inoltre non c'e' piu' il concetto di debug/info/warn/trace ecc. o > un evento e' significativo e lo notifichi oppure no. > > Ma secondo me il problema è definire "significativo". > Quello che è importante per qualcuno non lo è per qualcun altro.. > > Io sono sempre stato un fan del tagged logging: niente livelli > (debug/info/warn) ma solo tags. > A quel punto come dici tu il logging diventa una feature e cosa devi > loggare dal punto di vista del business lo chiedi al cliente, mentre > lo sviluppatore fa il logging degli internals dell'implementazione. > > Da Java 9 si è arrivati a questo per il logging interno della JVM, ma > niente da fare ancora per il logging applicativo e i vari SLF4J, > Log4J2 e LogBack che sono ancorati al modello di 20-30 anni fa. > > > > > Kirk Pepperdine mi ha fatto notare una volta come uno dovrebbe loggare > il meno possibile quando va tutto bene e il piu' possible quando succede > qualche cosa di sbagliato. > > Anche qui definire "sbagliato" è difficile. > > -- > Simone Bordet > --- > Finally, no matter how good the architecture and design are, > to deliver bug-free software with optimal performance and reliability, > the implementation technique must be flawless. Victoria Livschitz > >
