Softwareentwurf – Mit Flow Design zu Clean Code
No Big Design Upfront
Softwaresysteme sind heutzutage recht komplexe Gebilde. Bei der Entwicklung einfach drauf los zu programmieren, führt schnell zu Problemen: man versteht seinen eigenen Code nicht mehr. Nur Code, der nach den Clean Code Developer Prinzipien erstellt wurde, versetzt Entwickler in die Lage, die Software langfristig weiter zu entwickeln. Die Anforderungen heutiger Softwaresysteme können nur mit ordentlicher Planung umgesetzt werden. Das bedeutet, eine Lösung muss entworfen werden, bevor man an deren Umsetzung gehen kann. Die Clean Code Prinzipien sind fundamental. Doch es bleibt immer die Frage, wie man zu einer Idee gelangt, den Code so aufzubauen, dass die Prinzipien eingehalten sind.
Damit es nicht zurück in den Wasserfall geht, wo wir versucht haben, alles im voraus zu planen, ist eine leichtgewichtige Methodik erforderlich. Der Entwurf muss agil und somit iterativ und inkrementell erfolgen. Genau das leistet Flow Design. In jeder einzelnen Iteration wird ein kleiner Ausschnitt des Systems entworfen und anschließend umgesetzt. Damit passt Flow Design ganz wunderbar zur Empfehlung: No Big Design Upfront.
Flow Design
Die Notation ist einfach und besteht nur aus wenigen Symbolen. Entwickelt wurde Flow Design von Ralf Westphal und Stefan Lieser. Die Vorgehensweise ist unabhängig von einer konkreten Programmiersprache. Insbesondere ist sie nicht auf funktionale Programmierung ausgelegt, Das Ziel bei der Entwicklung von Flow Design war es, eine einfache Diagrammart zu definieren, mit der der Entwurf von Lösungen schnell von der Hand geht.
Die Basis eines Entwurfs mit Flow Design sind Funktionseinheiten. In der späteren Implementation werden diese als Methoden bzw. Klassen umgesetzt. Die Kernidee von Flow Design liegt darin, Funktionseinheiten zu definieren und herauszuarbeiten, welche Datenflüsse diese verbinden. Es ist also eine bottom-up Vorgehensweise, bei der wir erst darüber nachdenken, welche Schritte erforderlich sind, um ein Problem zu lösen. Daraus entstehen die Funktionseinheiten sowie die verbindenden Datenflüsse. Erst kurz vor der Implementation überlegen wir, ob und wie wir Methoden zu Klassen bzw. Dateien zusammenfassen.
Im weiteren Verlauf verwende ich nur noch den Begriff Klasse. In Programmiersprachen oder Paradigmen in denen diese nicht erforderlich sind, müssen Methoden mindestens in Dateien zusammengefasst werden. Insofern steht hier Klasse auch synonym für Datei.
Die Kernidee von Flow Design liegt darin, Funktionseinheiten zu definieren und herauszuarbeiten, welche Datenflüsse diese verbinden.
Mit Flow Design zu Clean Code
Schon durch das gezielte Nachdenken über eine Lösung vor deren Umsetzung wird die Codequalität steigen. Und gleichzeitig können wir beobachten, dass es einen deutlichen Unterschied zwischen top-down und bottom-up Vorgehensweisen gibt. Verwendet man bspw. UML in der üblichen top-down Methodik, beginnt man mit einem Klassendiagramm. Doch wie soll ich ernsthaft auf gute Klassenkandidaten kommen, ohne zu wissen, welche Arbeitsschritte im Einzelnen erforderlich sind, um das anstehende Problem zu lösen? Geht man dagegen bottom-up vor und denkt erst über die einzelnen Schritte nach, ergibt sich die Struktur auf sehr natürliche Weise quasi von alleine. Jetzt kann nämlich gezielt entschieden werden, ob Methoden eine so hohe Kohäsion haben, dass sie sinnvoll in einer gemeinsamen Klasse aufgehoben sind. Es entsteht so eine Klassenstruktur, die von vornherein auf Kohäsion und damit das Single Responsibility Principle (SRP) ausgelegt ist. Des weiteren entstehen so Klassen, von denen definitiv klar ist, dass sie tatsächlich benötigt werden. Beim top-down Vorgehen muss man im Trüben fischen, weil noch nicht klar ist, welche Funktionalität im einzelnen erforderlich ist. Denkt man erst über die Funktionalität nach, fällt es leichter, die Struktur zu entdecken.
Abhängigkeiten
Eine weitere Herausforderung bei einer top-down Vorgehensweise liegt in der Abhängigkeitsstruktur. Nicht nur, dass es schwer fällt, überhaupt auf gute Kandidaten für Klassen zu kommen, müssen diese auch noch in eine Struktur gepackt werden. Da zu diesem Zeitpunkt die Lösung für das anstehende Problem noch nicht wirklich durchdrungen ist, entstehen Codestrukturen, die sich bei der späteren Implementation oft als schwierig herausstellen. Und das liegt primär an den Abhängigkeiten zwischen den Klassen.
In der Softwareentwicklung stellen Abhängigkeiten eines der Hauptprobleme dar. Sind die Abhängigkeiten nicht gut gewählt, entstehen große Herausforderungen beim automatisierten Testen. Häufig geht dann quasi gar nichts mehr, oder es kommen Attrappen zum Einsatz und die Tests sind umfangreich formuliert und schwer verständlich.
Das Dependency Inversion Principle (DIP) bietet hier eine erste Lösung. Mit dem Integration Operation Segregation Principle (IOSP) steht eine Weiterentwicklung mit vielen Vorteilen zur Verfügung. Im Detail habe ich darüber an anderer Stelle geschrieben und möchte mich hier nicht wiederholen. Hinweisen möchte ich aber darauf, dass der Entwurf mit Flow Design ganz natürlich zu Strukturen führt, die das IOSP einhalten. Ergebnis eines solchen Entwurfs ist also eine optimale Struktur von Abhängigkeiten: leichte Testbarkeit und gute Lesbarkeit werden problemlos erreicht.
Der Entwurf mit Flow Design sorgt im Sinne des IOSP dafür, dass die Methoden Logik enthalten, die im Entwurf nicht mehr weiter verfeinert wurden. Gleichzeitig rufen diese Methoden keine weiteren Methoden der Lösung auf, so dass sie im Sinne des IOSP als Operation bezeichnet werden können. Funktionseinheiten die im Entwurf verfeinert wurden, enthalten dagegen keine Logik. Ihre Aufgabe liegt darin, den Datenfluss herzustellen, der sich aus der Verfeinerung ergibt. Hier liegen also Methoden vor, deren Aufgabe die Integration ist. So ergibt sich die Einhaltung des IOSP ganz natürlich aus dem Entwurf. Man spart sich zahlreiche Refaktorisierungen, weil man vorher nachgedacht hat. Die Codestruktur ist dadurch leicht verständlich und gut testbar. Nach dem Entwurf einer Lösung geht das Codieren flott von der Hand, da Klassen und Methoden sowie deren Zusammenwirken bereits aus dem Entwurf entstanden sind.
TDD ist tot – Entwurf vielleicht auch
Test Driven Development ist meiner Einschätzung nach völlig überholt. Kent Beck hat sein Buch über TDD Ende 2002 veröffentlicht. Die Idee, ein Programm erst zu testen, bevor man es implementiert, klingt schlau. Doch schnell zeigte sich, dass aus TDD alleine eben keine optimalen Softwarestrukturen entstehen. Für überschaubare Probleme mag der Ansatz funktionieren. Eine ganze Anwendung damit auf die Beine zu stellen, ist nicht möglich.
Aktuell entsteht durch ChatGPT und andere KIs noch eine ganz andere Herausforderung: wenn wir als Entwickler die Tests vorgeben, kann die KI die Implementation liefern. Niemand muss diesen generierten Code lesen, verstehen und ändern. So lange die Tests grün sind, ist alles ok. Bei neuen Anforderungen werden entsprechende Tests ergänzt und der Code durch die KI neu generiert. Man kann dies als Test-first bezeichnen mit dem Unterschied, dass die Umsetzung durch die KI statt Entwickler erfolgt.
Was die KI für den Entwurf bedeutet, lässt sich meiner Einschätzung nach noch nicht absehen. Möglicherweise wird zukünftig auch der Entwurf überflüssig, wenn wir es schaffen, der KI die Anforderungen und die zugehörigen Tests klar zu machen und daraus der Code generiert wird. So lange Entwickler den Großteil der Implementation vornehmen oder zumindest für die Struktur sorgen müssen, geht am Entwurf kein Weg vorbei.
Ein Beispiel
Unser klassisches Beispiel eines CSV Viewers findest Du auf der Flow Design Website.
Fazit
Mit Flow Design steht eine leichtgewichtige Entwurfsmethode zur Verfügung. Wer sich mit der UML schwer getan hat, sollte Flow Design dringend ausprobieren. Einen guten Überblick über die Vorgehensweise findest Du im Einführungskapitel meines Buchs „Mit Flow Design zu Clean Code„. Gerne lasse ich Dir das Einführungskapitel zukommen. Um mit der Vorgehensweise vertraut zu werden ist es hilfreich, einmal eine unserer Übungsaufgaben mit einem Flow Design Entwurf zu lösen.
Erhalte einen Auszug aus dem Buch „Mit Flow Design zu Clean Code“.
German 
English