Follow my new blog

Samstag, 26. Januar 2013

Softwareentwurf als Video – Ein Experiment

Wie entwirft man Software? Wie kann man über Softwarestrukturen nachdenken und reden, ohne am Code zu kleben?

Dazu entwickeln Stefan Lieser und ich als die Clean Code Advisors seit Jahren einen Ansatz unter wechselndem Namen: alles begann mit Softwarezellen, dann kamen Feature Streams dazu, die haben Event-Based Components auf den Kopf gestellt und im Augenblick steht im Kern Flow-Design. Alles fließt – nicht nur in der Software, sondern auch bei unserer Methode. Wir voran gekommen, haben einen pragmatischen Weg gefunden – aber wir sind sicher noch nicht am Ende [1].

Wie dieser Weg beschritten werden kann, thematisieren wir in Zeitschriftenartikeln und Blogpostings. Und wir führen in Trainings darin ganz konkret ein, zum Beispiel in der Clean Code Developer Akademie oder auch inhouse. Immer wieder werden wir aber auch gefragt, ob es nicht etwas “zum Zuschauen” gäbe, bei dem man verfolgen kann, wie die Anwendung funktioniert.
Bisher musste wir verneinen. Außer einem Vortragsmitschnitt hier und da, in dem ich mal Modellierung präsentiert habe, gibt es keine “Bewegtbilder” zum Softwareentwurf, wie wir ihn verstehen.

Das könnte sich jetzt aber ändern. Stefan und ich haben nämlich ein Experiment gemacht. In Regensburg haben wir uns um ein SMART Board versammelt und mitgeschnitten, wie wir eine Anwendung entwerfen und beginnen zu implementieren.

Das Ergebnis sehen Sie hier:



Wie gesagt, es ist ein Experiment. Alles steht letztlich zur Disposition. Wir freuen uns über Feedback.

Das Video gliedert sich in mehrere Abschnitte:
  • 00:18:18: Erklärung der Aufgabe
  • 02:13:14: Überblick über den Lösungsansatz verschaffen
  • 05:30:11: UI skizzieren
  • 09:24:03: Interaktionen identifizieren
  • Modellierung von…
    • 12:12:17: Inkrement #1
    • 15:58:21: Inkrement #2
    • 24:02:14: Inkrement #3
    • 28:24:05: Inkrement #4
  • 39:25:03: Kontrakte definieren, um zu zweit komponentenorientiert entwickeln zu können
  • 50:27:13: Review der Kontraktcodierung
  • 51:42:09: Review der Implementation des ersten Inkrements
  • Den Code können Sie im Github Repo einsehen. Dort liegen auch die Entwürfe als PDF.
Ob das zu viel oder zu wenig ist, werden Ihre Rückmeldungen ergeben. Aber wir haben uns auch schon eine Meinung gebildet ;-)

Doch nun: Vorhang auf!

Schauen Sie sich das Video an. Danach können Sie unsere Retrospektive zur Produktion lesen.

Retrospektive

Der Dreh hat Laune gemacht. Das war schon mal wichtig :-) Ganz grundsätzlich hat alles ziemlich gut geklappt. Abgesehen von kleinen technischen Problemen haben alle Werkzeuge geschnurrt. Auch der Videoschnitt verlief reibungslos – allerdings muss ich mal über eine Firewire Festplatte und/oder einen Rechner mit mehr Kernen nachdenken. Es wehte einige Stunden ein deftiger Lüfterwind in meiner Bude.

Ob wir das SMART Board allerdings weiter einsetzen, wissen wir noch nicht. Wie die Totale im Video zeigt, ist es mit dem Licht nicht so einfach. Die Projektionsfläche ist hell – aber Stefan und ich erscheinen als Schattenspieler davor. Die Raumhelligkeit hat für uns nicht ausgereicht. Das nehmen Kameras anders wahr als menschliche Beobachter im selben Raum. Das nächste Videoexperiment wird sicherlich ein anderes Darstellungsmittel ausprobieren.

