Writing Code and Other Prose

A blog about software development, electronics, and writing.

Das Ende fetter Log-Dateien

So langsam habe ich die Philosphie des Unit Testing verinnerlicht und beobachte interesante Verhaltensänderungen.

Lange Jahre war ich ein großer Fan von Log-Dateien und im Debug-Modus sind die meisten meiner Programme mehr als geschwätzig. Da werden alle Methodenaufrufe, das Verlassen einer Methode, sämtliche Aufrufparameter und jedes nur denkbare Ereignis in einer Log-Datei für die Ewigkeit festgehalten. Diverse Kilobytes Text werden für nur eine einzige Anfrage an einen Server erzeugt.

Warum das alles? Nur damit im Falle eines Fehlers Forensik betrieben werden kann. Typische Vorgehensweise: Trouble Ticket kommt an. Betroffenes System? Uhrzeit des Problems? Kundennummer? Aha, der Fehler müsste also in der Log-Datei xyz.log festgehalten worden sein. Jetzt kann anhand dieser Datei Schritt für Schritt nachvollzogen werden, wie das Problem entstanden ist. Eigentlich keine schlechte Sache, oder?

Doch, es ist eine schlechte Sache, denn wenn man mal genauer darüber nachdenkt, so ist es doch absurd: Da vergeuden wir wertvolle Ressourcen um wieder und wieder dieselben Dinge mit unterschiedlichen Zeitstempeln ins Dateisystem zu schreiben. Die meisten Anfragen funktionieren doch (sonst würde unsere Software den Kunden ja nicht angeboten, oder?). Nur für den Fall, dass eine gewisse, unerwartete Konstellation von Eingaben zu einem Fehler führt, halten wir die Historie aller Anfragen detailliert fest.

Seit ich Unit Testing verwende, tue ich das nicht mehr. Klar, ich schreibe immer noch Log-Dateien, aber darin halte ich wirklich nur noch Nenneswertes fest: Sämtliche externen Ein- und Ausgaben, die Kommunikation mit Systemen Dritter usw. Tabu ist aber alles, was mit dem Ablauf meiner Software zu tun hat.

Wenn ein Problem auftritt, prüfe ich anhand der Log-Datei, ob das Problem durch meine Software oder durch ein von mir verwendetes Fremdsystem verursacht wurde. Lag es an mir, so hole ich mir aus der Log-Datei die Eingaben, die zum fehlerhaften Verhalten führten und mache daraus einen Testfall in meinen automatischen Unit Tests.

Ausgerüstet mit einer vernünftigen Anzahl guter Tests ist es im Normalfall ein Leichtes, die Ursache des Fehlers zu finden und zu beheben. Die genaue Reihenfolge der Ausführungsschritte, wie sie in Log-Dateien zu finden ist, spielt dabei eine völlig untergeordnete Rolle. Wichtig ist das Verhalten der einzelnen Teile bzw. Klassen eines Programms.

Vorbei sind auch die Zeiten, in denen die produktive Software gerade nicht im Debug-Modus lief und mal wieder keine detallierte Log-Datei erzeugt wurde, als tatsächlich ein Problem auftrat. Mit Unit Tests kann ich ein reproduzierbares Problem nur anhand der Eingabeparameter immer wieder auftreten lassen, bis es endlich gelöst ist.

Somit habe ich das Beste aus allen Welten: Schlanke Log-Dateien, die sich leicht für andere Zwecke, wie z. B. Statistiken, auswerten lassen, Testfälle für in der Realität aufgetretene Probleme und ein System, das meine Software völlig automatisch auf Herz und Nieren prüft.

Übrigens lässt sich diese Erfahrung auch schnell auf andere Bereiche ausdehnen, denn ein Werkzeug wie der gute alte Debugger hat mit Unit Testing auch so gut wie ausgedient.


Share

comments powered by Disqus