Allgemeine Debugging-Log-Praktiken

Question

Aufgrund der jüngsten Ereignisse versuche ich herauszufinden, wie viele Debug-Protokolle ich für Code im Allgemeinen verwenden sollte.

Was ich gemacht habe, ist die Verwendung von Debugging-Protokolle ziemlich sparsam, und nur in Fällen, wo ich einige zusätzliche Informationen wollte oder was Sie haben. Das ergab für mich Sinn, da es so aussieht, als ob du nicht jedes kleine Ding, das dein Code tut, protokollieren solltest, denn das könnte dich mit so vielen Informationen überfluten, dass es leichter wäre, etwas zu verpassen, das wirklich wichtig ist (oder vom Graben verrückt wird) Protokolle durchlaufen und überprüfen.

Auf der anderen Seite stelle ich ein Beispiel vor: Ich habe gerade angefangen, Logback/Slf4j für mein Java-Projekt zu verwenden, und um zu testen, dass ich die .xlm-Datei korrekt eingerichtet hatte, fügte ich eine Debugging-Protokollanweisung an das Ende von ein Methode, die GUI-Komponenten initialisiert. Normalerweise hätte ich dort nie eine Log-Anweisung gesetzt, weil es ziemlich offensichtlich ist, wenn Ihre GUI-Komponenten beim Ausführen des Programms nicht korrekt initialisiert werden. Dieses Mal habe ich das Programm ausgeführt, und niedrig und siehe die Protokolle zeigten, dass die GUI-Komponenten zweimal initialisiert wurden, obwohl nur ein Satz von ihnen angezeigt wurde. Ein ziemlich großer Fehler, aber etwas, ohne das ich ohne diese Debugging-Anweisungen nicht hätte kommen können.

Also meine Frage: Gibt es irgendwelche "Best Practices", wenn es darum geht, Protokolle zu debuggen? Ich habe viele Best-Practice-Fragen gesehen, wenn es um Info-Logs, Exceptions, Fehler usw. geht, aber ich habe nicht viel über Debugging-Logs herausgefunden.

Thanks :)

Answer 1

Einige Gedanken:

1. nicht nur nicht vermerken, was passiert, aber darauf achten, die verfügbaren Parameter/Methodenargumente usw. anmelden Es ist einfach, diese zu übersehen.
2. Es ist einfach, die Debug-Protokollierung über die Konfiguration zu deaktivieren, statt sich nach der Tat anzumelden.
3. Mach dir keine Sorgen über Protokollierung Overhead, bis es wirklich ein Problem wird.
4. Sie können automatisieren einige Protokollierung (Entry/Exit-Methoden) durch einen AOP-Framework (Frühjahr/AspectJ usw.)

Answer 2

Ich glaube nicht, es gibt keine „best practices“ bei der Entscheidung, was/wie viel zu loggen. Es ist eine dieser Catch-22-Situationen. Wenn Sie sich die Logs ansehen müssen, gibt es "nie" genug Informationen, aber wenn Sie das nicht tun, dann ist "all" Logging nur Code-Unordnung und ein unnötiger Laufzeit-Overhead. Sie müssen separat entscheiden, wo die Linie für jede Anwendung gezeichnet werden soll.

Ein Punkt zu beachten. Wenn Sie und Ihre Kunden in der Lage sind, den Code zu hacken, um temporäre Debugging-Anweisungen hinzuzufügen, benötigen Sie nicht so viel permanenten Protokollierungscode. Aber wenn Sie nicht die Möglichkeit haben, den (fast) Produktionscode zu hacken, um Dinge zu debuggen, dann brauchen Sie ein gewisses Maß an Protokollierungscode, nur für den Fall ...