C'è qualche ragione per non includere i numeri di rilascio nei log di debug?

1

Stavo esaminando le risposte a questa domanda:

Quali informazioni non devono mai apparire nei log?

E ho notato che nessuno ha menzionato questo particolare attributo. È qualcosa che trovo utile: ogni volta che una registrazione viene aggiunta al sistema come risultato della traccia di un particolare problema sollevato nel bug tracker, o aggiungendo una funzionalità, tendo a includere il numero di ticket dell'helpdesk correlato elemento.

Ciò significa che quando si passa attraverso il log, qualsiasi programmatore può incrociare il riferimento a ciascun messaggio di registro con il numero di ticket associato. Ora capisco che utilizzando l'integrazione corretta VCS / helpdesk significa che la maggior parte dei commit sono comunque associati a un numero di ticket, ma con il tempo ci rende facile diagnosticare i problemi durante l'ispezione ogni volta che viene visualizzato un messaggio di registro.

Tuttavia mi rende ancora un po 'a disagio lasciare questo nei log. Il problema è che non riesco a pensare a uno scenario in cui questo potrebbe diventare un problema. Spero che SE possa aiutarmi.

A proposito- sto parlando del livello di log "verboso". Questo non viene mai fatto in un livello di registrazione che verrà visualizzato nella produzione.

    
posta clockpenalty 26.07.2013 - 10:50
fonte

1 risposta

5

I can't think of a scenario where this could become a problem

Nei miei progetti passati, ho passato 3 o 4 migrazioni di bug tracker che hanno modificato (invalidato) tutti gli ID dei bug utilizzati nel tracker precedente.

All'interno dei bugtracker stessi, questo non era un problema, dal momento che i riferimenti a problemi precedenti di precedenti tracker erano facili da scoprire. Ma posso facilmente immaginare che faccia un grosso mal di testa quando viene postato in un log di applicazioni di testo, specialmente quando ci saranno mix di "vecchi" e "nuovi" ID del tracker.

  • known issue, details in PRJ-12345
    si riferisce al vecchio tracker usato prima giugno 2012
  • known issue, details in PRJ-23451
    si riferisce al nuovo tracker usato dopo al 2012

Sarebbe abbastanza difficile capire quale dei (due) tracker sopra i messaggi si riferiscono a.

Trovo che sia meglio assicurarsi che i messaggi di log siano unici, ovvero garantire che lo sviluppatore sia in grado di rintracciare il messaggio al punto singolo nel codice sorgente (più su quello sotto).

In quel punto singolo riferito ai log, si possono usare commenti al lettore di punti per specificare l'URL del rispettivo problema quando necessario.

    // known issue, details in http://oldtracker/PRJ-12345
    // known issue, details in http://newtracker/PRJ-23451

Nota a margine, un "bell'esempio" di ciò che non va nel non avere messaggi di log univoci è un bug di Tomcat 27988 FileNotFoundException non utile . La sua descrizione sembra una strada regale per l'incubo della manutenzione ...

org.apache.naming.resources.DirContextURLConnection raises FileNotFoundException on lines 311, 344, 382 and 396. It would be more helpful if these provided a message string

... e nella mia esperienza, è stato davvero un incubo.

Indovina cosa succede quando la tua applicazione si blocca con braindead file not found e ci sono (almeno) quattro ragioni per questo e log non ti dà la minima idea di cosa potrebbe davvero andare storto lì.

La quantità di maledizioni che ho inviato agli sviluppatori Apache è difficile da contare.

    
risposta data 26.07.2013 - 11:28
fonte

Leggi altre domande sui tag