Softwareentwurf in der hohlen Hand

Gerade komme ich wieder von drei Trainingstagen zum Thema agiler Softwareentwurf. Ein inhouse Training für ehemalige C bzw. C++ Entwickler, die sich noch an .NET gewöhnen müssen. Aber es hat vielleicht gerade deshalb besonders Spaß gemacht, weil sie noch nicht so “objektorientiert verdorben” sind. Ihnen steckt vor allem die C-Praxis in den Knochen, die sie anscheinend offen für den Softwareentwurf mit Softwareuniversum und Flow-Design gemacht hat. Denn wenn die prozedurale Programmierung in einem Recht hatte, dann darin, dass es zuerst und vor allem um Funktionalität und nicht um Daten geht.

Aber von dem positiven Feedback, das Stefan Lieser und ich dort bekommen haben, wollte ich gar nicht sprechen. Die gute Stimmung bei den Trainingsteilnehmern hat vielmehr mich selbst nochmal unseren Ansatz frisch erleben lassen.

Abends saß ich nämlich im Hotel bei einem gemütlichen Kaminfeuerchen und habe an einer Anwendungsidee herumgebastelt. Eine Web-Anwendung, die helfen soll, eine Klippe des Kennenlernens über online Partnerbörsen zu umschiffen. Wie das gehen soll wird die dotnetpro demnächst berichten ;-) Technologisch mit von der Partie werden jedenfalls AppHarbor, Nancy und iron.io sein.

Da saß ich also und habe darüber nachgedacht, wie die Idee in Software funktionieren könnte. Welche Seiten sollte so ein Website haben? Wie sollten die Seitenübergänge sein? Was sollte dabei passieren? Welche Klassen/Komponenten sollte es geben? Wie würden Feature ineinander greifen?

Im Kopf kann ich so etwas bewegen – aber nur bis zu einer gewissen Grenze. Dann muss ich einen Dump machen. Irgendwie muss ich meine Gedanken und Ergebnisse manifestieren. Visual Studio hatte ich vor dem Kamin aber nicht zur Hand. Warum auch? Ich brauche keinen Code, um Software zu entwerfen.

So hat mir denn ein kleiner Notizblock des Hotels geholfen. Der war nur handtellergroß mit schmalen Blättern. Aber er hat mir gereicht wie diese Bilder zeigen:

Wenn Sie nicht wissen, was die Symbole bedeuten und meine Schrift nicht lesen können, macht das nichts. Ich will Ihnen ja nicht erklären, was die Anwendung tut und wie ich gedenke, das zu realisieren.

An dieser Stelle soll nur rüberkommen, dass ich mit zwei kleinen Zetteln die Software entwerfen konnte. Ich weiß nun, welche Klassen ist brauche. Ich weiß, welche Methoden die haben. Ich weiß, wie alles zusammenhängt und die Funktionalität herstellt. Ich weiß, welche Daten fließen. Ich weiß, wie ich APIs kapseln muss. Ich weiß sogar schon, wie ein guter Teil des Codes aussehen muss.

Den Entwurf der beiden Bilder kann ich “so runtercodieren”. Da ist alles drin, was ich brauche. Nur das Layout der Seiten fehlt. Aber das gehört ja auch nicht zum funktionalen Entwurf. Wichtig ist dafür nur, welche Interaktionen der Benutzer mit Dialogen hat. Und die stecken in dem Modell drin.

Durch das Training geöffnet habe ich frisch erlebt, wie effektiv Softwareentwurf mit Papier und Stift sein kann – wenn man eine geeignete Methode hat ;-) Ich muss nicht darauf warten, dass Softwarestrukturen durch Tests wachsen. Ich brauche keine IDE, um bei einer Anwendung voran zu kommen.

Klar, am Ende muss implementiert werden. Bubbles don´t crash. Ich weiß nicht, ob mein Entwurf 100% korrekt/ausreichend ist. Aber ich bin ein gutes Stück voran gekommen. Ich habe mit “systematischer Kritzelei” das Codieren solide vorbereitet. Wenn ich dann Details mit TDD austreiben will, weiß ich, wo ich ansetzen kann.

Und all das steckt in zwei Blättchen mit Flow-Designs. Das fand selbst ich, der ich täglich mit Flow-Design arbeite, irgendwie bemerkenswert cool.