Frank PientkaInnovation und Technologie

Refactoring im Großen und Kleinen

Kaum ist man ins neue Heim gezogen, gehen die ersten Umbau- und Renovierungsaufgaben los. Nicht anders ist es bei Software.

Eine besonders üble Sitte ist das Duplizieren von Code oder das Erfinden von neuen eigenen komplexen Lösungen, statt die bereits für ähnliche Probleme bekannten und bewährten Muster zu verwenden. Das systematische Umstrukturieren von Code nennt man Refactoring – nach Martin Fowlers Buch „Refactoring. Wie Sie das Design vorhandener Software verbessern, ist eine feste Folge von automatisierbaren Schritten, die die interne Struktur der Software verändern, um sie lesbarer und änderbarer zu machen. Deswegen hängt Refactoring eng mit der Verbesserung der Qualitätsanforderungen wie Lesbarkeit, Verständlichkeit, Wartbarkeit und Erweiterbarkeit zusammen.

Dafür hat Fowler über 90 Regeln (http://refactoring.com/catalog) beschrieben die auf übelriechende Codestellen angewandt werden. Einige Refactorings beziehen sich auf eine Klasse, andere auf mehrere Klassen bzw. Dateien, wenn man die Referenzen der Klassen mitzählt. Die meisten angewandten Refacorings beziehen sich auf nur wenige Dateien, wie Auswertungen von bekannten Open-Source-Projekten oder auch die Benutzungsstatistiken der Eclipse-Refacoring-Funktionen zeigen.

Bereits in seinem Buch gibt es ein Kapitel über „Big refactorings“. „Small refactorings“ gehören inzwischen zu jedem guten Entwickleralltag, nachdem die Basis wie Unit-Tests und Werkzeugunterstützung in den Entwicklungsumgebungen integriert sind.

Meist werden jedoch Refactorings eher bei funktionalen oder objektorientierten Sprachen durchgeführt. Hier kommt hinzu, dass es bei dynamisch typisierten Skriptsprachen oft erst zur Laufzeit möglich ist, zu überprüfen, ob die Umbaumaßnahmen auch korrekt ausführbaren Code hinterlassen.

Da immer mehr und größere Codeteile in JavaScript erstellt werden, sind Erweiterungen zur Typisierung der JavaScript durch ECMAScript6 TypeScript hilfreich. Nur mit diesen Erweiterungen und Werkzeugen, wie JSRefactor oder GrapsJS, wird auch Refactoring für JavaScript nutzbar.

Ein anderes Problem sind Generierungswerkzeuge, da dieser Code sicher auch viele Duplikate und zu refactorierende Codeteile enthält. Metriken, die hier diese Art von Code nicht von ihren Analysen ausschließen, führen zu falschen und gefährlichen Schlüsseln.

Ein großes Problem sind Architektur- oder Design-Refactorings. Hier gibt es zwar die wegweisenden Bücher von Joshua Kerievsky „Refactoring to Patterns“ und “Refactorings in großen Software-Projekten” von Stefan Roock und Martin Lippert. Diese Refactorings helfen im Nachhinein, die im Gang of Four-Buch („Design Patterns: Elements of Reusable Object-Oriented Software“) beschriebenen Design-Patterns für immer wiederkehrende Probleme als Lösung einzuführen.

Da solche Refactorings jedoch nicht ohne größere Absprachen eingeplant und durchgeführt werden können, scheitert das gerade bei agilen Projekten, bei denen ja die fachliche Lösung eher im Vordergrund steht als das saubere Design.

Hier ist oft schwierig zu argumentieren, wie große Refactorings einen potenziellen Geschäftsnutzen erzeugen bzw. ermöglichen. Hier ist es besser, es gar nicht zu weit kommen zu lassen. Mit einfachen Metriken kann die Architekturqualität kontinuierlich überprüft werden und bei groben Abweichungen können kleine Gegensteuermaßnahmen eingeleitet werden, bevor alles aus dem Ruder läuft, was letztendlich oft im Wartungs-Chaos endet.

Hier ist es besser, bei neuen noch frischen Codeteilen geeignete Refactorings frühzeitig durchzuführen, statt beim Altcode erst Software-Archäologie betreiben zu müssen und dabei den Wald vor lauter Bäume nicht zu sehen. Kleinere, dafür öfters und vor allem selbständig durchgeführte qualitätssichernde Maßnahmen sind oft besser als die nie oder nur halbherzig durchgeführten „großen Refactorings“. Die alte Pfadfinderregel gilt auch beim Programmieren, hinterlasse den Code in einem besseren Zustand, als du ihn vorgefunden hat und versuche Code-Müll zu vermeiden.

Der damit aufgebaute technische Schuldenberg ist nur schwer und dauerhaft abzutragen, da er oft nur über Prozess- und Verhaltensänderung aller Beteiligten geht. Regelmäßige Architekturreviews können hier ein erster Schritt sein. Um auch in der Zukunft das Anhäufen von technischen Schulden im großen Stil zu vermeiden, setzen sie jedoch den Willen aller und eine entsprechende Qualitätskultur voraus. Nur so kann Software-Entwicklung und die dabei eingesetzten Methoden wie Refactoring mit einem nachhaltigen und spürbaren Erfolg eingesetzt werden. Die Grundlagen dazu wurden, wie so oft bereits vor über einem Jahrzehnt geschaffen. Packen wir es gemeinsam an!

Schlagwörter: