In der Theorie lernt man sehr viele Dinge, die sich in der Praxis des Arbeitsalltags leider nur selten wieder finden. So sind Unittests in unserer alltäglichen Softwareentwicklung ein Fremdwort. Für mein aktuelles Projekt wollte ich diesen Umstand aus gegebenem Anlass ändern und habe angefangen, Tests nachzustricken.
Während des Entwerfens der Testfälle fragte ich mich, wie sich die Klasse, die ich gerade bearbeitete wohl unter Reset ihrer Daten verhält, und ob ihr Zustand danach wirklich definiert ist, da ich ursprünglich davon ausging, dass die Daten nur einmal pro Instanz gesetzt werden, was ich aber programmtechnisch nicht erzwungen hatte.
Ich hatte zwei Möglichkeiten: Im Source der Klasse nach lesen, was in diesem Fall wohl passiert, oder einfach einen Testfall dafür schreiben. Ich entschied mich für die zweite Lösung, was zu zwei Ereignissen führte: Ich entdeckte, dass sich die Klassenimplementation tatsächlich falsch verhielt und ich hatte das erste Mal in der realen Welt Kontakt mit test driven development (TDD).
Bei der ganzen Sache fiel mir ein Fakt auf:
Das Leben ist wie TDD beim refactoring und bug hunting von legacy code. Man hat einen Haufen Code, von dem eine ganze Menge irgendwie funktioniert, und man weiß nicht genau warum. Und dann gibt es Code, der nicht richtig funktioniert wie er soll, und auch hier weiß man nicht, warum er das tut. Also schreibt man sich ein paar Unittests, Blaupausen der eigenen Vorstellung, wie sich das Programm verhalten soll, und fängt an, das Programm langsam aber sicher umzustricken. Man nimmt sich einer Kante der Klasse nach der anderen an und bringt diese dazu, sich den eigenen Vorstellungen entsprechend anzupassen.
Nun hat man als Schöpfer des eigenen Lebenablaufes das gleiche Problem wie der Softwareentwickler: Wenn man es mit fremdem Code zu tun hat, ist man sofort versucht, alles als Müll abzutun und wegzuwerfen und das Rad von vorne zu erfinden, wenn es aber um eigenen alten Code handelt, kann es noch so ein Schrott sein, man wird meist an der alten Implementierung festhalten und nur ein wenig hier und da rumpfuschen, in der Hoffnung, dass es besser wird.
Ab wann sollte man sich von einer Implementierung trennen und eine neue beginnen? Warum gibt es kein Werkzeug, keine Codemetrik, die einem einen Anhaltspunkt liefert, wann man etwas neu machen sollte, und wann es sich lohnt, das alte zu reparieren?
Und wenn das Design der Klasse, das Interface schon fehlerhaft war? Wie soll man so eine Entscheidung treffen, wenn man noch gar keine Vorstellung davon hat, wie die neue Klasse eigentlich aussehen soll?
Also muss man auch noch die Architektur überarbeiten. Und vielleicht kommt dabei heraus, dass das Interface schlecht war… vielleicht, oder auch nicht.
Jedenfalls ist es besser, als immer wieder Instanzen von dem gleichen fehlerhaften Klassendesign zu machen.
Music for today The Corrs – At Your Side