Beim Begriff Legacy Code stellen sich Software Engineers oftmals die Haare auf. Der verpönte Code macht gerne Schwierigkeiten bei der Arbeit, insbesondere bei der Entwicklung neuer Features. Wie geht man mit dem schwarzen Schaf der Softwareentwicklung um? Software Engineer Oliver Zihler bietet Rat rund um Refactoring.
Wir Softwareentwicklerinnen und -entwickler lieben Greenfield-Projekte. Denn bei solchen können wir alles so einrichten, wie wir es wollen, mit der aktuellsten Technologie arbeiten und gleich zu Beginn entscheiden, wie unsere Architektur aussehen soll. Die Software, die wir bauen, ist gewissermaßen unser Baby. Als Profis möchten wir unserer Kundschaft nicht nur ein Produkt liefern, sondern ein ästhetisches Meisterwerk schaffen, das es wert ist, an die sprichwörtliche Wand gehängt zu werden und für seine Perfektion gerühmt wird. Die Welt soll seine Einfachheit und Überlegenheit in Sachen Design und Programmierung bewundern: „Das ist ein Rembrandt der Softwareentwicklung – was für ein Kunstwerk“, sollen sie sagen.
Um aber den Superbösewicht Thanos zu zitieren: „Die Realität ist oft enttäuschend.“ Viel zu oft wird uns eine bestehende Codebasis zugewiesen, an der sich bereits vor uns viele andere selbsternannte Kunstschaffende versucht haben. Mit Betonung auf versucht. Keine Spur von Rembrandt. Auch Tests sorgen nicht für mehr Verständnis: Sie sind entweder gar nicht vorhanden, verworren, unvollständig oder zeitraubend, und ihre Codeabdeckung ist alles andere als befriedigend. Schlussendlich wird uns klar: Es geht mal wieder um Refactoring von Legacy Code.
Legacy Code – der Albtraum jedes Softwareentwicklers
Legacy Code gibt es in vielen Formen und Farben. Für manche ist es einfach nur „Code, den wir nicht selbst geschrieben haben“. Bei anderen gilt jeder Code ohne Tests sofort als Legacy, da unser Verständnis und Wissen in Bezug auf den Code ohne richtige Tests schnell gegen null geht. Im Allgemeinen lässt sich Legacy Code nur schwer oder gar nicht ändern, da es sich für gewöhnlich um Spaghetticode ohne selbsterklärende Abstraktion handelt oder weil jede Änderung viele unerwünschte Nebenwirkungen mit sich bringt – sogenannte Bugs. In jedem Fall ist die Arbeit daran ein Albtraum. Legacy Code ist der Code, der alle zum Verzweifeln bringt, die daran arbeiten müssen.
Das Refactoring von Legacy Code mag auf den ersten Blick wie eine mühsame und langweilige Aufgabe erscheinen, aber am Ende ist es irgendwie lohnend: Man lernt, was man als Software Engineer eben nicht tun sollte. Und Änderungen sind davon abgesehen kaum zu vermeiden. Stellen Sie sich ein Legacy-Finanzsystem vor, in dem D-Mark, Francs usw. verwendet wurden. Mit der Einführung des Euro mussten diese verschiedenen Währungen natürlich ersetzt werden. Die Umwelt ändert immer wieder die Anforderungen an ein System, da können wir nichts dagegen tun. Deswegen muss auch das am besten geschützte Legacy-System irgendwann mal bearbeitet und auf die eine oder andere Weise geändert werden. Die armen Software Engineers, die diese Herausforderung meistern müssen, sind nicht zu beneiden.
Wie wir den Umgang mit Legacy Code meistern
Wir benötigen deshalb unbedingt Tools und Fähigkeiten, die uns beim Refactoring von Legacy Code helfen. Sie unterscheiden sich von den Tools, die wir nutzen, um neuen Code zu schreiben, denn das angewandte Refactoring kann ohne Testen des Codes nicht sicher durchgeführt werden. D. h., vor dem Refactoring müssen wir den Code zunächst testen. Und bevor wir den Code testen können, müssen wir ihn testbar machen. Dinge wie umständliche Abhängigkeiten – z. B. Datenbankzugriffe – oder fehlende Injektionspunkte wie Objekte, die neu in unserem Code erstellt wurden, sind Probleme, die angegangen werden müssen, um Tests zu schreiben, die das Verhalten des Legacy-Code-Wirrwarrs charakterisieren. Ohne solche Pindown-Tests haben wir keine Möglichkeit, schnell herauszufinden, ob der Code sich nach dem Refactoring noch gleich verhält wie zuvor.
Nur wenn wir den Umgang mit Legacy Code meistern, kann unsere Realität so aussehen, wie wir sie uns wünschen. Plötzlich verstehen wir Code, bei dem sich unsere Nackenhaare aufstellten, als wir ihn das erste Mal sahen. Wo einst Chaos herrschte, tauchen selbsterklärende Abstraktionen auf. Erforderliche Änderungen machen uns nicht mehr verrückt, da die zu ändernde Stelle schnell gefunden werden kann. Oder zumindest gelingt es uns, das Wirrwarr vom neuen Code zu trennen und durch klar definierte Schnittstellen darauf zuzugreifen. Darum müssen alle Software Engineers unbedingt diese Fähigkeiten erlangen. Nur dann werden wir endlich nicht mehr zittern müssen, wenn wir einen Legacy Code sehen, da wir genau wissen, was zu tun ist.
