Softwareentwurf mit Flow-Design
$17.50
Mindestpreis
$24.50
Empfohlener Preis

Softwareentwurf mit Flow-Design

Programming with Ease - Teil 2

Über das Buch

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

Über den Autor

ralfw
Ralf Westphal

Ralf Westphal is a freelance consultant, project coach, trainer, author, and speaker on concepts and methods to increase longterm productivity in software development. He is also the co-founder of the German "Clean Code Developer" initiative for higher software quality.

Ralf is based in Bansko, Bulgaria. Visit his homepage at www.ralfw.de for information on regular in-depth online trainings and consulting regarding sustainable software development.

Inhaltsverzeichnis

  •  
    • Zum Geleit
    • Motivation
      • Programming with Ease
      • Das Softwareuniversum
    • Einleitung
      • Anforderungskategorien
      • It’s the productivity, stupid!
      • Produktivitätskiller
        • Fehlende Korrekheit
        • Fehlender Wert
        • Fehlende Ordnung
      • Zusammenfassung
  • Die Methode
    • 01 - Die Anforderung-Logik Lücke
      • Logik - Der Stoff aus dem Verhalten entsteht
        • Funktionalität
        • Effizienz I - Effizienz durch Algorithmen und Datenstrukturen
        • Effizienz II - Effizienz durch Verteilung
        • Zusammenfassung
      • Von den Anforderungen zur Logik
        • Logik schwer definierbar
        • Die Phasen der Programmierung
        • Zusammenfassung
      • Übungsaufgaben
    • 02 - Entwurf im Überblick
      • Den Entwurf abstecken
        • Hierarchie der Lösungen
        • Von der Kunst lernen
        • Entwerfen ist fachgerecht
        • Entwerfen ist agil
      • 1. Der Lösungsansatz
      • 2. Das Modell
        • Modellarten
        • Abstraktion
      • Zusammenfassung
      • Übungsaufgaben
        • Aufgabe - Lösungsansatz finden
    • 03 - Radikale Objektorientierung
      • Die Welt bestehend aus Objekten?
      • Der Ursprung der Objektorientierung
        • Wer hat’s erfunden?
        • Die zentrale Analogie der radikalen Objektorientierung
      • Principle of Mutual Oblivion (PoMO)
        • Unabhängigkeit
        • Geschlossenheit
        • Unidirektionalität
        • Ein Prinzip als Destillat
        • Implementationsidee
      • Integration Operation Segregation Principle (IOSP)
        • Objekte verbinden als Verantwortlichkeit
        • Ein Prinzip als Destillat
        • Implementationsidee
      • Philosophischer Exkurs
      • Übungsaufgaben
        • Aufgabe - Mit PoMO/IOSP implementieren
    • 04 - Flow-Design mit 1-dimensionalen Datenflüssen
      • 0-dimensionale Datenflüsse
        • Notation
        • Implementation
      • 1-dimensionale Datenflüsse
        • Der Datenfluss als Scope
        • Fließende Mengen
        • Implementation
      • Übungsaufgaben
    • 05 - Flow-Design mit 2-dimensionalen Datenflüssen
      • Abstraktion durch Komposition
        • Stratified Design
        • 2-dimensionale Datenflüsse
      • Notation
        • Datenflüsse als aufgemotzte Abhängigkeitsdiagramme
        • n:1 Übersetzungen
        • Rekursion
      • Reflexion
      • Übungsaufgaben
    • 06 - Flow-Design mit modularisierten Datenflüssen
      • Abstraktion durch Aggregation
        • Physisch kategorisieren mit dem Dateisystem
      • Module
        • Abhängigkeiten
        • Orthogonale Containerdimension
      • Die Modul-Hierarchie
        • Klasse - Abhängigkeiten mit Kontrakten zähmen
        • Namensraum - Kontraktkollisionen vermeiden
        • Bibliothek - Wiederverwendbarkeit ermöglichen
        • Paket - Abhängigkeiten stabilisieren
        • Komponente - Die Arbeitsteilung befördern
        • Service - Module plattformneutral machen
        • Wave - Softwareevolution zur Laufzeit
        • Die Modul-Hierarchie im Überblick
      • Datenflüsse modularisieren
        • Notation & Implementation I - Funktionen
        • Notation & Implementation II - Daten
        • Modularisierungsbeispiel
      • Reflexion
      • Übungsaufgaben
    • 07 - Flow-Design mit 3-dimensionalen Datenflüssen
      • Die wahren Übersetzungsverhältnisse
      • Streams
        • Einsatzgebiete für Streams
      • Implementation
        • Continuation
        • Iterator
        • Fallunterscheidung in der Integration
        • Polymorphie
        • Warteschlange
      • Reflexion
      • Übungsaufgaben
    • 08 - Die IODA Architektur
      • Die Softwarezelle
        • System vs. Umwelt
        • “Kleiderbügelarchitektur”
        • Die Membran
        • “Griechische Architekturen”
        • Der Kern
        • “Vitruvianische Architektur”
      • The Missing Concern: Integration
        • IOSP in der Architektur
        • Interactors
        • Processors
        • IODA: All together now!
      • Übungsaufgaben
    • 09 - Finale im Softwareuniversum
      • Der Explizite Entwurf ist nötig
      • Der Entwurf ist deklarativ
      • Das Modell beschreibt Funktionen in Beziehungen
      • Flow-Design im 4-dimensionalen Raum
        • Orientierungshilfe für die Softwareentwicklung
  • Anhang - Musterlösungen
    • Musterlösung: 01 - Die Anforderung-Logik Lücke
      • Aufgabe 1 - Erklären
        • Vom Nutzen der Modellierung für die Programmierung (ELI5)
        • Reflexion
      • Aufgabe 2 - Modellieren
        • Lösungsansatz
        • Modell
        • Reflexion
    • Musterlösung: 02 - Entwurf im Überblick
      • Aufgabe - Lösungsansatz finden
        • Lösungsansatz für die Domänenlogik
        • Reflexion
    • Musterlösung: 03 - Radikale Objektorientierung
      • Aufgabe - Mit PoMO/IOSP implementieren
        • Modellskizze
        • Codierung der Integration
        • Codierung der Operationen
      • Reflexion
    • Musterlösung: 04 - Flow-Design mit 1-dimensionalen Datenflüssen
      • Aufgabe 1 - Modellieren und implementieren
        • Lösungsansatz verfeinern: Prä-Modell
        • Modell
        • Implementation
      • Aufgabe 2 - Reverse modeling
      • Aufgabe 3 - Lösen, modellieren, implementieren
        • Lösungsansatz
        • Modell
        • Codierung
        • Reflexion
    • Musterlösung: 05 - Flow-Design mit 2-dimensionalen Datenflüssen
      • Aufgabe 1 - Implementation eines Modells
        • Reflexion
      • Aufgabe 2 - Die Dimensionalität eines Modells erhöhen
        • Reflexion
      • Aufgabe 3 - Anforderungen umsetzen mit 2-dimensionalem Modell
        • Verstehen
        • Lösen
        • Modellieren
        • Codieren
        • Reflexion
    • Musterlösung: 06 - Flow-Design mit modularisierten Datenflüssen
      • Aufgabe 1 - Datenfluss modularisieren
        • Schrittweise Modularisierung
        • Klassendiagramm
        • Bibibliotheken
      • Aufgabe 2 - Game of Life
        • Lösungsansatz
        • Modellierung
        • Reflexion
    • Musterlösung: 07 - Flow-Design mit 3-dimensionalen Datenflüssen
      • Aufgabe 1 - Tic-Tac-Toe
        • Lösungsansatz
        • Modell
        • Implementation
        • Reflexion
    • Musterlösung: 08 - Die IODA Architektur
      • Aufgabe 1 - Umbau nach IODA
        • Abhängigkeiten zeigen den Abstraktionsgradienten hinab
      • Aufgabe 2 - Enturf nach IODA inkl. Implementation
        • Anforderungsanalyse
        • Lösungsansatz
        • Modell
        • Implementation
        • Reflexion
  • Anmerkungen

