Rapporto tra codice e registrazione? [chiuso]

Question

Qual è il rapporto ideale tra codice e registrazione? Non sono abituato a scrivere registri poiché la maggior parte delle applicazioni che ho sviluppato non ha registrato molto.

Di recente ho cambiato lavoro e ho notato che non è possibile visualizzare il codice dell'applicazione per le chiamate a log4net. Mi rendo conto che questo è utile ma sicuramente avere troppe dichiarazioni di debug è altrettanto male che non averne affatto?

Esistono istruzioni di registrazione che indicano quando ogni metodo inizia e finisce e cosa stanno restituendo. e quando praticamente si fa di tutto.

Non sarebbe più facile avere un componente aggiuntivo che utilizza la riflessione per aggiungere le istruzioni di registrazione in fase di compilazione in modo che non si mettano in mezzo mentre stavi cercando di guardare il codice?

Anche in questi giorni di potenti IDE e debug remoto questa registrazione è davvero necessaria?

Answer 1

In realtà esiste una bella libreria per aggiungere la registrazione dopo il fatto come dici tu, PostSharp . Ti consente di farlo tramite la programmazione basata sugli attributi, tra le molte altre cose molto utili oltre alla semplice registrazione.

Sono d'accordo che ciò che dici è un po 'eccessivo per la registrazione.

Alcuni altri sollevano alcuni punti positivi, in particolare lo scenario bancario e altre app mission-critical. Potrebbe essere necessario per la registrazione estrema, o almeno essere in grado di accenderlo e spegnerlo se necessario, o avere diversi livelli impostati.

Answer 2

Dato che log4net fa un ottimo lavoro nel non intasare le risorse, tendo ad essere un po 'prolisso nel logging perché quando devi passare alla modalità debug, più informazioni hai, meglio è. Ecco cosa in genere registro:

Livello DEBUG

• Qualsiasi parametro passato in Metodo
• Qualsiasi riga viene conteggiata dai set di risultati recuperati
• Qualsiasi datarows che può contenere dati sospetti quando viene passato al metodo
• Qualsiasi " generato " percorsi di file, stringhe di connessione o altri valori che potrebbero essere confusi quando "messi insieme" dall'ambiente.

Livello INFO

• L'inizio e la fine del metodo
• L'inizio e la fine di tutti gli anelli principali
• L'inizio di tutte le principali dichiarazioni case / switch

Livello ERRORE

• Eccezioni gestite
• Tentativi di accesso non validi (se la sicurezza è un problema)
• Dati errati che ho intercettato per la segnalazione

Livello FATAL

• Eccezioni non gestite.

Anche avere molti dettagli di registrazione mi impedisce di chiedere all'utente cosa stavano facendo quando hanno ricevuto il messaggio di errore. Posso facilmente metterlo insieme.

Answer 3

I file di registro completi sono incredibilmente utili. Prendi in considerazione una situazione in cui l'applicazione viene distribuita da qualche parte come una banca. Non puoi entrare e debug a mano e sicuramente non ti invieranno i loro dati. Quello che puoi ottenere è un registro completo che può indicare dove si è verificato il problema. Avere un numero di livelli di registro è molto utile. Normalmente l'applicazione verrebbe eseguita in modo tale da riportare solo errori fatali o errori gravi. Quando è necessario eseguirne il debug, un utente può attivare il debug o tracciare l'output e ottenere molte più informazioni.

Il tipo di registrazione che stai vedendo sembra eccessivo, ma non posso davvero dire che lo sia senza sapere di più sull'applicazione e su dove potrebbe essere distribuita.

Answer 4

  

Anche in questi giorni di potenti IDE e debug remoto questa registrazione è davvero necessaria?

Sì, assolutamente, anche se l'errore che molti sviluppatori non qualificati commettono è quello di provare a correggere i bug usando il metodo sbagliato, di solito tendendo alla registrazione quando dovrebbero essere il debug. C'è un posto per ciascuno, ma ci sono almeno alcune aree in cui la registrazione sarà quasi sempre necessaria:

• Per esaminare i problemi nel codice in tempo reale, in cui la sospensione con il debugger influirebbe sul risultato del calcolo (garantito, la registrazione avrà un leggero impatto sui tempi in un processo in tempo reale come questo, ma quanto dipende molto dal software)
• Per build inviate a beta tester o altri colleghi che potrebbero non avere accesso a un debugger
• Per scaricare dati su disco che potrebbero non essere facili da visualizzare all'interno di un debugger. Ad esempio, alcuni IDE che non sono in grado di analizzare correttamente le strutture STL.
• Per ottenere " sentire " del normale flusso del tuo programma
• Per rendere il codice più leggibile oltre a commentare, in questo modo:

