Der Fluch der Wiederverwendung

Wiederverwendung ist der Fluch des modernen Software-Designs.
Nicht die Wiederverwendung, die man entdeckt, weil es sich so ergibt.
Sondern die geplante Wiederverwendung – oder, besser beschrieben, die geforderte Wiederverwendbarkeit.

In Lastenheften lese ich sehr häufig die nicht-funktionale Anforderung der Wiederverwendbarkeit.
Sofern ich Einfluss darauf habe, lasse ich diese Anforderung streichen, denn sie ist praktisch nicht zu erfüllen.
Eine nicht näher spezifizierte Wiederverwendbarkeit impliziert die Fähigkeit, mögliche Szenarien zur Wiederverwendung vorauszusehen.
Leider gibt es nur sehr wenige Menschen, möglicherweise gar keine, die mit der Gabe der Vorhersehung gesegnet sind, die jedoch dafür notwendig wäre.

Wozu führt eine solche Anforderung der Wiederverwendbarkeit?
Auf direktem Weg zu Technical Debt in Form von Over-Engineering.
Es werden große Aufwände investiert, um wiederverwendbare Komponenten zu designen, ohne dass konkrete funktionale Anforderungen existieren, die die Design-Entscheidungen unterstützen.
Unglücklicherweise übersieht man nach Murphys Gesetz genau den Fall, der dann im Sinne der Wiederverwendung eintreten wird.

In den letzten 15 Jahren ist mir kein Projekt begegnet, in dem verordnete Wiederverwendbarkeit per Design zu positivem Business Value geführt hätte.
Stattdessen zeigte sich: sinnvoller ist es, Lösungen maximal einfach zu implementieren.
Hilfreich ist dabei vor allem Test Driven Development und das Fokussieren aufs Wesentliche.

Wiederverwendbarkeit entsteht durch Refactoring, das Herauslösen gemeinsamer Abhängigkeiten und gemeinsamer Logik aus Softwareteilen mit einem konkreten Business Value.

Es ist eine Tatsache, dass Wiederverwendung Anpassungen erfordert.
Diese Tatsache kann man, so lange man nicht mit der Gabe der Vorhersehung gesegnet ist, nicht weg-designen.
Die Anpassungen sind aber um so leichter und günstiger, je einfacher das Design der Software (oder Komponente, Klasse…) ist, die wiederverwendet werden soll.

Das Fazit lautet: Erst mit Fachlichkeit einen konkreten Anwendungsfall für Wiederverwendung schaffen, danach die wiederverwendbaren Bestandteile mit Refactoring extrahieren.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.