Die Leanpub 60-Tage 100% Zufriedenheitsgarantie

Innerhalb von 60 Tagen nach dem Kauf können Sie mit nur zwei Klicks eine 100% Rückerstattung für jeden Leanpub-Kauf erhalten.

Technisch gesehen ist das ein Risiko für uns, da Sie die Buch- oder Kursdateien so oder so behalten. Aber wir sind so überzeugt von unseren Produkten und Dienstleistungen sowie von unseren Autoren und Lesern, dass wir gerne eine vollständige Geld-zurück-Garantie für alles anbieten, was wir verkaufen.

Sie können nur herausfinden, wie gut etwas ist, indem Sie es ausprobieren, und dank unserer 100% Geld-zurück-Garantie gehen Sie dabei buchstäblich kein Risiko ein!

Es gibt also keinen Grund, nicht auf den 'In den Warenkorb'-Button zu klicken, oder?

Vollständige Bedingungen ansehen...

Verdienen Sie 8$ bei einem Verkauf von 10$ und 16$ bei einem Verkauf von 20$

Wir zahlen 80% Tantiemen auf Käufe von 7,99$ oder mehr und 80% Tantiemen abzüglich einer Pauschale von 50 Cent auf Käufe zwischen 0,99$ und 7,98$. Sie verdienen 8$ bei einem Verkauf von 10$ und 16$ bei einem Verkauf von 20$. Wenn wir also 5000 nicht zurückerstattete Exemplare Ihres Buches für 20$ verkaufen, verdienen Sie 80.000$.

