Antwort: „It is all design – really?“

In seinem Blogpost „It is all design – really?“ argumentiert Ralf Westphal, dass Quellcode etwas Konkretes ist, aber der eigentliche Entwurf in einer höheren Abstraktionsebene geschehen soll. Als Lösung wird Flow-Based-Entwicklung dargestellt.

Ich stehe dem Post kritisch gegenüber:

1: Softwareentwürfe sind sehr unterschiedlich und auch wenn ich klare Präferenzen für Flow-Based habe, scheinen mir verschiedenste Entwurfstechniken und Vorgehensweisen nützlich zu sein. Die Bandbreite geht hier von Anforderungsbeschreibung in Word, mit wenigen Illustrationen, bis hin zum vollständigen Entwurf in UML.

Am häufigsten genutzt zu werden und am effektivsten scheint mir eine Mischform, die in verschiedenen Projektphasen für verschiedene Zielgruppen verschiedenste Artefakte erzeugt: Word-Dokumente, unterschiedliche Diagrammtypen, ausführbare Spezifikationen. Das Entwurfsvorgehen passt sich an die Projekteigenschaften an.

2: Entwurf kann sehr wohl im Quelltext geschehen. Hierum geht es ja gerade in TDD, das von Kent Beck als Entwurfstechnik beschrieben wird. Die TDD-Idee, in der Tests die Entwicklung tatsächlich treiben, muss man nicht mögen, aber sie sollte auch keine Zielscheibe sein. Es ist durchaus pragmatisch, innerhalb eines Arbeitstages ein Teilproblem vormittags Flow-Based zu modellieren und zu implementieren und nachmittags eine  API testgetrieben  zu modellieren und implementieren.

3: Interne DSL als Entwurfstechnik möchte ich nicht so schnell abtun. Auch Flow-Based hat das Potential, mit DSLs betrieben zu werden. Warum sollen (einfache) Prozesse nicht gleich in der IDE textuell beschrieben sein? Für einige Anwendungsfälle sehe ich hier großes Potential. Kommt die DSL als Bibliothek, stellt sich das auch nicht mehr als: Meta-DSL(DSL(C#(IL-Code(Maschinencode)))) dar, sondern als C# (Maschinencode).

Zusammenfassung:

Soll es über der Implementierung weitere Entwurfsabstraktionsebenen gebenl? Ohne Frage! (Auch Robert Martin sieht das vermutlich nicht anders.) Dass Denken, Entwerfen, Modellieren, Implementieren in Prozessen (Flow-Based, flußorientiert, etc.) ein natürlicher und einfacher Weg für die Herangehensweise an Softwareentwicklung ist, diese Ansicht Teile ich auch – aber warum kann Flow-Based sich nicht einfügen, mitmachen und Teil eines Ökosystems von Denkideen sein? Warum wird UML nicht also ein Werkzeug unter vielen akzeptiert? Warum muss man sich von der TDD-Perspektive, die Robert Martin vertritt, abgrenzen? Warum kann nicht das eine oder andere OOAD-Konzept Flow-Based ergänzen? Hier würde ich mir mehr Offenheit wünschen und auch eine Perspektive, die einer Koexistenz von eingeführten Ideen und Flow-Based wohlwollend und positiv gegenübersteht, sodass auch individuelle inkrementelle Veränderung unterstützt und begünstigt wird.