Systemgesundheit - Wartbarkeit von Systemen - Refactorings

03.12.2015 Michael Mosmann

Systemgesundheit - Wartbarkeit von Systemen - Refactorings

In der Softwareentwicklung ist wenig Zeit für Refactorings. Wann sind sie aber notwendig und wie überzeuge ich als Entwickler das Management davon?

Du weißt, 's ist aller Los: Was lebt, muss sterben! Und Ew’ges nach der Zeitlichkeit erwerben..
-- William Shakespeare aus: Hamlet

Systemgesundheit Wartbarkeit Refactoring Wenn ein typisches Softwareprojekt startet, muss es meisten sehr schnell gehen. Allen Beteiligten ist klar, worum es geht und welches Ziel erreicht werden soll. Alle Anstrengungen steuern auf dieses Ziel zu, alles was davon ablenkt oder den Weg dorthin verlangsamt wird "wegdiskutiert".

Hat man das erste Ziel erreicht, dann ist auch schon das zweite im Blick. Wer hier "innehalten" möchte (z.B. Refactorings durchführen möchte, ungenutzte Features ausbauen will), der wird mit einem Verweis auf den Erfolg auf einen Zeitpunkt nach dem nächsten Ziel vertröstet. Aber auch wenn das erste Ziel nicht erreicht wurde, wird mit einem Verweis auf den Misserfolg argumentiert. Man kann sich die Aufräumarbeiten dann meist "nicht leisten".

Was ist Wartung? Was ist Wartbarkeit?

Wenn man die Definition im Duden heranzieht, dann bedeutet Wartung:

Durchführung von Arbeiten an einer technischen Anlage o. Ä., die der Erhaltung ihrer Funktionsfähigkeit dienen

In Anlehnung an Wikipedia kann man Wartbarkeit wie folgt beschreiben:

Wartbarkeit beschreibt die Einfachheit, mit der Änderungen an einem System vorgenommen werden können.

Wenn man nun betrachtet, wie Softwareprodukte entstehen und wachsen, muss man streng genommen feststellen, dass die Wartung sehr viel früher anfängt. Nicht beim Erreichen des ersten Ziels sollte man sich über Wartung und Wartbarkeit unterhalten, sondern mit der zweiten Funktion, die hinzugefügt wird. Denn zu diesem Zeitpunkt werden die ersten Arbeiten zur "Erhaltung der Funktionsfähigkeit" durchgeführt.

Big Ball of Mud

Die Qualität von Software kann man von außen selten gut beurteilen. Wenn man bei Software die Qualität und vor allem die Stellen sichtbar machen könnte, an denen unsauber gearbeitet wurde, dann würde man sicher sehr viel weniger Diskussionen darüber führen, ob man "mal was aufräumen muss". Metriken helfen da wenig, denn die Frage, die beantwortet werden muss ist folgende:

Wieviel muss man aufräumen, damit man wieder vernünftig arbeiten kann?

Niemand wird eine Tischlerei so lange und genau putzen, dass man darin Operationen durchführen könnte. Aber jedem wäre klar, dass man den Müll raus räumt, bevor man nicht mehr in den Raum kommt.

Small Ball of Mud

Das nachträgliche Aufräumen ist immer zu spät. Aber wenn es schon schwierig ist, in Verhandlung über Wartung und Wartbarkeit nach dem Erreichen des ersten Ziels zu treten, wie soll das dann weit davor besser funktionieren?

Vielleicht in dem man die richtigen Fragen stellt.

Wenn ein neues Feature hinzugefügt werden soll oder eine Anpassung an einer bestehenden Funktion durchgeführt werden soll, hat jeder der Beteiligten ein Gefühl dafür, wie lange das dauern wird. Wenn man diese Schätzungen wie z.B. in Scrum auch transparent macht, dann wird man feststellen, dass es meist kein eindeutigen Wert sondern vielmehr eine Spanne gibt, in dem sich die Schätzungen bewegen.

Und an dieser Stelle sollte man sich fragen, wie hoch der Aufwand für dieses Feature oder die Änderung sein sollte.

Ein Beispiel aus der Praxis: Als ich diese Fragestellung mit einem Kollegen diskutierte und ihm das Konzept erklärte, sagte ich, das man "z.B. eine klare Vorstellung davon hat, was das Hinzufügen eines Formularfeldes kosten darf." Seine Antwort kam prompt: "2 Stunden".

Nun muss man nur noch die tatsächlichen Aufwände dagegen halten und ausrechnen, wie viel höher der tatsächliche Aufwand ist.

Multiplikator

Nun hat man dem Bauchgefühl eine Zahl gegeben. Was nun?

Wenn die durchschnittliche Faktor bei den typischen Anforderungen so zwischen 1 und 2 schwankt, dann sieht das ganz gut aus. Vielleicht hat man ein Muster erkannt und festgestellt, dass bestimmte Anforderungen immer etwas länger dauern und das man das System vielleicht in eine neue Richtung drehen muss, weil diese Anforderungen am häufigsten vorkommen. Wenn man das System weiter im Auge behält, bekommt man ja mit, ob der Schwenk richtig und ausreichend war. Vielleicht sind die Ursachen auch an ganz anderen Stellen zu suchen (Infrastrukturprobleme, zu viel Organisationsoverhead, ...)

Wenn der Faktor die 2 deutlich übersteigt, wird es Zeit, über ein Refactoring zu verhandeln. Dieses Mal hat man vielleicht eine Zahl, mit der man in die Argumentation einsteigen kann: alle zukünftigen Aufwände reduzieren sich um den Faktor x. Und schon kann man a) errechnen, ob sich die Investition lohnt und b) kann man im Nachhinein ermitteln, ob man das Ziel erreicht hat.

Was man dabei nicht aus dem Auge verlieren sollte: die entwickelte Anwendung ist ein System im System. Manchmal muss man den Bogen weiter spannen und das Optimierungspotential hebt man mit einem Prozess- oder Organisationsrefactoring.

Alte Fehler, neue Fehler

Es gibt verschiedene Faktoren, die sich ungünstig auf die Systemgesundheit auswirken. In diesen Fällen sollte man ein besonderes Augenmerk darauf legen, wie sich der Multiplikator verändert:

Es gibt nicht genug Zeit, um sich in die verwendeten Technologien einzuarbeiten.
Man geht mit dem Prototyp in Produktion.
Der Softwarearchitekt entwickelt nicht mit.
Frameworks werden nicht als Verallgemeinerung von sich wiederholenden Anforderungen entwickelt, sondern werden von "unbeteiligten" Teams entworfen.
Es werden zu wenig Tests geschrieben.
Es wird zunehmend integrativ getestet.
Die Liste der gewünschten Funktionen wird länger.
Die Anzahl der gleichzeitig bearbeiteten Themen wird größer.
Das Team wird größer.
Die Deadlines werden zunehmend knapper erreicht oder gerissen.

Natürliche Softwareentwicklung

Zu schnelles Wachstum ist immer ein Problem. Wenn man ein Softwareprojekt als Organismus begreift, dann wird klar, dass ungezügeltes Wachstum ein Zeichen von Krankheit ist. Mit jedem neuen Feature gibt man seiner Schöpfung eine neue Fähigkeit. Aber mit jeder neuen Funktion schwächt man auch die Wirksamkeit der bestehenden. Ein Pinguin ist ein perfekter Schwimmer aber ein schlechter Läufer. Mit besseren Füßen wird er wahrscheinlich verhungern.

Man sollte vermeiden, dass aus der eigenen Schöpfung ein Monster wird.

nach oben