(Ja, einige Autoren haben auf Leanpub bereits viel mehr als das verdient.)

Tatsächlich haben Autoren bereitsüber 14 Millionen Dollar durch das Schreiben, Veröffentlichen und Verkaufen auf Leanpub verdient.

Erfahren Sie mehr über das Schreiben auf Leanpub

Kostenlose Updates. DRM-frei.

Wenn Sie ein Leanpub-Buch kaufen, erhalten Sie kostenlose Updates, solange der Autor das Buch aktualisiert! Viele Autoren nutzen Leanpub, um ihre Bücher während des Schreibprozesses zu veröffentlichen. Alle Leser erhalten kostenlose Updates, unabhängig davon, wann sie das Buch gekauft oder wie viel sie bezahlt haben (einschließlich kostenloser Bücher).

Die meisten Leanpub-Bücher sind als PDF (für Computer) und EPUB (für Smartphones, Tablets und Kindle) verfügbar. Die verfügbaren Formate eines Buches werden in der oberen rechten Ecke dieser Seite angezeigt.

Schließlich haben Leanpub-Bücher keinen DRM-Kopierschutz-Unsinn, sodass Sie sie problemlos auf allen unterstützten Geräten lesen können.

Erfahren Sie mehr über Leanpubs E-Book-Formate und wo Sie sie lesen können

Auf Leanpub schreiben und veröffentlichen

Mit Leanpub können Sie ganz einfach E-Books und Online-Kurse schreiben, veröffentlichen und verkaufen - sowohl während der Entstehung als auch nach Fertigstellung!

Leanpub ist eine leistungsstarke Plattform für engagierte Autoren, die einen einfachen, eleganten Schreib- und Veröffentlichungsprozess mit einem Shop verbindet, der sich auf den Verkauf von E-Books in Entstehung konzentriert.

Leanpub ist eine magische Schreibmaschine für Autoren: Schreiben Sie einfach in normalem Text und klicken Sie zur Veröffentlichung Ihres E-Books nur auf einen Button. (Wenn Sie Ihr E-Book auf Ihre eigene Art erstellen, können Sie sogar Ihre eigenen PDF- und/oder EPUB-Dateien hochladen und mit einem Klick veröffentlichen!) Es ist wirklich so einfach.

Erfahren Sie mehr über das Schreiben auf Leanpub