Komplexe Refactorings mit der Mikado-Methode durchführen
Nicht wackeln
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.
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 mehrfachen 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 [a].
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.