Endlich: ein Cheatsheet zu Flow Design!
Als ich gemeinsam mit Ralf Westphal Ende 2008 die Clean Code Developer Initiative gegründet habe, sind wir damit beim Thema innere Qualität von Software einen gewaltigen Schritt weiter gekommen. Plötzlich konnten wir auf Prinzipien und Praktiken verweisen, die alle unter einem Dach dokumentiert sind. Ferner hat das Kind nun einen Namen: Entwickler bezeichnen sich seit dem als Clean Code Developer um auszudrücken, dass sie es ernst meinen mit der Qualität von Softwareentwicklung.
Wandelbarkeit
Es kristallisierte sich schnell heraus, dass der Wert der Wandelbarkeit, anfangs sprachen wir von Evolvierbarkeit, völlig unterbelichtet ist. Das führt in vielen Teams zu einem massiven Legacy Code Problem. Der Code ist schon nach wenigen Wochen in einem Zustand, der flüssiges Ändern und Ergänzen verhindert. In den darauffolgenden Monaten und Jahren haben wir daher nicht aufgehört zu diskutieren, zu forschen und auszuprobieren. Wir haben für unsere Trainings der CCD School immer wieder nach neuen Wegen gesucht, um Entwicklern eine Vorgehensweise an die Hand zu geben, mit der sie „sauberen Code“ schreiben können. Die Prinzipien zu benennen, hier vor allem deren Verletzung, ist eine Sache. Eine andere Sache ist es, über eine Methodik zu verfügen, durch die wichtige Prinzipien leicht eingehalten werden können.
Flow Design
Das Ergebnis ist Flow Design. Damit bezeichnen wir unsere Methode. Sie besteht mit ihren Datenflussdiagrammen im Kern aus einer Methode zum Entwurf von Software. Darüber hinaus bietet die Methode konkrete Handlungsanweisungen dem Schneiden von Anforderungen (Domänenzerlegung), zum Umgang mit nicht-funktionalen Anforderungen (Hostsdimension) sowie natürlich zum Thema Wandelbarkeit (Containerdimension). Immer wieder werden wir in unseren Trainings nach Material zur Methode gefragt. Und immer wieder antworten wir, dass es diverse Blogbeiträge, Artikel, Büchlein und Beispiele gibt. Es gibt sogar die Website http://flow-design.info auf der wir begonnen haben, alles zu dokumentieren. Aber uns ist durchaus bewusst, dass es an Material fehlt.
Cheatsheet zu Flow Design
Heute schließe ich eine kleine Lücke: In den letzten Tagen habe ich ein Cheatsheet zu Flow Design erstellt. Sie finden es unter folgendem Link zum Download.
In diesem Cheatsheet sind alle Symbole unserer Entwurfsmethode aufgeführt. Ferner zeigt es die Übersetzung der Entwürfe in C#.
Feedback
Schreiben Sie mir unten in den Kommentaren gerne Ihr Feedback zum Cheatsheet. Fehlt etwas? Ist etwas missverständlich ausgedrückt? Haben Sie Anregungen oder Fragen? Jetzt ist die Gelegenheit dazu. Gerne pflege ich Ihre Anregungen in das Cheatsheet ein.
Hallo Stefan,
warum Zustandsbeschreibungen, wenn es um Flow/Prozess geht? Ich wäre jetzt davon ausgegangen, dass eine Beschreibung als „Side Effect“ ausreichen würde. Hast du dafür ein/zwei Beispiele?
BG, Mike
Hallo Mike,
jede Funktionseinheit kann Zustand tragen, ohne dass ich ihn zwingend kenntlich machen muss. Auch shared state über mehrere Funktionseinheiten hinweg ist „erlaubt“. Spätestens dann würde ich ihn im Diagramm kenntlich machen, da das Verständnis des Diagramms andernfalls leiden könnte.
Wenn ich einen Flow leichter verstehe durch das explizite Ergänzen von Zustand (sei es also Tonne an eine Funktionseinheit oder durch Get/Set in den Flow gestellt), dann sollte ich es tun. Wenn dir die Diagramme dann möglicherweise überladen erscheinen, auch gut, lass ihn einfach weg 😉
Wir wollen mit dem Cheatsheet lediglich die Möglichkeiten aufzeigen.
Grüße, Stefan
Super! Ist sicher sehr hilfreich.
Manche Notation kannte ich noch gar nicht, obwohl ich Euch doch regelmäßig folge. 🙂 Wahrscheinlich waren sie einfach noch nicht in öffentlichen Beispielen aufgetaucht.
Zwei Anregungen hätte ich:
Das Cheatsheet sollte in Englisch oder Deutsch sein, jetzt ist es irgendwie gemischt (Überschriften).
Die Kurznotation für Iterationen finde zu überladen. Der Gnubel mit dem Stern drin stört mich. Was haltet ihr davon einfach in der FU den Namen der Einzel-Element-FU in Klammern mit Stern zu schreiben? Also z.B. „(Convert to String)*“? Oder „[Convert to String]*“ um Assoziationen mit den Daten durch die runden Klammern zu vermeiden.
Hallo Denis,
Danke für dein Feedback! Das Deutsch/Englisch Durcheinander werde ich gleich beheben, Danke für den Hinweis!
Zur Iteration: ist „[Convert to String]*“ knapper formuliert, als einen Knubbel mit Sternchen an die Funktionseinheit zu stellen? Bin da nicht sicher, werde es mal ausprobieren. Danke für den Vorschlag!
Hallo Stefan,
A very useful cheatsheet indeed. Thank you for that.
As I find the coloring for threading difficult to write/draw, I have a simpler proposal.
How about just writing a slash through the arrow? Also makes it easy to indicate multiple threads, by writing multiple slashes.
For instance:
+—+ (x) +—+ (y) +—+
| A |——->| B |—-/—->| C |
+—+ +—+ +—+
|
| (z) +—+
+——//—–>| D |
+—+
Grüsse, Johan
Ich vermisse die Notation für eine „or“ Verknüpfung von zwei oder mehr Ausgängen. Wir haben einen Klassifier der .OnFröhlich / .OnTraurig / .OnUnbekannt liefert. Im Nachgang soll OnFröhlich ein true und OnTraurig ein false liefern und OnUnbekannt rekursiv arbeiten.
Hallo Stefan,
Tatsache, da fehlt was. Danke für den Hinweis!!
Wenn zwei oder mehr Datenflüsse zu einem zusammengeführt werden sollen, zeichnen wir dies einfach als zusammenlaufenden Fluss. Im Gegensatz zum Join, bei dem alle eingehenden Daten anliegen müssen, bevor es weitergehen kann, bedeutet dies dann eine Alternative: genau einer der Datenflüsse wird durchlaufen. Ich ergänze es im Cheatsheet (und im Buch).
Viele Grüße
Stefan Lieser
—