Altsysteme strahlen eine gewisse Faszination aus, denn sie bieten ihre ganz eigenen, spannenden Herausforderungen. Die können viel interessanter als das Zusammenstecken moderner Frameworks zu einer Anwendung auf der grünen Wiese sein. Entwicklerinnen und Entwickler führen aber nur ungern Änderungen an Altsystemen aus, denn es ist oft nicht klar, was dabei kaputtgeht.

Falk Sippach ist Softwarearchitekt, Berater und Trainer bei der embarc Software Consulting GmbH. Er engagiert sich in der Java-Community und teilt sein Wissen in Artikeln, Blogbeiträgen und Vorträgen.

Viele Legacy-Systeme sind technologisch auf dem Stand von vor über zehn Jahren und damit nicht mehr up to date. Es fällt schwer, geeignete Mitarbeiter für die Wartung und Weiterentwicklung zu finden. Regelmäßige Aktualisierungen der eingesetzten Bibliotheken und Frameworks helfen leider nur wenig. Der Quellcode, der in den letzten Jahren schon durch so viele Hände gegangen ist, wird dadurch nicht besser.

Die größten Schwierigkeiten bestehen im fehlenden Wissen über die interne Struktur, über die Entscheidungen, die zu Beginn des Projekts getroffen wurden, und über die unklaren Auswirkungen der Änderungen. Leider lernen die meisten Entwickler in der Ausbildung oder im Studium häufig nur, wie sie neue Systeme erstellen und nicht, wie sie bestehende Software pflegen oder weiterentwickeln können.

Das Refactoring ist dabei ein Mittel zur Struktur- und Designverbesserung. Und in komplexen Umfeldern bietet die Mikado-Methode zusätzliche Unterstützung. In den Worten von Ola Ellnestam und Daniel Brolund, die die Methode erfunden haben: „Die Mikado-Methode ist ein strukturierter Weg, um signifikante Änderungen an komplexem Code vorzunehmen … für Änderungen an einem System, das zu groß ist, um es erst zu analysieren und dann zu bearbeiten. Das betrifft grundsätzlich jedes produktive System in der Welt“ (Ola Ellnestam, Daniel Brolund: The Mikado Method; Manning 2014).

Wie beim Möbelrücken

Beim Editieren an einer Legacy-Code-Basis können Entwicklerinnen und Entwickler schon mal ins Schwitzen kommen. Insbesondere dann, wenn die Änderungen außer Kontrolle geraten und sie nach mehreren Stunden Arbeit wieder ganz am Anfang stehen. Es fällt leichter, wenn es eine ausführliche Dokumentation oder wenigstens automatisierte Tests gibt. Aber häufig steckt die gesamte Wahrheit nur im Quelltext und Tests sucht das Entwicklerteam vergeblich.

Hier unterstützt die Mikado-Methode dank ihres strukturierten Vorgehens. Das Refactoring von komplexem Code läuft ähnlich ab, wie das Umstellen von Möbeln in einer Wohnung. Wenn sich die alte Polstergarnitur aus Platzgründen (Tür wäre verstellt) nicht einfach durch das neu angeschaffte Dreisitzer-Sofa austauschen lässt, dann müssen größere Umbaumaßnahmen erfolgen (siehe Abbildung 1).

Beim Verrücken von Möbeln ergeben sich oft ähnliche Probleme wie beim Refactoring von Software (Abb. 1).

Der Esstisch muss für das neue Sofa weichen. Er soll an den Platz der alten Polstergarnitur rücken, die aber erst mal entfernt werden muss. Genau wie in der Programmierung kann man sich hier schnell im Chaos verlieren. Wenn die Bewohner einfach das neue Sofa ins Zimmer stellen, ist möglicherweise gar kein Platz mehr, um die Möbel umzustellen.

Darum werden die Schritte zunächst nur theoretisch durchdacht und die Hindernisse (zum Beispiel beim Verrücken des Esstischs) jeweils festgehalten. Im nächsten Schritt werden die Bewohner versuchen, das gerade entdeckte Problem zu beseitigen. Dabei stehen aber häufig weitere Hindernisse im Weg, wie in diesem Fall die alte Polstergarnitur. Diese muss zunächst aus der Wohnung entfernt werden. Dann kann der Esstisch umziehen und schließlich das neue Sofa endlich an den geplanten Platz gestellt werden.

Verbessertes Softwaredesign durch Refactoring

Refactoring ist ein Hilfsmittel zur Verbesserung des Softwaredesigns. Bereits vor über zwanzig Jahren hat Martin Fowler in seinem Buch folgende Definition dazu festgehalten: „Refactoring (Substantiv): Eine Änderung an der internen Struktur einer Software, um sie verständlicher zu machen und kostengünstiger ändern zu können, ohne ihr sichtbares Verhalten zu ändern“ (Martin Fowler; Refactoring: Improving the Design of Existing Code; Addison Wesley 2019).

Wer den Quellcode restrukturieren will, wird dazu letztlich eine Serie von Refactorings anwenden. Dabei handelt es sich um sogenannte verhaltenserhaltende Code-Transformationen: An der fachlichen Logik ändert sich nichts. Das Ziel ist eine verständlichere interne Struktur, die zukünftige Änderungen erleichtert und die Testbarkeit erhöht. Damit das Refactoring gut funktioniert, braucht es einige Verbündete.

Dazu zählen schnelle Compile- und Build-Zeiten, vorhandene automatisierte Unit- beziehungsweise Integrationstests sowie eine Versionsverwaltung, um Änderungen jederzeit leicht rückgängig machen zu können. Zudem kann der Einsatz von Werkzeugen bei der sicheren und zügigen Durchführung unterstützen. Viele moderne Entwicklungsumgebungen wie Eclipse oder IntelliJ bringen ein komfortables Tool-Set mit.