Auch beim Ton müssen wir nochmal schauen, was wir tun können. Einerseits könnten wir etwas lauter sprechen. Andererseits darf die Akustik etwas besser werden. Das Nuscheln müssen wir uns aber in jedem Fall abgewöhnen ;-)

Mit mehreren Kameras aufzunehmen und zwischen ihnen zu schneiden, war in jedem Fall eine Leichtigkeit. Das behalten wir bei. Dadurch ergibt sich eine natürliche Lebendigkeit im Video ohne großen Aufwand. Wechsel zwischen Küche, Fahrrad, Auto, Schreibtisch usw. ohne inhaltlichen Bezug, wie bei anderen Videoproduktionen, können wir uns sparen ;-)

Nicht zufrieden sind wir jedoch mit der Präsentation des Inhalts. Da sind wir einen Kompromiss eingegangen, weil wir organisatorischen Aufwand befürchtet haben, der das Ergebnis suboptimal ausfallen lässt.

Der Kompromiss besteht darin, dass wir die Inkremente im Sinne eines agilen Vorgehens zuerst alle modellieren, um sie erst anschließend eines nach dem anderen zu implementieren. Das entspricht nicht unserem wahren Vorgehen, das ist nicht, was wir empfehlen. Doch wir dachten, so sei es einfacher aufzunehmen, um nicht immer wieder zwischen Modellierung und Implementierung umbauen zu müssen.

Wie sich dann aber herausgestellt hat, war es gar nicht nötig, für die Implementierung bzw. den Review von Code umzubauen. Wir haben einfach mit den drei Kameraperspektiven weitergemacht und am SMART Board über den Code gesprochen. Kein live coding, kein Screenrecording, wie zunächst gedacht.

Das werden wir beim nächsten Mal auf jeden Fall anders machen: design a little, code a little. So muss der Rhythmus sein. Sonst läuft man mit dem Modell bei allen Vorteilen eines expliziten Entwurfs in die Irre. Bubbles don´t crash behält seine Relevanz. Das zeigt das letzte Inkrement im Video. Die Diskussion darüber ist verhältnismäßig lang – und trotzdem kommt etwas heraus, das nicht voll funktionstüchtig ist. Wir haben schlicht nicht alle Eventualitäten durchdacht. Erst “Anwendertests” nach der Implementierung von Inkrement #4 haben gezeigt, dass es eine Lücke in der Funktionalität gab.

Das Problem ist beim letzten Inkrement aufgetreten, da war es dann nicht so schlimm. Aber es hätte uns auch früher passieren können; dann wären die Modelle weiterer Inkremente auf falschen Modellen aufgebaut worden. Dagegen schützt nur, Modellinkremente sofort zu implementieren.

Eine weitere Frage, die wir uns gestellt haben, ist die nach dem Single Responsibility Principle. Haben wir das mit dem Video eingehalten? Ist der Fokus eng genug? Oder haben wir auch hier schon zuviel auf einmal gewollt? Bewusst haben wir unseren Ansatz schon nicht erklärt, sondern ihn einfach unter uns angewandt. Aber ist es vielleicht zuviel, dann auch noch zu implementieren? Die Kontraktdefinition scheint uns in jedem Fall zu ausführlich geraten.

Ausblick

Soweit mal unser erstes Videoexperiment mit Reflexion. Nun kommen Sie. Was ist Ihr Feedback? Was gefällt Ihnen, was sollen wir anders machen? Haben Sie Interesse an weiteren Videodarstellung zum Thema Softwareentwurf? Wünschen Sie sich inhaltlich etwas? Worauf sollten wir näher eingehen? Was weglassen? Können wir den Entwurf in bestimmten Domänen oder von konkreten Szenarien demonstrieren?

Wir sind gespannt, was Sie uns schreiben.

Fußnoten

