Refactoring – Altlasten beseitigen

Software lässt sich wesentlich einfacher als Projekte der realen Welt umbauen oder aufräumen, ohne dabei Rückstände zu hinterlassen. Trotzdem enthalten größere Softwareprojekte immer wieder Altlasten, die jede Wartung und Erweiterung unnötig belasten. Aus diesem Grund musste ich diesem sehr wichtigem Thema einen eigenen Beitrag spenden.

Historisch gewachsen

Die Bedeutung dieser zwei Worte haben schon so manchen Entwickler Zeit und Nerven gekostet. Damit ist Code gemeint, der über die Zeit nicht durchgängig gepflegt wurde und somit Inkonsistenzen aufweist. Sobald ein Satz fällt wie „das ist historisch gewachsen“, müssen sich zuständige Entwickler auf irrationalen Code einstellen, mit dem sie dann weiter arbeiten. Solch ein Code verschwendet teure Entwicklungszeit. Daher muss jeder Entwickler sofort melden, sobald er Code findet oder produziert, der historisches Wachstum aufweist, damit dieser dann eingeplant und bereinigt werden kann.

Welche Arten von „historischem Code“ gibt es?

Es schleichen sich gerne folgende Arten von historisch gewachsenem Code in größere Softwareprojekte ein.

Unterscheidungen von historischem Code:

• Überreste alter Technologien, die beim Einführen Neuerer nicht vollständig ausgewechselt wurden.
• Nicht durchgängig angepasste Bezeichner (Inkonsistente Bezeichner).

Veraltete Technologien

Oft ist unsicher ob alte Technologien noch benutzt werden, daher lässt man ihre Funktionalität gefährlicher Weise am Leben. Dies geschieht meist aus Zeitgründen, da sonst die Einführung neuer Technologien den verfügbaren zeitlichen Rahmen sprengen.

Inkonsistente Bezeichner

Bezeichner werden ganz einfach nicht durchgängig korrigiert. Oberflächenänderungen schlagen sich hierbei meist nicht bis zum Backend durch oder umgekehrt. Gerade bei verteilter Software wird oft nur eine Komponente geändert. Sicher auch aus dem Grund, weil diese Änderungen den zeitlich oder auch organisatorischen Rahmen überschreiten.
Ein Beispiel wäre eine Änderung im Frontend, die bei einer sauberen Änderung auch das Backend betreffen würde und somit eventuell erst mit einem neuen Release ausgeliefert werden kann, der Kunde jedoch diese Funktion früher benötigt.

Wie können diese Altlasten verhindert werden?

Es gibt zum Glück eine Vielzahl an Möglichkeiten, diese unangenehmen Altlasten los zu werden. Diese müssen allerdings konsequent und vor allem stetig angewendet werden, um Altlasten entfernen oder besser gar nicht erst entstehen zu lassen.

1.) Refactoring muss bei jeder Aufwandsschätzung mit einkalkuliert werden
Es ist sehr wichtig, ausgiebige Recherchen bezüglich der Tragweite von Altlasten „vor“ jeder Aufwandsschätzung zu betreiben. Refactoring muss ein fester Bestandteil jeder Planung und Entwicklung sein.

2.) Ein Refactoring-Team, um Altlasten successive zu entfernen
Je nachdem wie stark die Belastung durch Altlasten erscheint, ist es sinnvoll ein Team zusammenzustellen, welches sich ausschließlich um diese kümmert. Es gibt viele Entwickler, die sich diesem Thema sehr gerne annehmen. Ein großer Mehrwert für jede Firma.

3.) Fortlaufendes Refactoring
Entwickler müssen für dieses Thema allgemein sensibilisiert werden, damit sie während der Codierung Altlasten erkennen und diese gegebenenfalls „ad hoc“ beseitigen können. Dieses ist sehr wichtig, aber auch nicht ungefährlich. Daher muss klar definiert sein, welche Altlasten ohne Aufzeigen entfernt werden dürfen und welche erst nach Absprache. Hinzu kommt, dass Entwickler bei jedem Projekt eine fest zugesicherte Zeit für Refactorings erhalten müssen.

4.) Altlasten dokumentieren
Meist reicht hier ein kleiner Bereich im Intranet, um dort auffallende Altlasten festzuhalten, damit sie in spätere Release-Planungen einbezogen werden können.

Ist das nicht etwas übertrieben?

Keines Falls. Wer sich zu spät um dieses Thema kümmert, riskiert es teure Entwicklungszeit zu verschwenden. Ich habe unerlässliche Refactorings mitbekommen, bei denen ein kompletter Release-Zyklus damit belastet wurde. Das ist wirtschaftlich natürlich katastrophal und es gilt dieses, im Vorfeld zu vermeiden.