Supple Design / "Geschmeidiges" Design

Wunderschöne Sätze in dem Buch von Eric Evans: Domain-Driven Design: Tackling Complexity in the Heart of Software gefunden. In Kapitel 10 geht es um "Supple Design". Und was heißt "supple" überhaupt? Aha, LEO D-E Ergebnisse für "supple": geschmeidig, gefügig, biegsam!

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!

DesignStaminaHypothesis

In einem Blogbeitrag von Martin Fowler zu MF Bliki: DesignStaminaHypothesis folgende schöne Graphik gesehen:

die ich so oder ähnlich auch schon hie und da an die ein oder andere Tafel gemalt hatte. Meine Erklärung in etwa:

Wenn man am Anfang huddelt (wie schreibt man huddelt? hudelt?) kann man zwar schneller etwas vorweisen, später rächt sich dies allerdings, die Kurve wird immer flacher, d.h. für jedes bisschen mehr Funktionalität muss man immer mehr Zeit (und Energie) aufwenden: Die blaue Kurve. Im Extremfall erreicht die Kurve früher oder später eine waagrechte Asymptote, d.h. egal wie viel Zeit man investiert, man erreicht keine substantiellen Verbesserungen mehr. Stillstand auf hohem Niveau: Zwei Fehler beseitigt, dafür zwei neue verursacht.

Die andere Vorgehensweise wäre, zunächst Grundlagen zu legen, Architekturfragen zu klären, "ordentlich" vorgehen, usw.., d.h. dass man am Anfang erstmal sehr wenig sieht, später aber immer schneller mehr Ergebnisse produzieren kann: Siehe die rote Kurve.

Irgendwo mittendrin schneiden sich die Kurven, bis zu diesem Zeitpunkt kommt man letztendlich mit der blauen Kurve besser weg, ab da allerdings klar mit der roten.

Wie drückt das Martin Fowler aus?

Design activities certainly do take up time and effort, but they payoff because they make it easier to evolve the software into the future. You can save short-term time by neglecting design, but this accumulates TechnicalDebt which will slow your productivity later. Putting effort into to the design of your software improves the stamina of your project, allowing you to go faster for longer.

Was eigentlich nicht vorkommt ist, dass sich der Prozess linear verhält: So wie man beispielsweise einen Graben gräbt. Halber Tag = 5 Meter, 5 Tage = 50 Meter.

Einem EDV-Profi mag das klar sein, einem EDV-Laien nicht unbedingt. Der würde sich vielleicht folgende Gedanken machen und Fragen stellen:

Blaue Kurve: Sie waren doch letztens schon so weit, und jetzt soll es doch noch so lange dauern? Sie waren doch letztens schon fast fertig?
Rote Kurve: Na, wie läufts? Oh, man sieht quasi noch gar nichts? Oder fast gar nichts? Wie wollen Sie da bis nächste Woche/Monat/Freitag/xxx fertig werden?

Und was Stamina auf Deutsch heißt, könnte man auch mal eruieren...

Big Ball of Mud / 7

Na, ein kleines Zitat aus Big Ball of Mud geht noch, oder? Ist auch ganz kurz:

Das rituelle Zurschaustellen von "Cleverness" verbessert oft den Rang in der Programmierer-"Hackordnung" eher als handwerkliche Merkmale wie Einfachheit oder Klarheit. Und so gedeiht das, was glorifiziert wird.

Alles klar?

Meine erste C# Windows Applikation!

Weiß nicht, wie ich da heute draufgekommen bin, vielleicht weil hier so lustig stand:

Lernen Sie, wie Visual Studio Express Editions Ihnen helfen können, Spaß bringende, coole Projekte zu erstellen, die Sie auf Ihrem Windows Desktopclient ausführen können.

Ja, ja, "Ihnen helfen können"! Wie war das: Da wird Ihnen geholfen? Aber das macht einen schon ein wenig heiß: "Spaß bringend", "coole Projekte".... Also, runtergeladen, installiert, gestartet, und dann noch in der Hilfe das gefunden: "How to: Build a C# Application in 60 Seconds", und schon war das Windows Forms Hello World fertig:

private void button1_Click(object sender, EventArgs e)
{
   label1.Text = "Hello, World!";
}
Supercool, oder?

Big Ball of Mud / 6

Nachtrag zu Big Ball of Mud / 5: Lt. eines englischen Muttersprachlers ist "the most complicated system that can possibly work" sowas wie "das komplizierteste System, das gerade noch funktioniert", was auch irgendwie Sinn macht.

Und gleich weiter, die nächsten schönen Zitate:

Solche Programme können eine persönliche Festung werden, die zwar selbst der Autor kaum noch verstehen kann, jeder andere aber noch viel, viel weniger. Und sobald simple Reparaturen am Programm Tagesbeschäftigungen werden, verwandelt sich das Programm in einen Sumpf. Es wird für das Management zunehmend schwierig vorherzusagen, wie lange diese Reparaturen eigentlich dauern sollten. Dinge, die simpel zu bewerkstelligen sein sollten, ähneln eher einem nicht enden wollenden Schützengrabengefecht. Alle müssen sich in dieses absurde Tempo fügen. Manche finden sogar Gefallen daran, verstecken sich in ihren gemütlichen Höhlen, und machen ihre "Zwei-Zeilen-pro-Tag"-Reparaturen.

Big Ball of Mud / 5

Systeme werden rasch komplizierter, allerdings nur bis zu einem gewissen Punkt:

Die Antriebskräfte für die Evolution solcher System sind bisweilen pervers. So wie es einfacher ist geschwätzig zu sein, als präzise, ist es leichter komplexe Systeme zu schaffen als einfache. Dafür begabte Programmierer können Komplexität schneller schaffen als ihre Kollegen, und schneller als sie sie dokumentieren und erklären können. Und so wie eine Armee ihren Logistikzug abhängt, steigert sich die Komplexität bis zu dem Punkt, wo dieselben Programmierer gerade nicht mehr damit klar kommen.

Dies wird manchmal auch als "Peter Prinzip" der Programmierung bezeichnet. Komplexität steigert sich schnell bis zu einem Grad, an dem Programmierer gerade nicht mehr damit zurecht kommen. An diesem Punkt geraten Komplexität und unsere Fähigkeiten in ein ungutes Gleichgewicht. Der Blitzkrieg verwandelt sich in eine Niederlage. Wir schufen das komplizierte System, das gerade noch funktionieren kann.

Mann, da ist noch viel verbesserungswürdig! Wie sagt man auf gut Deutsch: Das komplizierteste System, das "can possibly work". Das womöglich funktionieren könnte?

Big Ball of Mud / 4

Und noch etwas aus dem Big Ball of Mud-"Pattern":

Und letztendlich unterscheiden sich Programmierer in ihren Fähigkeiten und ihrem Engagement für Architektur. Leider wurde Programmarchitektur so lange gering geschätzt, dass viele Programmierer den Big Ball of Mud als Normalfall ansehen. Manche Programmierer sind auch besonders begabt sich in diesen Sümpfen zurecht zu finden und andere durch sie zu führen. Irgendwann kann die Symbiose zwischen Programmarchitektur und Fähigkeiten das Wesen einer Organisation selber verändern, und Sumpfführer wertvoller als Programmarchitekten werden. Undurchschaubarer Code kann dann sogar einen echten Wettbewerbsvorteil für die bringen, die sich in dem Kladeradatsch noch zurecht finden. In einem Land ohne Grenzsteine, ohne Markierungen werden solche Führer überlebenswichtig.