[1] Dass wir überhaupt an einem Ansatz arbeiten und nicht schlicht OOA/D und UML benutzen ist kurz gesagt: Wir sehen in der Praxis nicht, dass die existierenden Ansätze erstens überhaupt relevante Verbreitung gefunden hätten. Es regiert das Durchwursteln. Zweitens halten wir diese Ansätze im Sinne von Methode bzw. Standarddarstellung für unzureichend und allemal schwer erlernbar.
Unser Bemühen richtet sich daher auf eine pragmatischere, auch im Projektalltag handhabbare Methode ohne Firlefanz, die einen Großteil der Softwarerealität abdeckt.

Wie diese Methode aussieht, haben wir in unterschiedlichen Publikationen immer wieder in Facetten dargestellt. Eine umfassende Beschreibung fehlt allerdings. Auch dieses Video liefert sie nicht. Es bietet nur einen Ausschnitt. Aber vielleicht kommen wir ja noch dazu, ein Buch zu schreiben… ;-) Einstweilen entsteht die derzeit systematischste Beschreibung gerade in einer Artikelserie für die Zeitschrift web & mobile developer.

14 Kommentare:

Oliver hat gesagt…

Danke für das interessante Video. Ich fand es sehr gelungen zu sehen, wie einfach der Weg von den Anforderungen hin zur fertigen Software sein kann. Ich persönlich bin kein grosser Fan von UML und verwende auch gern Ablauf- bzw. Flussdiagramme in der Form wie ihr sie im Video gezeigt habt. Das extrahieren der Komponenten und Schnittstellen konnte nachvollziehbar aus den Diagrammen erfolgen. Die Dinge letztendlich in Code zu giessen war danach nur noch reine Formsache.

Mein Fazit lautet daher: Bitte mehr davon. Ich freue mich schon auf das nächste Softwaredesign Video.

Noch ein paar Anmerkungen zu einzelnen Punkten:

SMART Board: Die Präsentationsform hat mir gut gefallen. Auch das ihr wegen der Lichtverhältnisse nur als Schatten vor dem Board zu sehen wart hat mich nicht gestört. Das Hauptaugenmerk liegt auf den Inhalten und damit ist der Blick sowieso auf das SMART Board fokussiert.

Ton: Die Akustik war nicht optimal und könnte verbessert werden. Und keine Angst wegen des Nuschelns. Dieses habe ich kaum wahrgenommen.

Gliederung: Modellierung und Implementierung sollten iterativ erfolgen. Dabei solltet ihr aber darauf achten nicht zu viele Inkremente zu verwenden. Ich glaube in diesem Beispiel hätte es eher geschadet wenn die vier Inkremente nacheinander modelliert und implementiert würden da dann zu viele Wiederholungen im Video gewesen wären. Um dies zu vermeiden solltet ihr euch eventuell auf zwei Inkremente beschränken.

Länge: Eine Stunde ist in Ordnung für solch ein Video. Länger sollte es aber nicht gehen. Längere Videos sollten dann lieber in zwei oder mehr Folgen aufgeteilt werden.

Implementierung: Eine Live-Implementierung zu zeigen halte ich für unnötig. Den Quellcode am Ende zu sehen gehört aber auf jeden Fall zum Verständnis dazu. Daher fand ich eurer Vorgehen gut. Die Definition der Schnittstellen am SMART Board war wichtig für das Verständnis. Mir hat es zum Abschluss des Videos völlig gereicht, kurz den fertigen Quellcode der Schnittstellen und die implementierten Module zu sehen.

Carsten hat gesagt…

Mir hat das Video auch sehr gut gefallen - weiter so und mehr davon.

Ob Live-Coding wichtig ist? Hier sicher nicht, wenn die Beispiele komplizierter wären wäre es denke ich schon hilfreich - speziell wenn beim Coding dann doch ein Problem in der Architektur auftaucht, die in einem Review angesprochen werden müsste.

Konkret hier wäre das vielleicht der Bezug zum Timer bzw. Unit-Testing.

