To refactor or not to refactor

Refactoring ist zurzeit ein Modewort. Gemeint ist damit, den Quelltext eines Programmes zu verbessern, ohne neue Funktionalität hinzuzufügen oder die bestehende Funktionalität zu beeinträchtigen.

Angestrebt wird mit Refactoring, die Wartbarkeit von Software zu erhöhen. Es sind ganze Bücher und natürlich Blog-Posts zum Thema verfasst, Kataloge über Refactoring-Patterns geschrieben und „Code Smells“ identifiziert worden, die dabei helfen, unschönen Code aufzuspüren und durch bessere Lösungen zu ersetzen. Doch auch ohne diese Bücher eingehend zu studieren, dürften den meisten Programmierern die Schritte hin zu besserem Code geläufig sein: Sprechende Variablen- und Funktionsnamen, das Aufsplitten von grossen in mehrere kleine Klassen, oder das Auslagern von ähnlicher Funktionalität in eine Oberklasse gehören zum täglichen Handwerk.

Das Refactoring von grösseren Projekten bringt jedoch auch Risiken mit sich: Zum einen ist schwer abzuschätzen, wann der Code für die Veröffentlichung „schön genug“ ist, und Refactoring kann zum teuren Selbstläufer werden. Zum anderen besteht eine reale Gefahr, vorhandenen Code zu beschädigen: Denn die Einzelteile des bestehenden Systems sind unter Umständen stärker miteinander verwoben, als dies auf den ersten Blick ersichtlich ist. Eine unbedachte Änderung einer Methode kann andernorts zu unerwünschten Nebeneffekten führen. Automatisierte Tests helfen, dieses Risiko zu verringern, doch auch diese müssen sorgfältig erstellt werden und die richtigen Bedingungen testen. Schliesslich ist eine sorgfältige Zeitplanung notwendig, um ein Projekt trotz Refactoring fristgerecht abliefern zu können – auch schöner Code nützt wenig, wenn er nie produktiv eingesetzt wird. (Gründe, auf ein Refactoring zu verzichten.)

Für ein grösseres Kundenprojekt, an welchem mehrere Entwickler über einige Monate hinweg arbeiteten, entschieden wir uns relativ spät im Projektverlauf trotz der genannten Bedenken, ein Refactoring durchzuführen. Kurz zusammengefasst ging es darum, Daten über die Struktur der Website in einer XML-Datei statt einer Datenbank zu verwalten. Die Entscheidung, Daten in einer Datei abzuspeichern, hatte weitreichende Konsequenzen und betraf das Projekt an vielen Stellen.

Wichtig für das erfolgreiche Refactoring waren zwei Dinge: Erstens setzten wir uns eine knappe Frist von drei Tagen, nach deren Ablauf die Grundfunktionalität wie mit der bestehenden Architektur funktionieren musste – ansonsten hätten wir das Refactoring eingestellt und mit der alten Architektur weiterentwickelt. Zweitens verfügt unser Ray-Framework bereits über viele eingebaute Funktionen zur Verarbeitung von XML. Daher konnten wir projektspezifischen Code für die Datenbankabfragen durch bereits bestehende und ausgetestete Funktionsaufrufe ersetzen: Unsere projektspezifische Codebasis verringerte sich dadurch spürbar. Letztendlich haben wir mit dem Refactoring gute Erfahrungen gemacht. Wir werden jedoch auch in Zukunft die Vor- und Nachteile sorgfältig gegeneinander abwägen.