Softwareentwurf mit Flow-Design
$17.50
Minimal-Preis
$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

  • Teile dieses Buch

  • Kategorien

    • Software Architecture
    • Software Engineering
    • Message-Driven Design
    • C#
  • Rückmeldung

    Maile dem/den Autor/en

Ü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 bedingungslose Leanpub Garantie: Kein Risiko, 100% Zufriedenheit

Innerhalb von 60 Tagen ab Kauf kannst du dein Geld zu 100% zurückverlangen, bei jedem Leanpub-Kauf, in nur zwei Klicks. Wir bearbeiten die Erstattungen manuell, daher dauert es ein paar Tage, bis der Betrag ankommt.
Lese die kompletten Bedingungen.

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

Wir zahlen 80% Tantiemen bei Käufen von $7,99 oder mehr und 80% Tantiemen abzüglich einer Pauschalgebühr von 50 Cent bei Käufen 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ückgegebene Exemplare Ihres Buches für $20 verkaufen, verdienen Sie $80,000.

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

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

Erfahren Sie mehr über das Schreiben auf Leanpub

Kostenlose Updates. Ohne DRM.

Mit dem Kauf auf Leanpub bekommst Du kostenlose Updates solange der Autor Änderungen vornimmt! Viele Autoren veröffentlichen ihre Bücher während des Schreibens. Alle Leser bekommen dann kostenlose Updates, egal wann sie das Buch gekauft haben oder wie viel sie bezahlt haben (auch wenn es kostenlos war).

Die meisten Leanpub Bücher sind erhältlich als PDF (für Computer) oder EPUB (für Handy, Tablet, Kindle). Die verfügbaren Formate sind oben rechts auf dieser Seite angezeigt.

Leanpub Bücher kommen ohne DRM Kopierschutz Firlefanz, sodass Du sie problemlos auf jedem unterstützten Gerät lesen kannst.

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

Schreiben und veröffentlichen auf Leanpub

Autoren und Verleger nutzen Leanpub, um erstaunliche Fortschrittsbücher zu veröffentlichen und E-Books zu vervollständigen. Sie können auch auf Leanpub schreiben, veröffentlichen und verkaufen! Leanpub ist eine leistungsstarke Plattform für ernsthafte Autoren und kombiniert einen einfachen, eleganten Schreib- und Publishing-Workflow mit einem Store, der sich auf den Verkauf von E-Books konzentriert. Leanpub ist eine magische Schreibmaschine für Autoren: Schreiben Sie einfach in Klartext, und um Ihr E-Book zu veröffentlichen, klicken Sie einfach auf eine Schaltfläche. Es ist wirklich so einfach.

Erfahren Sie mehr über das Schreiben auf Leanpub