Ich schätze mal außer dem gezeigten "manuellen" Test gabs keine oder? Ansonsten muss man schon heftige Mocking-Geschüzte auffahren um mit Timern/DateTime.Now und ähnlichen sinnvoll arbeiten zu können (oder wie haltet ihr das?)

Wegen der Präsentation selber: ich würde hier nichts ändern - Smartboard ist absolut ok, Ton war IMO gut, Bild sowieso.

Also nochmals: Weiter so :D

Ralf Westphal - One Man Think Tank hat gesagt…

Freut mich, dass das Feedback bisher so positiv ist :-)

@Carsten: Das Testen ist ganz einfach. Keine Geschütze. Das ist ja der Trick beim Flow-Design. Um den Wecker zu testen, brauche ich eben keine Attrappe für die Uhr.

Der Schwerpunkt lag zwar nicht auf testgetriebener Entwicklung, dennoch gibt es gerade zum Wecker ein paar Tests (s. Repo).

@Oliver: Den Hinweis zu den sehr dünnen Inkrementen finde ich interessant. Vielleicht sollten wir da auch nochmal unterscheiden zwischen modellierten Inkrementen und Implementation.

Wir könnten beim Modellieren z.B. weiterhin Inkrement #1 und #2 getrennt sehen, aber dann zusammen implementieren.

In jedem Fall halte ich es aber für wichtig, den Wechsel zwischen Entwurf und Impl, wie wir ihn in der Praxis leben, auch im Video zu zeigen. Inkremente allein reichen nicht.

Wenn wir - außer in Sonderfällen - kein live coding brauchen, soll mich das freuen.

45-60min scheint mir auch das Maximum für die Dauer zu sein. Dieses Mal haben wir nicht drauf geachtet. Ist einfach so herausgekommen. Das Verhältnis war ca. 3:1 (Drehzeit : Spielzeit). In Zukunft müssen wir das aber im Blick behalten und mindestens Sollbruchstellen einbauen.

Anonym hat gesagt…

Gibt es auch die Möglichkeit, das Video ohne Flash zu sehen oder herunterzuladen?

Ralf Westphal - One Man Think Tank hat gesagt…

Sollte jetzt ohne Flash sein. Hab es auf dem iPad ansehen können.

Anonym hat gesagt…

Danke. Auf dem Android-Tablet läuft es jetzt, zwar eher schlecht als recht, aber es läuft.

Anregung: Vielleicht kann man bei Gelegenheit noch ein MP4/WMV/anderes bereitstellen.

Andreas Richter hat gesagt…

Mir hat das Video auch ziemlich gut gefallen und ich freue mich auf weitere Folgen.

Die Präsentation per (SMART-)Board solltet ihr auf alle Fälle beibehalten. Für mich spielt dabei nicht die Technik des SMART-Boards die entscheidende Rolle, sondern vielmehr die visualisierten Gedankengänge. Wie die Flüsse auf den Zeichnungen entstehen. Das kann sicher auch mit einem analogen Whiteboard erfolgen, wobei da der "Rückblick" auf vorhergehende Seiten und deren "Nachbesserung" sicher nicht so einfach möglich wäre.

Der Ton hat mich beim Ansehen nicht wirklich gestört. Mir ist nicht mal aufgefallen, dass ihr genuschelt haben sollt. Dafür war der Inhalt zu interessant :)

Live-Coding ist nicht nötig. Ich denke, wie man Entwickelt ist nicht der Fokus des Videos.

Vielleicht hätte man ein CodeReview nach jedem Inkrement einbauen können. Das wäre aus meiner Sicht näher an der Praxis. Auch auf die Gefahr hin, dass der Fluss in der Präsentation durch all zu häufigen Kontextwechsel leidet. Ein Versuch wär es sicher wert.

Was mir weiterhin gut gefallen hat, ob beabsichtigt oder nicht, war die während des Entwurfes gewonnene Erkenntnis, dass Änderungen an vorhergehenden Inkrementen nötig sind. All zu oft finden sich Präsentationen, in denen alles wie am Schnürchen läuft. Leider sieht die Realität anders aus. Das habt ihr meiner Meinung nach sehr gut dargestellt. Davon könnte es für mich mehr geben.