Durch das Refactoring sichern Entwickler bestehende Investitionen in ihrer Software ab, verhindern den Designverfall und erhöhen die Lesbarkeit, Änderbarkeit sowie Testbarkeit. Sie können gegebenenfalls gut versteckte Fehler finden, Wissen durch aktives Lernen am Code transferieren, und sie helfen auch den nachfolgenden Entwicklern, die oft vergessene Nutzer des Quellcodes sind. Ganz nach dem Motto von Martin Golding: „Schreibe deinen Code so, als wäre der Typ, der ihn verstehen muss, ein Psychopath mit einer Axt, der weiß, wo du wohnst.“

Die Arbeitsweise basiert dabei auf zwei grundlegenden Prinzipien: erstens den Programmcode nicht kaputt machen und zweitens jeweils nur eine Sache bearbeiten. Bei der Durchführung gehört daher viel Selbstdisziplin dazu. Entwickler sollen immer nur kleine Schritte machen und dann den Code kompilieren sowie die Tests ausführen. Anschließend beginnt es wieder von vorn.

Wichtig ist auch Kent Becks Metapher der zwei Hüte. Man kann immer nur einen Hut auf den Kopf setzen. Daher sollte beim Refactoring kein inhaltlicher Code geändert, also keine neuen Features eingebaut oder Bugs repariert werden.

Angewendet werden können Refactorings bei unterschiedlichen Gelegenheiten: zum Beispiel regelmäßig täglich eine halbe Stunde, damit der Code gesund bleibt. Oder wenn Entwickler den Quellcode nicht (mehr) verstehen und ihn beim Lesen aktiv kennenlernen möchten. Außerdem bietet sich das Refactoring bei geplanten Änderungen an, zum Beispiel vor Erweiterungen beziehungsweise Bugfixes. Oder einfach während eines Code-Reviews, wenn Unstimmigkeiten im Code auffallen. Getreu dem Motto der Boyscout Rule von Robert C. Martin: „Den Platz immer sauberer hinterlassen, als Du ihn vorgefunden hast.“ (Kevlin Henney: 97 Things Every Programmer Should Know; O'Reilly 2010)

Wirklich fertig werden Entwickler übrigens nie. Jedes Refactoring hat möglicherweise ein Gegen-Refactoring. Denn es gibt keine wirklichen Sackgassen und es lässt sich ewig weitermachen. Von daher ist es sehr sinnvoll, Grenzen zu setzen. Entwickler könnten aufhören, wenn der zu analysierende Code verstanden, ein gesetztes Zeitlimit erreicht ist oder der Chef beziehungsweise der Kunde mit einem anderen Auftrag um die Ecke kommt.

So hilft die Mikado-Methode

Refactoring scheint eigentlich ganz einfach zu sein, aber doch auch wieder nicht. Das Vorgehen – möglichst kleine Schritte und das ständige Kompilieren beziehungsweise Ausführen der Tests – gerät schnell in Vergessenheit. Was bei einem überschaubaren Kontext noch gut funktioniert, fällt bei komplexen Softwaresystemen deutlich schwerer. Gemäß der Mikado-Methode lassen sich rasch blockierende Elemente ermitteln und analysieren. Diese Hindernisse werden dann aber zunächst nur notiert und erst nach der gesamten Analyse Schritt für Schritt entfernt. In den Worten von Ellnestam und Brolund: „Die Mikado-Methode hilft dabei, am Business Value orientierte Verbesserungen über mehrere Iterationen und Arbeitsschritte zu visualisieren, zu planen und umzusetzen, ohne dass die Codebasis während des Prozesses jemals kaputtgeht“ (Ola Ellnestam, Daniel Brolund: The Mikado Method; Manning 2014).

Die Vorgehensweise ist dabei relativ einfach (siehe Abbildung 2). Zunächst legen die Entwickler das Ziel fest (1). Das ist der Startpunkt der anstehenden Änderungen und gleichzeitig auch das Erfolgskriterium für das Ende. Anschließend beginnt das Team damit, erste Lösungsansätze auszuprobieren (2). Bei diesen Experimenten darf es den Code aktiv ändern, um Hypothesen zu prüfen und deren Auswirkungen zu beobachten. Hindernisse visualisieren die Testerinnen und Tester transparent für alle im Mikado-Graph (3). Die durch die Experimente eingeführten Änderungen machen sie dann direkt wieder rückgängig (4), zum Beispiel durch einen git reset. Anschließend geht es bei Schritt 2 weiter und das Vorgehen wiederholt sich so lange, bis keine Hindernisse mehr im Weg stehen.

Abbildung 2 zeigt den Gesamtablauf der Mikado-Methode. Durch den wiederkehrenden Zyklus Ausprobieren-Visualisieren-Rückgängigmachen (2) baut sich Stück für Stück der Mikado-Graph auf. Dieser Graph enthält viele wertvolle Informationen über die Struktur des Systems. Die Erstellung kann jederzeit unterbrochen und später fortgesetzt werden. Die Code-Basis ist dabei immer in einem lauffähigen Zustand, denn alle durchgeführten Experimente werden ja nach dem Dokumentieren wieder rückgängig gemacht. Sobald alle Hindernisse auf dem Weg zum festgelegten Ziel analysiert sind, wird der Graph rückwärts abgespult. Alle dokumentierten Änderungen werden der Reihe nach ausgeführt (3), bis das ursprüngliche Ziel erreicht ist (4).

Gesamtablauf: Nach dem Ablauf der Zyklen setzt das Team alle Änderungen in umgekehrter Reihenfolge um. Der rechte, bunte Teil der Grafik zeigt das nachfolgende Beispiel (Abb. 2).