Gezielte Software-Evolution

Der Unterschied zwischen der heutigen Wissenschaft der Software-Evolution als Teilgebiet der Informatik und der agilen Entwicklung besteht erst einmal darin, dass sich die Software-Evolution mit viel grösseren Zeitabschnitten beschäftigt und aus diesem Grund auch mit sehr lange laufenden Projekten befasst ist. Während also der agilen Software-Entwicklung das Feld der Neuentwicklung überlassen wurde, betrachtet die Software-Evolution, wie sich Entscheidungen während des Entwicklungsprozesses auf lange Sicht auswirken und wie man diesen Auswirkungen begegnen kann. Genau das macht sie sehr bedeutend, denn Entwickler neigen dazu, Software eher auf der Ebene von Quellcode-Zeilen zu betrachten. Die monetären Aspekte einzelner Tätigkeiten und Bestandteile sind ihnen häufig nicht direkt bewusst. Auf Unsauberkeiten innerhalb einzelner Klassen reagieren sie gern schnell und bereinigen unschönen Code in Windeseile. Doch der andere Blick auf die tatsächlichen Strukturen hinter einem solchen System, wie Subsystem-, Modul- oder Komponentensicht, ist seltener, wobei gerade diese es sind, die die Überlebensfähigkeit einer Software auf lange Sicht ausmachen.

Dies zeigt sich beispielsweise auch in einem grundsätz­lichen Missverständnis in Bezug auf Refaktorisierungen. Der Entwickler und Autor Martin Fowler schrieb schon 2004, dass seine ursprüngliche Absicht hinter dem Begriff „Refactoring“ eigentlich in lokal begrenzten Strukturanpassungen lag, die sich nicht auf das Verhalten der Software auswirken. Demnach sollte eine Refaktorisierung die Software nicht länger als zwei Minuten unbrauchbar machen.

Im Alltag wird Code aber immer wieder auch in grösserem Mass umstrukturiert, und dabei werden ganze Entwicklungsteams über Tage hinweg behindert. Im Englischen würde man von einem Restructuring sprechen.

Umstrukturierungen sind innerhalb von Software-Systemen nach einigen Monaten oder Jahren notwendig, um die natürlich gewachsenen Verflechtungen aufzubrechen und durch eine geplante Architektur zu ersetzen. Dazu muss die Architektur aber vor der Umstrukturierung auch wirklich geplant worden sein und darf sich nicht während des Vorgangs per Zufall ergeben. Ist sie jedoch ein Ergebnis des Zufalls, wird sie sich auf Dauer ebenfalls als ungünstig herausstellen. Das Missverständnis zwischen Refaktorisierung und Restrukturierung ist somit, dass Entwickler immer wieder meinen, sie würden nur eine kleine Änderung am Code vornehmen; tatsächlich rütteln sie dabei aber oft an den Grundfesten der Applikation, da sie sich nicht ausgiebig mit den tatsächlichen Zusammenhängen beschäftigt haben. Die Krux an dieser Situation ist, dass die Evolution von Software solcherlei Umstrukturierungen auf jeden Fall notwendig macht. Unkontrollierter Aktionismus jedoch ist nicht hilfreich.

Die Wissenschaft der Software-Evolution bietet hier Mittel und Wege zur Bewertung. Dazu gehören neben den viel beachteten Code- und Strukturmetriken auch Verfahren zum Umgestalten der Architektur und Möglichkeiten der Kosten-Nutzen-Analyse.

Letzteres mag verwundern, ist aber wichtig, da auch die Software-Entwicklung zum ökonomischen Handeln verpflichtet ist. Nur weil ich Code verändern kann und er mir in seinem jetzigen Zustand nicht gefällt, bedeutet dies noch lange nicht, dass es auch wirtschaftlich sinnvoll ist, ihn zu verändern. Aus diesem Grund hat sich das Ideal etabliert, dass Refaktorisierungen nie einzeln durchgeführt werden sollten. Vielmehr sollten sie immer in Kombination mit einem umzusetzenden Merkmal oder mit dem Beheben von Programmierfehlern verbunden werden. Auf diese Weise werden die strukturellen Anpassungen dann zu einem Teil der eigent­lichen Aufgabe (das neue Merkmal) und können besser eingearbeitet werden.

Das macht den Gesamtaufwand ökonomischer und relativiert ihn schon durch die Umsetzung der Aufgabe. Umstrukturierungen in grösserem Mass mit dem Ziel, technische Schulden grossflächig abzubauen, folgen im Grunde dem gleichen Muster. Sie können entweder erfolgen, wenn die Umsetzung neuer Merkmale ohne sie nur zu noch grösseren technischen Schulden führen würde oder wenn sie der Sanierung bestimmter Teilbereiche der Software vorangestellt werden können, was beispielsweise dann passiert, wenn das User Interface auf eine andere Technologie gehoben werden soll.