// Now open the data file
fp = fopen("data.bin", "rb");

Il commento sopra potrebbe essere inserito altrettanto facilmente in una chiamata di registrazione:

const char *kDataFile = "data.bin";
log("Now opening the data file %s", kDataFile);
fp = fopen(kDataFile, "rb");

Detto questo, in qualche modo sei corretto. L'uso del meccanismo di registrazione come logger stack-trace glorificato genererà file di registro di qualità molto scadente, in quanto non fornisce un punto di errore abbastanza utile per lo sviluppatore da esaminare. Quindi la chiave qui è ovviamente l'uso corretto e prudente delle chiamate di accesso, che penso si riduca a discrezione dello sviluppatore. Devi considerare che stai essenzialmente creando i file di log per te stesso ; i tuoi utenti non si preoccupano di loro e di solito interpretano male i loro contenuti comunque, ma puoi usarli per determinare almeno perché il tuo programma si è comportato male.

Inoltre, è abbastanza raro che un file di registro indichi la fonte diretta di un determinato bug. Nella mia esperienza, di solito fornisce alcune informazioni su come è possibile replicare un bug e quindi, attraverso il processo di replica o debug, trovare la causa del problema.

Answer 5

Quanta registrazione non è necessaria. Non c'è motivo (in produzione) di sapere quando ogni metodo inizia e finisce. Forse ne hai bisogno su alcuni metodi, ma avere così tanto rumore nei file di registro li rende quasi impossibili da analizzare in modo efficace.

Dovresti accedere quando accadono cose importanti come errori, accessi utente (registro di controllo), transazioni avviate, dati importanti aggiornati ... ecc. Se hai un problema che non riesci a capire dai registri, puoi aggiungerne di più se necessario ... ma solo se necessario.

Inoltre, solo per tua informazione, l'aggiunta dell'accesso in fase di compilazione sarebbe un esempio di ciò che viene chiamato Programmazione orientata agli aspetti . La registrazione sarebbe la "preoccupazione trasversale".

Answer 6

Penso che " registri al rapporto del codice " è un fraintendimento del problema.

Nel mio lavoro di tanto in tanto ho una situazione in cui un bug in un programma Java non può essere riprodotto al di fuori dell'ambiente di produzione e in cui il cliente NON vuole che accada di nuovo.

Quindi TUTTO quello che hai a disposizione per correggere il bug, è l'informazione che tu stesso hai inserito nei file di registro. Nessuna sessione di debug (comunque vietata negli ambienti di produzione) - nessuna ricerca dei dati di input - niente!

Quindi i log sono la tua macchina del tempo indietro al momento in cui si è verificato il bug e poiché non puoi prevedere in anticipo quali informazioni ti serviranno per correggere un bug ancora sconosciuto - altrimenti potresti semplicemente correggere il bug in primo luogo - tu è necessario registrare un sacco di roba ...

ESATTAMENTE CHE COSA dipende dallo scenario, ma in pratica abbastanza per assicurarti di non avere mai dubbi su cosa succede dove :)

Naturalmente questo significa che accadrà MOLTO di registrazione. Quindi creerai due registri: uno con tutto ciò che è tenuto in giro solo per il tempo sufficiente a garantire che non ne avrai bisogno, e l'altro con informazioni non banali che possono essere conservate per molto più tempo.

La chiusura eccessiva della registrazione viene generalmente eseguita da coloro che non hanno dovuto correggere un bug con nient'altro a cui rivolgersi :)

Answer 7

Quando ti imbatti in un bug durante la versione beta dell'applicazione e non riesci a riprodurlo, sai che avresti dovuto fare una registrazione eccessiva. Allo stesso modo se un client segnala un bug ma non è possibile riprodurlo, una funzione di registrazione eccessiva può salvare la situazione.

Answer 8

