Komplexe Refactorings mit der Mikado-Methode durchführen
Das Fehlen automatisierter Tests ist nur ein Stolperstein in Legacy-Projekten. Viel größer ist die Herausforderung, wenn selbst mit ihnen keine klare Vorstellung davon existiert, wie man komplexe Refactorings überhaupt angehen könnte. Oft fehlt ein strukturierter Prozess.
- Stefan Lieser
Damit ein Team ein Projekt sinnvoll weiterentwickeln kann, ist ein grundlegendes Verständnis seines Aufbaus und der implementierten Funktionen nötig. Refactorings können nicht nur dabei helfen, ein solches zu erlangen, sondern sich auch positiv auf Softwareeigenschaften wie die Performance auswirken. Ohne passende Strategie kann es jedoch sein, dass Erfolge selbst nach längeren Versuchen, den Code unter Kontrolle zu bringen, ausbleiben. Eine Folge ist häufig, dass Teams komplexe Refactorings nicht angehen oder abbrechen, um die Funktionsfähigkeit des Programms nicht zu gefährden. Allerdings tragen schon einfache Überarbeitungen dazu bei, den Code verständlicher und damit wandelbarer zu gestalten. Statt alles hinzuwerfen, sollten Entwickler daher zumindest bei der Codeuntersuchung erlangte Erkenntnisse im Code festhalten.
Allgemein gibt es zwei Gründe, komplexe Refactorings anzusetzen: Entweder soll das Team ein neues Feature ergänzen beziehungsweise ein altes modifizieren oder es muss einen Fehler beheben. Da Auftraggeber von der Annahme ausgehen, dass ihre Software dem Stand der Technik entsprechend test- und wandelbar ist, lohnt sich ein umfassendes Refactoring aus wirtschaftlicher Sicht nur, wenn solche Änderungen anstehen. Anders wird sich beispielsweise das Ergänzen von Prüfmaßnahmen nicht abrechnen lassen.
Der Überarbeitungsprozess beginnt typischerweise mit einer Änderung am Code. Sie löst eventuell an anderer Stelle Fehlfunktionen aus. Diese müssen die Entwickler beheben, wobei nicht auszuschließen ist, dass auch die Lösung Fehler nach sich zieht, denen es entgegenzuwirken gilt. Die Schritte wiederholen sich so oft, bis keine Schwierigkeiten mehr auftreten und die gewünschte Änderung anstandslos funktioniert.
Da sich der Vorgang über Wochen hinziehen kann, arbeitet das Team meist auf einem Branch der Versionskontrolle. So stören die Refactoring-Maßnahmen nicht die Weiterentwicklung, die gleichzeitig auf dem Trunk oder einem weiteren Branch stattfindet. Allerdings entstehen beim späteren Merge der Änderungen neue Herausforderungen: Da das Zusammenfügen aller Modifikationen teilweise nicht ohne weiteres möglich ist, führt das Refactoring-Team einzelne Schritte erneut aus, scheint solch ein Vorgehen doch häufig einfacher als ein Merge. Kein Wunder, dass Entwickler von solchen Refactorings lieber die Finger lassen.
Mikado für Entwickler
Ola Ellnestam und Daniel Brolund haben in ihrem Buch "The Mikado Method" die Mikado-Methode vorgestellt, um Refactorings den Schrecken zu nehmen. Am Anfang des Prozesses steht die angstrebte Änderung, die die Entwickler im sogenannten Mikado-Graph notieren (dazu später mehr). Sollten nach dem Umsetzen Fehler auftreten, hält das Team sie als Erkenntnisgewinn im Graph fest, statt sie sofort zu beheben. Anschließend versetzt es den Code mit der Versionskontrolle in den Ursprungszustand, wodurch erneut ein definierter Ausgangspunkt vorliegt. Mit ihm als Grundlage geht das Team den nächsten Lösungsversuch an. Anschließend bemerkte Fehler notiert es erneut und setzt wieder alles zurück. Der Prozess ist beendet, sobald das Mikado-Ziel erreicht ist.
Nun versuchen sich die Entwickler an der Lösung eines der notierten Probleme. Neue Herausforderungen hält es im Graphen fest. Am Ende des Prozesses steht eine Visualisierung der für die Änderung geeigneten Vorgehensweise zur Verfügung (siehe Abb. 1).
Durch die versuchten Änderungen und den Mikado-Graph ist der Refactoring-Prozess in kleine Schritte zerlegt. Beim Erarbeiten erlangte Erkenntnisse lassen sich in der Regel nicht durch eine Analyse gewinnen, da sich einige Details erst während des Versuchs offenbaren.
Sonderheft "Altlasten im Griff"
Mehr Artikel zum Thema Legacy-Code sind im Sonderheft iX Developer 01/2017 zu finden, dass sich unter anderem im heise Shop erwerben lässt.
Beim Refactoring von Legacy-Code handelt es sich folglich um eine komplexe Aufgabe. Es lässt sich nicht allein durch Nachdenken feststellen, ob ein erarbeiteter Lösungsansatz tatsächlich die gewünschte Änderung umsetzt. Erst ein Experiment klärt, ob sich das Verfahren eignet.
Ein weiterer Vorteil des Mikado-Graphen liegt in der Visualisierung. Mit ihm lässt sich im Team viel besser besprechen, wer welche Aufgaben übernimmt, wann einzelne Schritte durchzuführen sind, et cetera. Ferner können die Entwickler das ehemals große Refactoring, das sich nur "ganz oder gar nicht" angehen ließ, nun über einen längeren Zeitraum strecken. Mit seinen Blättern bietet der Graph eine Hilfestellung beim Festlegen der Reihenfolge der Aufgabe. Dadurch ist es möglich, einzelne Refactoringschritte konkret einzuplanen und mit der Weiterentwicklung des Systems zu verzahnen.
