Eine frei übersetzte Kostprobe:
Der eigentliche Zweck von Software? Einem ganz bestimmten Zweck für Benutzer zu dienen. Doch zunächst einmal muss Software Programmierern dienen. Insbesonders, wenn es um Refactoring geht. Im Verlauf der Entwicklung eines Programms wird jedes seiner Teile irgendwann neu geschrieben, die Teile werden neu strukuriert, neu angeordnet, "Domain Objects" werden integriert, umgestaltet, mit vorhandenen verbunden oder wieder auseinandergenommen. Auch noch nach Jahren wird der Code geändert und erweitert. Menschen müssen an diesem Gebilde arbeiten. Frägt sich nur, ob sie das auch wollen?
Wenn etwas kompliziertere Software kein gutes Design hat, wird es nämlich unendlich schwierig sie umzubauen, Elemente neu zu kombinieren, ein "Refactoring" durchzuführen. Wenn ein Entwickler nicht mit gutem Gefühl die Auswirkungen einer Änderung einigermaßen abschätzen kann, wird er eine Funktionalität einfach nochmal programmieren, und so entsteht "Duplication". Sie entsteht auch, wenn ein Design zu große Blöcke enthält, zu monolithisch ist. Zwar kann man Klassen und Methoden mit dem Ziel besserer Wiederverwendbarkeit feiner aufbrechen, aber dann wird es oft schwierig zu verstehen, was all die kleinen Teile machen.
Eine Software ohne klares Design mögen sich Entwickler kaum anschauen, geschweige denn mögen sie Änderungen an dem Schlamassel vornehmen, die womöglich Fehler an anderer Stelle durch kaum durchschaubare Abhängigkeiten verursachen. Abgesehen von sehr, sehr kleinen Systemen verhindert diese Zerbrechlichkeit, dass Software ein bestimmtes Maß an Funktionalität überschreiten kann, sie verhindert Refactoring und schrittweise Verbesserungen.
Ein Projekt, das in seinem Verlauf Fahrt aufnehmen und Schwung entwickeln, und nicht unter seinem eigenen Gewicht zusammenbrechen soll, setzt voraus: Ein Design, mit dem es Freude macht zu arbeiten, ein Design, das zu Änderungen einlädt. Ein geschmeidiges Design.
Ja! Wunderbar! Geschmeidig muss es sein!