Quando hai uno scenario cliente (ad es. qualcuno a cui non hai accesso fisico alla macchina), le uniche cose che sono "troppo registrate" sono stanno ridipingendo le funzioni e quasi tutto ciò che viene chiamato da loro (che dovrebbe essere quasi nulla). O altre funzioni che vengono chiamate 100 volte al secondo durante il funzionamento (l'avvio del programma è ok, tuttavia, per avere centinaia di chiamate per ottenere / impostare le routine registrate perché, nella mia esperienza, è lì che hanno origine la maggior parte dei problemi).

Altrimenti, ti prenderai solo a calci quando manchi un punto di log chiave che ti direbbe definitivamente qual è il problema sul computer dell'utente.

(Nota: qui mi riferisco alla registrazione che si verifica quando la modalità di traccia è abilitata per i registri orientati agli sviluppatori, non per i registri delle normali operazioni orientati all'utente.)

Answer 9

Quante di queste linee registrano per impostazione predefinita? Ho lavorato su un sistema molto simile a quello che descrivi: il solo avvio di esso causerebbe la scrittura di oltre 20 MB di log se il log fosse avviato, ma anche per il debug non lo abbiamo attivato completamente per tutti i moduli . Per impostazione predefinita, registra quando viene inserito un modulo di codice e eventi di sistema importanti. È stato ottimo per il debug poiché il QA poteva semplicemente allegare un registro a un ticket e anche se non era riproducibile, si poteva vedere cosa stava succedendo quando si è verificato il problema. Se hai in seria multithreading, la registrazione è ancora migliore di qualsiasi IDE o debugger con cui ho lavorato.

Answer 10

Trovo che la registrazione sia molto meno necessaria da quando ho iniziato a usare TDD. Rende molto più facile determinare dove si trovano i bug. Tuttavia, trovo che le istruzioni di registrazione possano aiutare a capire cosa sta succedendo nel codice. Certo, i debugger ti aiutano a dare un'idea di basso livello di ciò che sta accadendo. Ma trovo più facile quando posso abbinare una riga di output a una riga di codice se voglio avere una visione di alto livello di ciò che sta accadendo ..

Tuttavia, una cosa che dovrei aggiungere è questa: assicurati che le tue istruzioni di registro includano il modulo in cui si trova l'istruzione di registro! Non riesco a contare il numero di volte in cui ho dovuto tornare indietro e scoprire dove si trova effettivamente un'istruzione di registro.

Answer 11

Personalmente credo che prima di tutto non ci siano regole rigide e veloci. Ho alcune applicazioni che registrano MOLTO, dentro e fuori i metodi e gli aggiornamenti di stato nel mezzo. Queste applicazioni, tuttavia, sono processi pianificati, eseguiti a mani libere e i log sono analizzati da un'altra applicazione che memorizza il successo / fallimento.

Ho scoperto che in tutta la realtà, molte applicazioni utente non necessitano di grandi quantità di registrazione, poiché in realtà se sorgono problemi dovresti eseguire il debug per rintracciare i valori lì. Inoltre, in genere non è necessario il costo della registrazione.

Tuttavia, dipende davvero dal progetto.

Answer 12

Nella mia linea di lavoro, scrivo molti servizi di Windows. Per me la registrazione non è un lusso; in realtà è la mia unica interfaccia utente. Quando distribuiamo alla produzione, perdiamo l'accesso al debug e persino ai database su cui scrivono i nostri servizi e senza registrazione non avremmo modo di conoscere le specifiche delle problematiche che si presentano.

Detto questo, credo che uno stile di registrazione conciso sia l'approccio migliore. I messaggi di registro tendono ad essere limitati alla logica aziendale dell'applicazione come "messaggio ricevuto dall'account xxx". di "quotata funzione yyy". Registriamo eccezioni, inizia il thread, riecheggia le impostazioni e i tempi dell'ambiente. Oltre a ciò, guardiamo al debugger per identificare errori logici nelle fasi di sviluppo e QA.

Answer 13

Devo confessare che quando ho iniziato a programmare ho registrato più o meno tutti i dettagli come descritto da " Dillie-O " ;.

Credetemi ... Ha aiutato molto durante i primi giorni di distribuzione della produzione, dove ci siamo affidati fortemente ai file di registro per risolvere centinaia di problemi.

Una volta che il sistema diventa stabile, ho lentamente iniziato a rimuovere le voci di registro mentre il loro valore aggiunto iniziava a diminuire. (No Log4j in quel momento.)

Penso che il rapporto tra voci da codice a registro dipenda dal progetto e dall'ambiente e non debba necessariamente essere un rapporto costante.

Oggi abbiamo molta flessibilità nella registrazione con pacchetti come Log4j, abilitazione dinamica del livello di registro, ecc.

Ma se i programmatori non lo usano in modo appropriato, come quando usare, quando NON usare INFO, DEBUG, ERRORE ecc. così come i dettagli nei messaggi di registro (ho visto messaggi di registro come, " Ciao X , Ciao XX, Ciao XXX, ecc. "Che solo il programmatore può capire) il rapporto continuerà ad essere elevato con meno ROI .

Answer 14

Penso che un altro fattore sia il set di strumenti / la piattaforma utilizzata e le convenzioni che ne derivano. Ad esempio, la registrazione sembra essere abbastanza pervasiva nel mondo J (2) EE, mentre non ricordo di aver mai scritto un'istruzione di registro in un'applicazione Ruby on Rails.