Bleibt mir nur noch, mich für das Video bei den beiden Protagonisten zu bedanken. Ich für meinen Teil habe viel mitnehmen können und freue mich auf kommende Folgen.

Andreas Richter hat gesagt…

Ich habe noch eine Frage zum Code.

Warum habt ihr die einzelnen Komponenten auf mehrere Solutions verteilt? Warum nicht alle Projekte in eine Solution?

Widerspricht das dem Komponenten-Gedanken? Oder wird eine Solution schnell zu unübersichtlich? Oder sollen die Komponenten so schneller austauschbar und an anderen Stellen einsetzbar sein?

Unknown hat gesagt…

Ich kann mich den anderen nur anschließen!
Mir hat das Video sehr gut gefallen!

Die Spontanität müsst ihr auf alle Fälle beibehalten. Das zeigt sehr gut, dass ihr auch nur Menschen seid, die mit Wasser kochen und nicht gleich zum perfekten Design gelangen.
(Selbst bei so einer relativ trivialen Wecker-App.)

Gerade der Weg von der Idee zum Entwurf ist oftmals das Kernproblem.

Ich finde auch, dass es kein Live-Coding geben muss. Wie ihr es in dem Video gemacht habt, war das gut. Mal kurz die wesentlichen Codefragmente zeigen und erklären, reicht.

Ihr könntet höchstens, wie auch schon erwähnt wurde, mehr inkrementell vorgehen. Also erst ein bisschen entwerfen, dann in Code gießen, wieder entwerfen, usw.

Die lauffähige Software sollte dabei nach jeder Iteration kurz gezeigt werden. (Wobei es immer so eine Sache ist, ob es überhaupt was zu sehen gibt.)

Dadurch entsteht nicht der Eindruck, dass man gleich am Anfang die gesamte Software auf "Papier" entworfen haben muss, ehe man implementiert.

Insgesamt war das aber sehr gelungen und ich freue mich riesig auf das nächste Video!

Ralf Westphal - One Man Think Tank hat gesagt…

@Andreas: Die mehreren Solutions sind der Komponentenorientierung geschuldet.

Sie dienen einerseits der Vermeidung von Kollisionen bei der gleichzeitigen Arbeit am Quellcode. Aber vor allem wird dadurch die binäre Nutzung von anderen Projekten gefördert. Nur der Kontrakt zählt. Deshalb auch nicht zwischendurch mal schnell rüberlinsen, wie die Implementation aussieht. Das macht man aber schnell, wenn alles in einer Solution ist. (Davon mal abgesehen, dass große Solutions in VS irgendwann keinen Spaß mehr machen.)

Carsten hat gesagt…

@Ralf ... ok den Code hatte ich nicht gesehen - danke für den Hinweis

Denis hat gesagt…

Ton und Präsentation über das SMART-Board waren aus meiner Sicht Ok. Nur die Bezeichner im Code waren schlecht zu sehen. Dagegen würde sicher eine dunklere Farbe helfen, damit mehr Kontrast reinkommt.
Als inhaltliche Anregung hätte ich noch folgendes: Eine Modellierung, die mehrere Abstraktionebenen benötigt, wo also in das Modell hineingezoomt wird, würde die Vorteile des FlowDesigns noch besser zur Geltung bringen und einen grundlegenden Unterschied zur anderen Modellierungsarten unterstreichen, der es erlaubt, ein Modell auf verschiedenen Abstraktionsebenen zu studieren.

Carsten hat gesagt…

Was ist denn aus dem Experiment geworden?

Ralf Westphal - One Man Think Tank hat gesagt…

Ein Buch: https://leanpub.com/thearchitectsnapkin-katafuerkata - Hier ein paar erklärende Worte: http://blog.ralfw.de/2014/05/zuschauen-beim-softwareentwurf.html