Voraussichtlicher Erscheinungstermin: September 2020
Die Softwareentwicklung braucht mehr Planung, wenn sie nachhaltig arbeiten will.
Davon bin ich überzeugt, auch wenn es sich anachronistisch und kontraproduktiv anhört. Dass der Wasserfall überwunden wurde, ist zweifellos gut. BDUF ist natürlich keine gute Sache - aber nicht wegen des D für Design, sondern wegen des B für Big. Leider scheint diese Feinheit aber unter die Räder des guten Willens von Agilität und Software Craftsmanship gekommen zu sein.
Die Kunst des Softwareentwurfs wird nicht gelehrt, ist mein Eindruck. Systematisch, greifbar, für andere nachvollziehbar über Software nachzudenken, steht nicht hoch im Kurs. Auf dem Zettel des Agilität ist das Gespräch über inkrementelle Anforderungen im Rahmen eines iterativen Vorgehens. Super! Auf dem Zettel der Software Craftsmen sind TDD und Prinzipien der Codegestaltung. Auch super! Nicht weniger braucht es für korrekten und sauberen Code. Bei aller Notwendigkeit halte ich das aber nicht für hinreichend.
Wer sich auch mit der besten Definition of Done sofort an TDD macht, wird über kurz oder lang den Code in die Ecke der Unwartbarkeit pinseln. Verständlichkeit und Wandelbarkeit kann man nicht (oder nur begrenzt) in Code "hineincodieren". Damit ist es wie mit der Korrektheit: die lässt sich auch nicht in Code "hineintesten".
Korrektheit hat Voraussetzungen schon in der Anforderungsanalyse und braucht eine konsequente test-first Disziplin beim Codieren. Verständlichkeit und Wandelbarkeit haben ihre Voraussetzungen gleichermaßen vor der Codierung und zwar in einem expliziten Entwurf. Think before Coding muss das Motto lauten. Ansonsten startet die Codierung mit einem zu unklaren Bild und geht durch zu viele Veränderungen, die den Code unsauber zurücklassen. Denn Refaktorisierungen werden gewöhnlich als zu aufwändig angesehen; es muss ja weitergehen mit dem nächsten Issue, wenn eines erfolgreich codiert wurde. Und wohin auch refaktorisieren? Wie sieht eine saubere Struktur eigentlich aus?
Ordnung als Grundlage für langfristig hohe Produktivität musst du also planen. Du musst ein Modell deines Codes entwerfen, das du in der Codierung fast schon mechanisch umsetzt. Ja, das meine ich so: Codierung ist nach einem guten Entwurf fast langweilig. Die Lösung kennst du ja schon. Die Spannung ist dann raus aus der Softwareentwicklung, zumindest eine gewisse kreative Spannung.
Das Modell ist noch nicht der Code. Seine Beschreibung musst du also in einer anderen formalen Weise vornehmen als mit einer Programmiersprache.
Und das Modell ist schon mehr als der Lösungsansatz. Der geht dem Modell voraus und umreißt, wie du dir "ganz informell" eine Lösung ausmalst.
Denn um ein Ausmalen geht es, um Visualisierung. Für mich bedeutet Softwareentwurf visuelle Softwareentwicklung. Mit UML ist dieser Gedanke auch schon einmal verbreitet worden - nur hat UML keine Akzeptanz in der Praxis gefunden. 90% der Entwickler nutzen UML nicht. Visuellen Entwurf deshalb als gescheitert anzusehen, hieße jedoch, das Kind mit dem Bade auszuschütten. Für mich liegt der pragmatische Weg in der Mitte: Wir brauchen einen leichtgewichtigen, visuellen Entwurf. Wir brauchen eine alltagstaugliche Entwurfsmethode. Genau die möchte ich dir in diesem Buch vermitteln.
Der Softwareentwurf ist für mich die mittlere von drei Phasen, in denen du Anforderungen in hochqualitativen Code transformierst. Sie ist für mich sogar die wichtigste, weil im Entwurf das anliegende Problem grundsätzlich gelöst wird. Hier ist deine ganze Kreativität und Erfahrung gefragt. Du musst die Domäne verstehen und dein Codierungshandwerkszeug beherrschen. Beim Entwurf schreibst du zwar keinen Code, doch er kann deshalb nicht unabhängig von den Einschränkungen stattfinden, die dir Code auferlegt. Entwurf muss durch technische Kompetenz informiert werden.
Deshalb ist es mir auch sehr wichtig, dass eine Entwurfsmethode leichtgewichtig ist. Nur dann hast du genug Motivation, sie zusätzlich zu deiner Codierkompetenz zu lernen.
Und mir ist wichtig, dass du als jemand mit Codierkompetenz entwerfen lernst, weil dann sichergestellt ist, dass der so wichtige Entwurf nicht im luftleeren Raum entsteht. Entwürfe von "Astronautenarchitekten" sind nicht praxistauglich und haben der Disziplin Entwurf einige Imageschaden zugefügt.
Entwurf ist natürlich etwas anderes als Codierung. Das muss er sein, sonst würde er nichts bringen. Er ist zum Beispiel deklarativ und nicht imperativ. Dennoch glaube ich daran, dass es nicht zu schwer ist, dass du dir diese Kunst aneignest. Oder noch besser: Dein ganzes Team sollte das visuelle Entwerfen lernen. Denn mit einem visuellen Entwurf kann man im Team viel unaufwändiger und schneller Lösungsalternativen durchspielen oder überhaupt Lösungen kommunizieren.
Entwurf ist dabei zu unterscheiden von Dokumentation! Entwurf findet vor der Codierung statt. Ein visueller Entwurf nimmt Codestrukturen vorweg. Dokumentation hingegen findet nach der Codierung statt. Dafür wird UML durchaus gern benutzt - nur ist das etwas ganz anderes, als worum es in diesem Buch geht.
Du wirst hier deshalb auch keine sauberen Zeichnungen sehen. UML-Tools oder auch nur Visio benutze ich nicht und rate dir nicht, danach zu schielen. Pragmatischer Entwurf findet mit Handzeichnungen statt. Das ist ein Aspekt seiner Leichtgewichtigkeit. Sobald du mit dem "Reinzeichnen" anfängst, geht Spontaneität verloren und bekommt ein Entwurf zu viel Gewicht.
Selbstverständlich ist ein Entwurf ein Plan. Doch den darfst du nicht missverstehen als "in Stein gemeißelt". Der Plan soll dich schneller machen bei der Codierung, weil einfach so eine Menge Entscheidungen getroffen wurden, als du noch nicht unter Codierungsstress gestanden hast. Doch letztlich kannst du auch vom Plan abweichen, wenn du während der folgenden Phase neue Erkenntnisse gewinnst.
Aus der "Handschriftlichkeit" des Entwurfs folgt auch, dass er für sich genommen nur schwer zu verstehen ist. Ein Entwurf wie ich ihn meine, lebt vom Diskurs. Du kannst einen Entwurf allein anfertigen und bist damit dann vertraut. Besser allerdings, wenn du einen Entwurf im Pair oder Team gemeinsam erarbeitest. Er ist dann für alle in gleicher Weise verständlich.
Dass ein solcher Entwurf anschließend einem Dritten aber "über den Zaun geworfen" werden kann, damit er dort umgesetzt wird, halte ich für ein Missverständnis. Ein Entwurf braucht mindestens die lebendige Erklärung. Der Betrachter muss ihn sich aktiv aneignen - am besten im Dialog.
Und wie wird Software nun entworfen? Was visualisiert der ominöse Entwurf? An dieser Stelle nur kurz: vor allem Datenflüsse. Datenflüsse und Module sind für mich die default Bestandteile eines pragmatisch-praktischen, leichtgewichtigen Entwurfs. Meine Gründe dafür lege ich dir ausführlich im Buch dar. Auch wenn dir das gerade noch nicht plausibel sein mag, steht das überhaupt nicht im Widerspruch zu Objektorientierung. Im Gegenteil! Ich nehme die Objektorientierung sehr ernst, genauso wie die Funktionale Programmierung. An die wird dich auch einiges im Buch gemahnen. Deshalb ist es aber noch lange kein Buch, mit dem ich dich zur Funktionalen Programmierung bringen will. Mein Ansatz ist eklektisch: Ich benutze das mir sinnvoll Erscheinende aus beiden Welten.
Wesentliches Merkmal solchen Entwurfs ist, dass er sich leicht, geradezu mechanisch in Code transformieren lässt. Das ist mir sehr wichtig. Die visuellen Beispiele im Buch unterlege ich deshalb auch immer mit Code. Sonst glaubst du mir nicht, dass ein solcher Entwurf praktikabel ist. Bubbles don't crash ist mir auch bekannt. Deshalb muss ich dir glaubhaft machen, dass dennoch bubbles ihren Sinn haben.
Was erwartet dich konkret in diesem Band? Ich habe meine Vorstellung von einem visuellen Entwurf in mehrere Lektionen/Kapitel eingeteilt, die ich auch in Trainings vermittle. Schau dir einfach mal das Inhaltsverzeichnis an. Jedes Kapitel besteht aus einem Erklärungsteil und Übungsaufgaben. Der Text ist mit vielen Abbildungen und Code aufgelockert. Insgesamt sollte das Buch dir ca. 8+ Stunden Lesespaß geben. Und zur Bearbeitung der Übungsaufgaben kannst du auch nochmal 12-16 Stunden rechnen. Das meine ich nicht zur Abschreckung, sondern will dir zeigen, dass du hier einiges Material hast, um dich als Software Craftsman solide mit der Thematik Clean Code Development auseinander zu setzen - auch wenn ich dich hier ein wenig vom reinen Codieren abbringen will. Das Buch ist ernsthafte Lektüre für deine Weiterbildung.
Schau dir am besten einmal die Probekapitel an; oder stelle Fragen in der Community zum Buch und rund um Clean Code Development. Dann bist du hoffentlich entschlossen, es damit zu versuchen: für mehr Verständlichkeit und Wandelbarkeit in deiner Software.
Ich wünsche dir viel Freude bei der Programmierung!
-Ralf Westphal, info@ralfw.de
Ver. 1.1.0.20210416
