Dal punto di vista di uno sviluppatore avere una grande quantità di informazioni di tracciamento è una vera manna dal cielo quando si ottiene una segnalazione di bug da un cliente che spesso consente di riprodurre e diagnosticare rapidamente la causa di un bug da un file di registro: non tutti i bug sollevano eccezioni, e questo vale doppiamente per i più cattivi.
Quando arriva una segnalazione di bug direi più verbosa è la registrazione, meglio è. Inoltre, quando si esegue il codice, essere in grado di osservare ciò che sta facendo in tempo reale nella vista di debug è davvero molto utile, specialmente per il codice multithread. Immagino che questo debba essere qualificato dicendo che vuoi minimizzare la ripetizione per migliorare la leggibilità; ma in generale quando un bug arriva sulla tua scrivania, in genere non chiedi meno informazioni.
Esistono tuttavia ottime ragioni per non utilizzare la traccia:
- Può portare a un orribile, brutto codice di codice che può impedire il refactoring. Mettere una "funzione di invio" "funzione di uscita" su quasi tutti i metodi è un incubo di manutenzione e sembra sbagliato. In C # puoi usare Post Sharp che risolve questo problema iniettando IL nel tuo codice in modo da non vedere mai quelle chiamate, ma in generale credo che non ci sia modo di aggirare questo.
- Ti rallenta il codice. Questo potrebbe non essere un grosso problema: se il collo di bottiglia in esecuzione è accedere al database, la registrazione dettagliata non sarà un problema. Tuttavia, se sono proprio i colli di bottiglia a essere il collo di bottiglia, la registrazione dettagliata potrebbe rendere il tuo codice troppo lento per essere utilizzabile.
- I dati potrebbero contenere informazioni sensibili che non puoi registrare: ci sono modi per aggirare questo come crittografare il file di log al volo, ma questo si verifica in un overhead delle prestazioni e solo tu sai se è accettabile per la tua applicazione o no.
- Quantità enormi di dati di traccia possono diventare ingombranti. Ad esempio, il framework di testing delle unità Microsoft per Visual Studio visualizzerà l'intero registro trace / debug dopo un test dell'unità: se il codice è piccolo e atomico sono sicuro che funziona davvero bene. Se si dispone di un codice che non si presta a testare facilmente e si finisce per creare pochi MB di dati di traccia / debug per eseguire un singolo test, l'IDE si bloccherà per un minuto o due mentre tenta di visualizzare tali dati.