Vom Nutzen der Code Kata für das Entwicklerleben

Grad gibt es ja mal wieder Diskussion um eine Code Kata, die Kata Tennis. Siehe u.a. die Kommentare hier und hier. Anlass war ein online Coding Dojo der Online .NET User Group. Da gehen die Meinungen darüber, wie man am besten zu einer Lösung der Aufgabe kommt, nun auseinander. Das ist gut so. So kommen wir alle weiter, das macht grundsätzlich Spaß.

Allerdings hat die Diskussion für mich auch unbefriedigende Züge. Sie wird nämlich mühsam, wenn wir uns nicht auf technische Aspekte konzentrieren können, weil uns unterschiedliche Ansichten zur Form im Wege stehen, genauer sogar: unterschiedliche Ansichten zum Zweck von Code Katas.

Was soll das also mit den Code Katas?

Nutzen #1: Lernen

Code Katas sind Übungsaufgaben. An ihnen soll man irgendwas lernen. Sie bieten ein überschaubares Problem ab vom Projektalltag, an dem man Techniken, Konzepte, Tools, Vorgehensweisen ausprobieren kann, ohne Angst vor Fehlern haben zu müssen. Feedback stellt sich schnell ein, weil die Aufgaben klein sind. Hat man eine Lösung zum Laufen gebracht? Hat man die Technik, das Tool, die Vorgehensweise mit Gewinn eingesetzt? Das lässt sich in wenigen Stunden herausfinden. Und wenn es Differenzen zwischen Wunsch und Wirklichkeit gibt, kann man es dann nochmal probieren mit derselben oder einer anderen Kata.

Nutzen #2: Spaß

Code Katas sind von Thema und Umfang so geschnitten, dass es Spaß macht (oder zumindest machen sollte), sich mit ihnen allein oder in Gemeinschaft zu beschäftigen. Da ist für jeden etwas dabei. Ein bisschen Knobeln, aber nicht zuviel. Der Spaß entsteht durch Herausforderung auf einem für jeden selbst wählbaren Problemniveau mit Feedback in absehbarer Zeit.

Lernen mit Spaß: Darum gehts bei Code Katas, würde ich mal sagen. Nicht mehr und nicht weniger.

Das ist übrigens nicht neu. Solche kleinen Aufgaben gibt es schon seit Jahrzehnten. Die pragmatischen Programmierer haben sie also nicht erfunden. Da gibt es die legendären Programming Pearls von Jon Bentley. Oder den Bundeswettbewerb für Informatik, den International Collegiate Programming Contest der ACM oder hier eine wettbewerbsübergreifende Sammlung von Aufgaben.

Wer Übungen sucht, um seine Programmierfertigkeiten zu trainieren, der findet also reichlich Material. Wie wäre es z.B. mal mit einem APL Interpreter oder Barcodeerkennung statt der ewigen Fizzbuzzpotterbankocrtennisaufgaben? Zufinden hier. Vielleicht ist da dann auch mal was dabei, was nicht so trivial ist, dass wir ewig darüber diskutieren müssen, ob TDD allein ausreicht für eine Lösung. Denn am Ende sind die bisher im Umlauf befindlichen Katas eher so klein, dass man mit oder ohne spezielle Methoden und Konzepte zu einer lauffähigen Lösung kommt.

Übrigens: Wer Spaß am Knobeln und am Wettbewerb hat, kann mit “Code Katas” sogar Geld verdienen. Einfach mal bei TopCoder vorbeischauen.

Freiheit der Form

Womit wir bei der Frage sind, was denn unverbrüchlich zu Code Katas gehört, um den Nutzen zu erreichen? Gehört TDD dazu? Gehört Modellierung dazu? Gehört eine Gruppe dazu?

Ich würde sagen, nichts davon ist zwingend. Code Katas – anders als die anderen o.g. Aufgaben – sind zwar traditionell verbunden mit TDD, doch das halte ich nicht für unverbrüchlich. TDD zu üben, war mal ein Ausgangspunkt für bestimmte Leute zu einem bestimmten Zeitpunkt. Doch sich daran nun zu klammern, finde ich kontraproduktiv und dogmatisch.

Für mich ist daher die Durchführung einer Code Kata völlig frei in der Wahl der Form. Man kann sie allein oder zu mehreren im Coding Dojo bearbeiten. Man kann mit TDD oder F# oder UML oder auch ganz anders dran arbeiten. Nur der Nutzen sollte am Ende entstehen.

Minimaler Rahmen

Damit ein Nutzen sichergestellt ist, halte ich zweierlei dann aber doch für zwingend:

1. Vor Beginn der Code Kata ist festzulegen, was genau gelernt werden soll. Lernziel und Erwartungshorizont sind zu definieren. Soll TDD geübt werden? Soll das Modellieren geübt werden? Soll Modellieren + TDD geübt werden? Soll die Lösung mit UML entworfen werden? Soll BDD geübt werden? Soll die Formulierung der Lösung in F# geübt werden ganz ohne Tests? Soll besonders auf SOLID oder KISS oder LOC geachtet werden? Egal. Es muss nur festgelegt werden. Ein für die Code Kata gültiger Grundsatz, ein Lernziel ist zu finden.
2. Auf die Kata folgt eine Reflexion. In der wird besprochen, inwiefern der Nutzen realisiert wurde. Hatten alle Spaß? Wurden die vorher festgelegten Lerninhalte zielstrebig verfolgt? Was wurde davon gelernt? Wo gab es Schwierigkeiten? Wo wurde Unerwartetes gelernt?

Reflexion der Diskussion

Wenn ich diesen minimalen Rahmen für Code Katas mal in Anschlag bringe, sehe ich die Diskussion um die Kata Tennis ein wenig mit anderen Augen. Teile der Diskussion scheinen mir nun um ein unausgesprochenes Missverständnis zu gehen: die Lerninhalte der Diskutanten.

Über den Nutzen von Code Katas sind wir uns alle einig, glaube ich. Aber bei den Lerninhalten gehen unsere Meinungen auseinander.

Da gibt es manche, die vor allem eine Lösung finden wollen. Mehr oder weniger egal wie. Hauptsache, am Ende läuft es. Andere sind auch zufrieden, wenn keine lauffähige Lösung entsteht, es aber Spaß gemacht hat und irgendwas vorher nicht Spezifiziertes gelernt wurde. Wieder andere wollen vor allem TDD üben. Und noch andere wollen ein umfassenderes Vorgehen üben, das womöglich für die trivialen Code Katas überkandidelt erscheinen mag.

Ich denke, in zukünftigen Diskussionen über Code Katas sollten wir uns klarer darüber werden, was unsere Lerninhalte sind. Wir sollten dann Lösungen einfach so kritisieren, bei denen ein anderer als unser Lerninhalt im Vordergrund stand. “Warum hast du nur TDD benutzt?” ist nur eine valide Kritik, wenn z.B. “Softwareentwicklung üben” der Lerninhalt war, nicht jedoch wenn der lautete “TDD üben”. Kritik sollte sich entweder auf das Lernziel direkt beziehen, “Warum übst du A und nicht B?” Oder sich innerhalb des Lernziels bewegen, “Ich würde zwar B üben statt A, aber wenn du schon A verwendest, dann solltest du es anders machen.”

Vor meiner Kritik anderer Tennis-Lösungen hätte ich also z.B. erst fragen sollen, “Was war dein Lernziel, Björn?” Wenn er dann geantwortet hätte, “Ich wollte nur TDD üben.” oder “Ich wollte das State-Pattern üben.”, dann wäre meine weitere Agrumentation anders verlaufen. Dann wäre sie weniger Kritik gewesen als vielmehr schlichte Beschreibung.

So aber hatte ich angenommen, Björns Ziel sei dasselbe wie meines gewesen: “Üben, eine Lösung für ein Programmierproblem zu finden im Rahmen eines systematischen Vorgehens”. Da für mich zum systematischen Vorgehen auch Modellierung gehört, die bei Björn und anderen aber nicht sichtbar war, habe ich Kritik statt schlichter Beschreibung geäußert.

Nach ein wenig mehr Nachdenken weiß ich das nun. Zukünftig werde ich deshalb versuchen, zuerst mehr über die Ziele anderer herauszufinden. Wenn ich die kenne, kann ich entweder bewusst kritisieren, wenn ich anderer Meinung bin, oder eben nur Alternativen beschreiben. Das können alternative Ziele sein oder alternative Wege zum selben Ziel. Oder beides. Soviel als Beitrag von mir für heute zu mehr Harmonie und Frieden auf dem Entwicklererdball… :-)

Wider die Patternmania

Heute morgen habe ich hier im Blog meinen Ansatz für die Kata Tennis beschrieben. Den kommentierte Björn Rochel mit

“Warum so abstrakt? Warum so viel Zeremonie? Eine Alternative wäre bsp. das State-Pattern. Finde ich persönlich deutlich einfacher und lesbarer.”

Nach meinem Antwortkommentar bin ich daraufhin aber nicht recht zur Ruhe gekommen. Sein Einwand hat an mir genagt; ich fand meine Entgegnung noch nicht fundiert genug. Nun kann ich meine Position aber besser formulieren, glaube ich. Für einen Kommentar ist sie mir allerdings zu wichtig. Also ein weiterer Blogartikel.

Zu abstrakt?

Ist ein Zustandsautomat zu abstrakt? Dass er abstrakt ist im Vergleich zu Code, ist klar. Aber ist er zu abstrakt, d.h. unnötig abstrakt? Gibt es also ein absolutes, für alle Entwickler der Kata Tennis bestes Abstraktionsniveau, auf dem sie denken sollten? Ich behaupte, nein.

Für mich einfachen Sterblichen ist ein Zustandsautomat zur Beschreibung der Tennis Zählregeln nicht zu abstrakt, sondern gerade richtig. Wenn ich die irgendwie formalisieren will, um eine bessere Übersicht zu bekommen, ist ein Zustandsautomat sehr, sehr praktisch. (Ob ich den grafisch entwerfe oder als Tabelle, ist egal.)

Was wäre denn auch die Alternative? Eine Reihe von Wenn-Dann-Regeln? Das kann Björn doch nicht wirklich meinen.

Meine Vermutung ist eher: Björn ist Tennisprofi und atmet die Regeln täglich, deshalb muss er darüber nicht mehr nachdenken. Deshalb findet er einen Zustandsautomaten zu abstrakt.

Dagegen halte ich, dass es nicht darum geht, ob ein Entwickler meint, Anforderungen verstanden zu haben, sondern er muss das dem Auftraggeber – auch einen imaginierten wie bei einem Dojo – demonstrieren. Als Entwickler müssen wir also darlegen können durch eine eigene Beschreibung der Anforderungen, dass wir wissen, worum es geht. Zum Anforderungstext zu nicken, ist zu wenig.

Wie hat Björn das aber dargelegt? Keine Ahnung. Sein Code bei github gibt darüber keine Auskunft. Wie hätte ich nach Darlegung der Anforderungen in Björn Vertrauen haben können, dass er korrekten Code schreibt? Weil er nach TDD vorgeht? Kaum. Das interessiert mich nämlich als Auftraggeber nicht. Vertrauen hätte aufbauen können, dass Björn mir in seinen Worten und/oder mit einer eigenen (abstrakteren) Darstellung widerspiegelt, was er verstanden hat. Meine Zustandsautomatengrafik ist so eine Darstellung, finde ich. Die könnte sogar ein Auftraggeber verstehen; aber wenn nicht, dann machts auch nichts. Dann kann ich mit dem Automaten in der Hand dem Auftraggeber erklären, wie ich danach die Regeln verstehe.

Ergo: Zu abstrakt finde ich den Zustandsautomaten nicht, sondern als Beschreibung meines Verständnisses der Anforderugen unabhängig vom Code absolut nötig.

Zu viel Zeremonie?

Nicht nur soll der Zustandsautomat zu abstrakt sein, nein, er soll auch zu zeremoniell sein. Damit meint Björn wohl, dass er unabhängig von der Beschreibung unnötig ist und nicht zum Kern der Lösung gehört.

Das verstehe ich nicht. Was ist an einem Zustandsautomaten unnötig für die Lösung? Er stellt vielmehr den Kern der Lösung dar. Er formalisiert das Tennis Zählregelwerk. Er fasst an 1 Ort zusammen, wie es geht. Auf dem Papier formuliert er kurz und knapp die Essenz der Zählung. Und in Code umgesetzt braucht er ganze 5 Zeilen

private readonly int[,] _stateTransitions = new[,] {
                              {1,2,3,6,5,6,-1,4,-1},
                              {0,1,2,4,7,4,-1,8,-1} };
internal int _currentState;
…
var transition = position == ScoringPositions.YouWin ? 0 : 1;
_currentState = _stateTransitions[transition, _currentState];

Ich bitte um Erhellung, wie das Regelwerk der Zählung knapper und auch übersichtlicher und auch leichter anzupassen hätte gefasst werden können. Björn braucht in seinem Code, der ohne Modellierung auskommt, immerhin mindestens 57 Zeilen und weitere, die ich auf die Schnelle nicht erkenne. Ist das ein Vorteil von weniger Zeremonie? Eine Zehnerpotenz mehr Codezeilen und weniger Verständlichkeit durch Verteilung der Verantwortlichkeit für die Zählung auf mehrere Klassen? Hm… ich bin im Zweifel.

Zu wenig Pattern?

Und schließlich eines meiner Lieblingsargumente – vor allem aus der Java-Ecke gehört: “Was du da machst, folgt nicht dem Pattern XYZ. Das ist nicht gut.” Oder in der allgemeineren Form: “Was du da machst, ist nicht wirklich objektorientiert.” Da muss ich immer schmunzeln. Als ob mehr Patterns oder mehr Objektorientierung irgendein Qualitätskriterium seien…

Patterns und Objektorientierung sind nur Mittel zu einem Zweck. Die Frage muss also immer sein: Wird ein Zweck mit einem Pattern oder der Objektorientierung am besten erreicht?

Diese Frage stelle ich an Björn:  Bist du wirklich der Meinung, dass du durch Befolgen eines Patterns, das dich 57+ Zeilen kostet – im Gegensatz zu meinen 5 Zeilen – irgendwie den Zweck “Tennis Zählregeln implementieren” besser erreichst?

Das kann ich nicht glauben.

Mein simpler “Beweis”: Wenn sich an der Zählregel etwas ändert, dann habe ich genau 1 Eingriffspunkt, nämlich die Tabelle mit den Zustandsübergängen. Ich muss mich also nur auf 2 Zeilen Code konzentrieren. Du hingegen müsstest schauen, ob eine oder mehrere deiner State-Klassen verändert werden müssten oder gar eine neue hinzukommen muss.

Und nun noch fundamentaler: Patterns und Objektorientierung sind Implementationsdetails. Ob und wie ich sie einsetze muss für die Lösung relativ egal sein. Denn die Lösung sollte nicht allein und schon gar nicht sofort in Code formuliert werden. C# ist auch ein Implementationsdetail.

Stattdessen – wie könnte es anders sein ;-) - sollte die Lösung zuerst modelliert werden. D.h. sie sollte unabhängig von Implementationsdetails formuliert werden. Keine Klassen, kein State-Pattern, keine Arrays… Genau das habe ich getan. Ich habe mir sprachunabhängig Gedanken gemacht, wie die Lösung aussehen könnte. Ein Zustandsautomat ist nicht an C# gebunden und das Datenflussdiagramme auch nicht.

Und erst als ich auf Modellebene zuversichtlich war, die Lösung formuliert zu haben, habe ich mich an die Übersetzung gemacht. Da sind dann 5 Zeilen für den Zustandsautomaten rausgekommen und ca. 60 Zeilen für die gesamte Logik – also knapp nur 50% der LOC bei Björn. Die habe ich sehr wahrscheinlich dann auch schneller getippt und schneller getestet.

Schneller und einfacher geändert sind sie auch, da es erstens viel weniger Funktionseinheiten (Klassen, Methoden) gibt und zweitens deren Verantwortlichkeiten nicht weniger klar sind als bei Björn.

Nebenbei: Wer meint, meine Lösung enthalte zu wenig Pattern, der schlage in der Literatur nach. Dort wird man finden, dass ein Zustandsautomat das um Jahrzehnte ältere Pattern im Vergleich zum State-Pattern und jedem anderen Designpattern ist. Ich habe also sehr wohl auf Patterns gesetzt; nur eben nicht die seit 15 Jahren hippen Entwurfsmuster. Entwurfsmuster entlasten also nicht von der Mühe, sich mit Modellierung auseinanderzusetzen. Eine Leseempfehlung dazu: “Modellierung” von Kastens und Büning.

Fazit

Kritik der Art “zu viel von …” oder “zu wenig von …” finde ich wenig hilfreich. Sie ist letztlich nur eine Gefühlsäußerung und nicht argumentbasiert. Denn Argumente beziehen sich auf eine Differenz zwischen Zweck und Mittel. Die habe ich aus Björns Kritik nicht wirklich herauslesen können.

Aber ich bin offen: Wer mag, kann mir darlegen, warum meine gewählten Mittel Modellierung im Allgemeinen, Zustandsautomat und EBC-Diagramm im Besonderen und ihre Übersetzung in Code die Zwecke Testbarkeit und Evolvierbarkeit weniger gut erfüllen als eine andere Herangehensweise.

Spiel, Satz, Sieg fürs Nachdenken

Gerade hat die .NET Online User Group die Kata Tennis beim online Coding Dojo bearbeitet. Leider konnte ich nicht teilnehmen. Da in Twitter dazu aber noch anschließend diskutiert wurde, habe ich mir gedacht: Warum nicht die Aufgabe nachträglich angehen?

Meine Lösung liegt hier in meinem Mercurial Google Repository. Anders als im Coding Dojo bin ich jedoch nicht streng nach TDD vorgegangen. Deshalb ist die Struktur der Implementation anders als bei den Dojo-Teilnehmern und auch meine Tests sehen anders aus.

Zum Hintergrund meiner Lösung an dieser Stelle daher ein paar kurze Worte.

1. Der API

Bevor ich mit der Implementation losgelegt habe, habe ich über die Lösung nachgedacht. Wie könnte die aussehen? Nicht nur an der “Oberfläche”, Stichwort API, sondern auch darunter.

Der API – der immer explizit vor Codierungsstart festgelegt werden sollte, wie ich meine – sieht so aus:

var g = new Game();
g.AddScore(Players.Player1);
g.AddScore(Players.Player2);
g.AddScore(Players.Player1);
…
Console.WriteLine(g.Winner);

Bei mir geht es also nur darum festzustellen, ob durch einen Ballsieg ein Gewinn eingetreten ist und wer der Gewinner ist. Die Aufgabenstellung der Kata Tennis lässt diese Interpretation zu. Dort ist nämlich von gar keinem API die Rede; es sollen lediglich “irgendwie” die Regeln implementiert werden.

2. Das Modell

Ausgehen vom API habe ich mir Gedanken gemacht, wie denn so ein Tennisspiel intern überhaupt repräsentiert werden könnte. Sofort fiel mir da ein Zustandsautomat ein. Die Zustände sind die Spielstände eines Spielers, die Übergänge ergeben sich aus Gewinn eines Balls bzw. ob ein Ball verloren wurde (rot). Hier meine Skizze, die ich auf meinem iPad gemacht habe:

So ein Zustandsautomat ist natürlich eine sehr abstrakte Funktionseinheit. Wo und wie läuft der denn im Zusammenhang, so dass er vom API genutzt wird? Das habe ich mit einem kleinen EBC-Diagramm für den AddScore() API-Aufruf modelliert:

Der Spieler, der einen Ball gewonnen hat, fließt hinein und wird übersetzt in eine Position für jeden der beiden Spieler. Beide Spieler sind repräsentiert durch ein Objekt (Player), das ihren Zustand hält. Dort läuft der Zustandsautomat. Der liefert nach einer Transition den neuen Spieler-Spielstand an ein abschließendes Bauteil, das ermittelt, wer gewonnen hat.

Beide Skizzen zusammen haben mich, hm, 10-15 Minuten gekostet. Der Zustandsautomat hatte daran den Löwenanteil, würde ich sagen. Er diente ja aber nicht nur der Lösungsmodellierung, sondern auch noch dem Anforderungsverständnis.

Am Ende der Modellierung kannte ich dann alle relevanten Funktionseinheiten und konnte loslegen – und zwar wo ich wollte. Denn die Funktionseinheiten sind ja durch EBC wunderbar entkoppelt.

3. Implementation

Die Implementation habe ich mit den beiden kleinsten Funktionseinheiten begonnen: Ballgewinner in Position übersetzen und Gewinner aus den Spieler-Spielständen ermitteln. Die Herausforderung Zustandsautomat hab ich also an den Schluss gelegt.

Die ersten beiden Funktionseinheiten waren so klein, dass ein Test-first Ansatz nicht nötig war. Ich habe sie deshalb einfach runtergeschrieben und danach Tests geschrieben. Das war ohne Verlust an Korrektheit befriedigender.

Test-first/TDD sollte ja kein Dogma sein. Wenn die Zwecke von TDD anders/leichter erreicht werden können, dann sollte man den leichteren Weg gehen. Und was sind die Hauptzwecke von TDD? 1. Code in überschaubare, leicht testbare Einheiten strukturieren; 2. Eine gute Testabdeckung sicherstellen. Beides habe ich durch die Modellierung erreicht. Denn die hat zu kleinen Funktionseinheiten geführt – ohne später refaktorisieren zu müssen –, die testbar sind und die ich mit wenigen Tests gut abdecken kann – auch im Nachhinein.

Bei der Implementation des Players habe ich dann jedoch nach Test-first gearbeitet. Viel herausgekommen ist dadurch jedoch nicht ;-) Denn auch der Player ist am Ende so einfach mit dem Zustandsautomaten, dass sich eine weitere Zerlegung nicht lohnt:

internal class Player
{
    private readonly Dictionary<ScoringPositions,
                                Dictionary<Scores, Scores>>
                                _stateTransitions =
        new Dictionary<ScoringPositions, Dictionary<Scores, Scores>>
            {
                {ScoringPositions.YouWin,
                    new Dictionary<Scores, Scores>
                    {
                        {Scores.Love, Scores.Fifteen},
                        {Scores.Fifteen, Scores.Thirty},
                        {Scores.Thirty, Scores.Forty},
                        {Scores.Forty, Scores.Win},
                        {Scores.Deuce, Scores.Advantage},
                        {Scores.Advantage, Scores.Win},
                        {Scores.Win, Scores._Invalid},
                        {Scores._Advantage, Scores.Deuce},
                        {Scores._Win, Scores._Invalid},
                    }},
                {ScoringPositions.YouLoose,
                    new Dictionary<Scores, Scores>
                    {
                        {Scores.Love, Scores.Love},
                        {Scores.Fifteen, Scores.Fifteen},
                        {Scores.Thirty, Scores.Thirty},
                        {Scores.Forty, Scores.Forty},
                        {Scores.Deuce, Scores._Advantage},
                        {Scores.Advantage, Scores.Deuce},
                        {Scores.Win, Scores._Invalid},
                        {Scores._Advantage, Scores._Win},
                        {Scores._Win, Scores._Invalid},
                    }},    };
    internal Scores _currentState;
 
    public void Adjust_score(ScoringPositions position)
    {
        _currentState = _stateTransitions[position][_currentState];
        this.Out_CurrentScore(_currentState);
    }

 
    public void In_Deuce()
    {
        _currentState = Scores.Deuce;
    }
 
    public Action<Scores> Out_CurrentScore;
}

Etwas zusammenreißen musste ich mich vielmehr bei den Tests. Ich war schon dabei, möglichst viele Zustandsübergänge zu testen, als ich merkte, dass ich damit “Feedback” verzögerte. Also habe ich nur ein paar essenzielle Transitionen geprüft und mich dann an die Integration aller Bauteile gemacht.

Damit konnte ich dann schon “beweisen”, dass das Gesamtmodell grundsätzlich funktioniert. Zwei Szenarien zeigen Funktionsweise und Umgang mit dem API. Hier zum Beispiel ein Spiel mit Gewinn nach Tie Break:

[Test]
public void Game_with_a_tie_break()
{
    var sut = new Game();
    sut.AddScore(Players.Player1);
    Assert.AreEqual(Players.None, sut.Winner);
    sut.AddScore(Players.Player2);
    Assert.AreEqual(Players.None, sut.Winner);
    sut.AddScore(Players.Player1);
    Assert.AreEqual(Players.None, sut.Winner);
    sut.AddScore(Players.Player2);
    Assert.AreEqual(Players.None, sut.Winner);
    sut.AddScore(Players.Player1);
    Assert.AreEqual(Players.None, sut.Winner);
    sut.AddScore(Players.Player2);
    Assert.AreEqual(Players.None, sut.Winner);
    sut.AddScore(Players.Player1);
    Assert.AreEqual(Players.None, sut.Winner);
    sut.AddScore(Players.Player1);
    Assert.AreEqual(Players.Player1, sut.Winner);
}

Fazit

Ich bin zufrieden mit meinem Vorgehen. Erst modellieren – ja, auch in so kleinen Szenarien – und dann moderat testgetrieben implementieren hat mich schnell, flexibel und sicher gemacht. Alle Funktionseinheiten waren überschaubar und gut testbar. Ich konnte mich auf die Implementation konzentrieren, ohne immer wieder über Refaktorisierungen nachdenken zu müssen.

Es scheint mir ein Nachteil von TDD zu sein, die Modi Implementation und Refaktorisierung so zu verquicken. In der Schrittfolge red-green-refactor sind sie zwar getrennt, doch da diese Schleife immer wieder und schnell in kleinen Schritten durchlaufen werden soll, verschmelzen Implementation (red-green) und Refaktorisierung wie die Einzelbilder eines Films. Als Entwickler muss ich schwebende Aufmerksamkeit für beide haben.

Bei meinem Vorgehen hingegen sind beide Modi klar getrennt. Ergebnis der Modellierung sind Funkionseinheiten, die zunächst mal nicht mehr refaktorisiert werden müssen. Solange ich die implementiere, kann ich mich auf die Implementation konzentrieren. Das entlastet mich mental. Wenn ich damit dann fertig bin – z.B. nach einer Stunde wie in diesem Beispiel –, dann kann ich mich zurücklehnen und den Modus wechseln. Das empfinde ich als Entspannung und wertvolle Phase der Reflexion. Dann habe ich die “Ruhe des Erfolgs” in mir, weil ich ja schon eine Menge geschafft habe.

Ergo: Ich finde weiterhin, dass Implementierung ohne Modellierung harte Arbeit ist und nicht smarte. Man kommt damit auch zum Ziel – aber warum so anstrengen, wenn es auch einfacher geht? TDD ist ne gute Sache – in Maßen. Es ist keine Silberkugel, sondern nur eine Methode unter vielen, die im Zusammspiel zur Produktion von Code genutzt werden sollten. Und somit empfände ich es als künstliche oder gar unrealistische Reduktion, wenn ein Coding Dojo sich nur auf die Anwendung von TDD zur Lösungsfindung beschränken würde.

PS: Danke an Krzysztof Eraskov für seine Hinweise auf Fehler in der Implementierung und Inkonsistenzen im Modell.

Lesenswerte Widerlegung

Eine Allaussage geht um: “Es kann nur sein, wie es ist.”

Unternehmen geht es schlecht, weil der Markt halt so ist, wie er ist; böse Globalisierung. Oder die Mitarbeiter sind halt, wie sie sind; böse Ausbildungsdefizite und Konsumentenhaltung. Daran kann man kaum was ändern. Höchstens sollte man die bisherigen Anstrengungen verstärken: “Nachsitzen”, wenn das Release noch raus muss; mehr Incentives, damit endlich die Softwarequalität steigt; strengere Budgetschrauben, damit alles unter Kontrolle bleibt; weniger Investition in Mitarbeiterfortbildung, weil dadurch wertvolle Zeit zur Kundenwunscherfüllung verloren geht. Usw. usf. ad nauseam.

[Pause]

Mir ist ein wenig übel geworden, da ich diese Litanei geschrieben habe. Die komprimiert und verkürzt zwar, ist aber ein Abbild der Stimmung, die mir in Beratungen, Trainings oder auf Community-Veranstaltungen entgegenschlägt. Früher war vor allem Klagen über Tools oder Microsoft. Veteranengeschichten folgten dann schnell. Wie es damals mit dem C64 war… und die Lochkarten…

Heute scheint das weniger Thema. Vielleicht liegt es auch an meinem neuen Fokus, der nicht mehr auf Technologien, sondern auf Softwarequalität liegt. Heute höre ich Klagen über Arbeitsbedingungen. Immer wieder werden da Mauern beschrieben, gegen die Entwickler laufen, weil sie nicht so dürfen, wie sie wollen. ReSharper darf nicht angeschafft werden: zu teuer. Automatisiertes Testen darf nicht in Anschlag gebracht werden: dafür hat der Kunde nicht bezahlt. Eine Fortbildung darf nicht besucht werden: vier Monate Urlaubssperre, weil die Projekte weit jenseits des Plans liegen.

Dahinter – wie schon gesagt – der Glaubenssatz: Irgendwie kann es nicht anders sein. So ist die Welt halt. Vor allem ist sie kein Wunschkonzert. Dem Schicksal und den Marktgesetzen den ehernen sollte man sich daher ergeben.

Widerlegung

Die Allaussage, der unumstößliche Glaubenssatz wird ad absurdum geführt durch den Nachweis der Existenz auch nur eines Gegenbeispiels.

Wenn es auch nur einmal anders gehen kann, als die Überzeugung diktiert… dann ist die Welt anders als gedacht. Dann ist Hoffnung auch in schlimmsten Zeiten.

Und solche Hoffnung gibt es. Der campus Verlag hat eine mehr als 200 Seite starke Widerlegung des allgegenwärtigen Glaubenssatzes herausgebracht, die Unternehmensverhältnisse könnten kaum anders sein. Ihr Titel: “Nur Tote bleiben liegen” vom Autorenduo Förster und Kreuz.

Gelesen habe ich das Buch, weil Rezensionsexemplare davon im Blog der Autoren an andere Blogger vergeben wurden. Da konnte ich nicht nein sagen ;-)

Gefallen hat mir das Buch aber nicht wegen seiner Kostenlosigkeit für mich. Nein, keine Sorge. Es ist seine “Schwingung”, die gute Laune, der Optimismus, die Hoffnungsfülle, der Gegenentwurf, das Ja zu Neu und Anders, die es für mich zu einer Empfehlung machen.

Ich will deshalb auch gar nicht lange auf den Inhalt eingehen. Man muss es einfach aufschlagen und loslesen. Irgendwo. Jede Seite eine Widerlegung. (Naja, vielleicht übertreibe ich ein wenig ;-) Jede Seite ein Beispiel dafür, dass andere Arbeitsverhältnisse, andere Organisation von Unternehmen möglich ist. Und zwar ganz handfest. Dies ist kein Thesenbuch, sondern eine Beispielsammlung. Förster und Kreuz berichten aus der Realität. Die mag mal fern sein, auf anderen Kontinenten, aber sie ist immer relevant. Auch das ein Effekt der schlimmen Globalisierung. Oder ist die gar nicht so schlimm?

Wer glaub, man können nicht anders umgehen mit der Arbeitszeit oder der Führung oder der Aus-/Fortbildung oder der Kontrolle oder dem Kunden, der schlage dieses Buch auf uns lasse sich eines Besseren belehren. Es geht anders, als die allermeisten Unternehmen es heute tun und meinen nicht anders tun zu können. Irgendwo geschieht schon die kleine oder große Revolution, die Kunden zufrieden macht, Unternehmen prosperieren lässt und Mitarbeiter ganz einfach motiviert.

Internet, Globalisierung, neue Medien, anspruchsvolle Kunden, Digital Natives als Mitarbeiter… das alles und mehr muss keine Bedrohung althergebrachter Ruhe und Ordnung sein. Es liegt an uns, das Glas als halb voll und nicht als halb leer zu betrachten. Die Chancen auf etwas Besseres lauern überall. Das beweist “Nur Tote bleiben liegen” mit einem Feuerwerk an weltweit gesammelten Impressionen.

Im Maul vom Gaul

So empfehlenswert ich das Buch finde, man darf keine Tiefründigkeiten erwarten und auch keine Tipps für die Praxis. Wer von der Lektüre motiviert das Berichtete selbst ausprobieren möchte, ist auf sich gestellt.

Das soll keine Klage sein, sondern nur ein Hinweis, um falsche Erwartungen zu zerstreuen. Förster und Kreuz haben einen hochfrequenten Impulsgeber und Motivator geliefert, kein Handbuch.

Nein, eine tiefergehende Kritik am Inhalt habe ich nicht. Man nehme einfach das Buch für das, was es will und kann. Die knapp 25 EUR für das Hardcover sind nicht zuviel für die Portion Zuversicht, die sich daraus löffeln lässt.

Aber -- denn ohne Aber geht es nicht ;-) -- eines hat mir nicht gefallen. Es ist mir erst nach einiger Zeit aufgefallen, als ich nachfragte, ob es auch eine elektronische Version des Buches gäbe, die ich mit meinem iPad auf den prio.walk hätte nehmen können. Das, was fehlt, ist eben oft schwerer zu erkennen, als das, was da ist.

Nein, ich meine nicht eine eBook-Version oder ein Hörbuch. Beides gibt es.

Ich meine die Abwesenheit von Innovation bei Verlag und Autoren.

Es hat einen Moment gedauert, weil auch ich in Jahrzehnten konditioniert wurde, bei Büchern ersteinmal an Papier zu denken. Aber was für ein Quatsch! Bücher müssen weder aus Papier bestehen noch als zusammenhängendes PDF ausgeliefert werden. Sie müssen auch nicht daheim am Schreibtisch verfasst, zu einem Verlag getragen und dann von einem Vertriebler an den Buchhändler gebracht werden. All das inklusive eBook und Hörbuch ist so Buch 1.0, dass es kaum auszudenken ist. Das ist so un-innovativ und so un-mutig, dass es mich bei diesem Buch erschreckt und enttäuscht hat. Schade.

Warum haben Förster und Kreuz, die als Erfolgsautorenduo genügend Reichweite auch ohne Verlag haben, ihr neues Buch “im stillen Kämmerlein” geschrieben? Sie haben natürlich ein Blog, dessen Inhalte früher oder später wahrscheinlich in der einen oder anderen Weise auch wieder in einem Buch auftauchen werden. Dennoch findet das Schreiben ab von der Öffentlichkeit und somit ab vom Feedback statt.

Wie Buch 2.0 ist dagegen dieser Titel:

Der Autor hat sich schon beim Schreiben dem detaillierten Feedback der Community gestellt, indem er den kompletten Text online veröffentlicht hat – mit der Möglichkeit, absatzweise Kommentare zu geben. Hier ein Auszug:

Das ist Web 2.0 gelebt. Vom Autor wie vom Verlag.

Oder warum haben Förster und Kreuz den potenziellen Rezensenten überhaupt als Default ein Papierbuch angeboten? Warum nicht einen Link auf ein PDF oder einen Kindle-Gutschein? Der ganze Aufwand mit Verpackung und Porto ist überflüssig. Allemal für Rezensenten. Mich interessiert doch nur am äußersten Rand, ob das Papierbuch geschmeidig in der Hand liegt. Auch hier also eine merkwürdige Zurückhaltung in Bezug auf das, was möglich und zukunftsweisend ist.

Wo ist auch das virale Marketing? Warum nicht das Buch launchen im Blog mit einem befristeten kostenlosen Download für jedermann? Von mir aus kann es dabei ja durch Einbinden des Namens des Herunterladenden personalisiert werden.

Oder wenn schon nicht ganz umsonst für eine gewisse Zeit, dann zumindest Zahlen mit einem Tweet. Das ist ja trivial aufzusetzen: http://www.paywithatweet.com/

Nett, dass die Blogeinträge der Rezensenten am Ende von den Autoren zusammengefasst werden. Aber auch das ist letztlich Buch 1.0, weil es auf Zentralisierung setzt.

Oder wie wäre es, das Buch sofort in “Module” zu zerlegen. Und nicht nur dieses Buch, sondern auch die bisherigen von Förster und Kreuz? Dann die Module mit Tags versehen oder in eine Concept Map o.ä. einbinden und ab ins Internet damit.

Dann könnte der Inspiration suchende Leser sich durch das Förster und Kreuz Universum bewegen, online lesen z.B. mit Scribd, sich am Ende sein persönliches Buch aus den interessantesten Modulen zusammenstellen, alles in ein PDF “zusammenschweißen” und das womöglich noch ad hoc in der Auflage 1 für sich z.B. durch www.epubli.de drucken lassen. Das (!) wäre Buch 2.0. Das würde dem amerikanischen Sprichwort “Put your money where your mouth is!” entsprechen.

Aber ich will nicht abschweifen. Dies ist ja nur eine Buchrezension und keine Verlagsberatung ;-) Eine Beratung wäre für viele Verlage wohl auch eher das falsche Mittel, um aus deren Klagehaltung herauszukommen. Da scheint mir eher eine Therapie angezeit. Aber das ist ein anderes Thema…

Also komme ich mal zum Schluss:

“Nur Tote bleiben liegen” finde ich lesenswert, weil kurzweilig und inspirierend. Lockere Schreibe, lockerer Inhalt, macht gute Laune. Einfach mal auf den Wunschzettel für Weihnachten setzen – oder gleich dem Chef schenken ;-)

Denn wer sagt, es ginge nicht anders in den Unternehmen, Erfolg und Zufriedenheit seien nur mit Verstärkung tradierter Maßnahmen – Management 1.0 – zu erreichen oder gar nicht, der findet in diesem Buch einen bunten Strauß an Widerlegungen.

Und ganz vielleicht sind Förster und Kreuz ja beim nächsten Buch auch selbst mutiger. Raus aus der Komfortzone gilt nicht nur für die, über die sie berichten, würd´ ich mal sagen.

Private Methoden einfach testen

In einer Session auf der ADC fragte Stefan Lieser mich heute, ob nicht die dynamischen Features von C# helfen könnten, private Methoden von Objekten zu testen. Erst war ich skeptisch – doch dann half Google. Es geht tatsächlich.

Wer das also dringend tun will, der kann es so wie folgt beschrieben tun. Besonders mag das in Brownfield-Projekten helfen. Denn ansonsten ziehe ich es vor, Privates privat sein zu lassen und nicht direkt zu testen. Und Internes mache ich für Tests mit InternalsVisibleTo zugänglich.

Gegeben dieses Systen under Test:

public class MyFizzBuzzer
{
    public static IEnumerable<string> FizzBuzz()
    {
        return Enumerable.Range(1, 100).Select(FizzBuzzThis);
    }
 
    private string FizzBuzzThis(int i)
    {
        if (IsFizzBuzz(i)) return "FizzBuzz";
        if (IsFizz(i)) return "Fizz";
        if (IsBuzz(i)) return "Buzz";
        return i.ToString();
    }
 
    private static bool IsFizz(int i)
    {
        return i % 3 == 0;
    }
    …

Dann können Sie in Zukunft solche Tests schreiben für die privaten Methoden:

[TestFixture]
public class testMyFizzBuzzer
{
    [Test]
    public void Check_fizz_numbers()
    {
        dynamic sut = typeof(MyFizzBuzzer).Undress();
        Assert.IsTrue(sut.IsFizz(3));
        Assert.IsTrue(sut.IsFizz(12));
        Assert.IsFalse(sut.IsFizz(5));
    }
 
 
    [Test]
    [TestCase(1, "1")]
    [TestCase(2, "2")]
    [TestCase(3, "Fizz")]
    [TestCase(5, "Buzz")]
    [TestCase(15, "FizzBuzz")]
    public void FizzBuzz_number(int number, string expected)
    {
        dynamic sut = new MyFizzBuzzer().Undress();
        Assert.AreEqual(expected, sut.FizzBuzzThis(number));
    }
    …

Dazu ist es nur nötig, dass Sie diese Klassen ins Testprojekt einbinden:

namespace System.Dynamic
{
    public static class UndressObjects
    {
        public static dynamic Undress(this Type type)
        {
            return new UndressedObject(type);
        }
 
        public static dynamic Undress(this object obj)
        {
            return new UndressedObject(obj);
        }
    }
 
 
    public class UndressedObject : DynamicObject
    {
        private const BindingFlags MEMBERS_FLAGS = 
                BindingFlags.Instance | BindingFlags.Static | 
                BindingFlags.Public | BindingFlags.NonPublic;
 
        private readonly object _dressedObject;
 
 
        public UndressedObject(object o)
        {
            _dressedObject = o;
        }
 
 
        public override bool TryInvokeMember(InvokeMemberBinder binder, 
                                             object[] args, out object result)
        {
            var method = TypeOfDressed().GetMethod(binder.Name, 
                                                   MEMBERS_FLAGS, 
                                                   null, 
                                                   GetParameterTypes(args).ToArray(), 
                                                   null);
 
            if (method == null) return base.TryInvokeMember(binder, args, out result);
 
            result = method.Invoke(_dressedObject, args);
            return true;
        }
 
 
        private IEnumerable<Type> GetParameterTypes(object[] args)
        {
            return from a in args select GetActualType(a);
        }
 
 
        private Type GetActualType(object t)
        {
            return (t is ParameterInfo) ? (t as ParameterInfo).ParameterType 
                                        : t.GetType();
        }
 
 
        private Type TypeOfDressed()
        {
            return (_dressedObject is Type) ? (Type)_dressedObject 
                                            : _dressedObject.GetType();
        }
    }
}

Die Idee stammt aus diesem Artikel. Ich hab sie lediglich etwas, hm, fokussiert.

Getestet werden können also private statische Methoden oder Instanzmethoden.

Enjoy your brownfield! ;-)

Wider die Softwarearchaeologie

Auf der prio.conference habe ich mal die Event-Based Components Dru Sellers vorgestellt, einem der Entwickler des MassTransit Busses. Das war ein sehr interessantes Gespräch in vielerlei Hinsicht.

Zu einem Aspekt daraus bin ich dann auch gleich heute zurückgekehrt: der Archaeologie der Software.

Frage: Was ist der Unterschied zwischen dem Steinkreis von Stonehenge und einem Klassendiagramm?

Meine Antwort: Es gibt keinen Unterschied.
Naja, außer dem offensichtlichen

Sowohl der Steinkreis wie das Klassendiagramm sind archaeologische Artefakte. Das heißt für mich hier, sie sind Menschengemachtes mit einem Zweck, den es zu entschlüsseln gilt. Er lässt sich nicht einfach ablesen, sondern muss durch langwieriges Studium rekonstruiert werden. Stonehenge wie Klassendiagramm zeigen nicht an, wie sie funktionieren.

Für Stonehenge mögen Sie mir da auch zustimmen. Beim Klassendiagramm jedoch schütteln Sie sehr wahrscheinlich den Kopf. Dennoch: Ich meine es genau so. Ein Klassendiagramm zeigt nicht, wie eine Software funktioniert. Die Prozesse, für die es steht, sind aus ihm nicht abzulesen.

Ist das nun ein Mangel des Klassendiagramms? Sicher nicht. Sein Zweck ist allein die Darstellung von Struktur, es beschreibt Beziehungen zwischen Funktionseinheiten.

Meine Kritik richtet sich daher nicht an das Klassendiagramm, sondern an die, die es zum Symbol für die rechte Softwareentwicklung gemacht haben.

Unter den Diagrammarten ist es wohl die heute am wohl häufigsten verwendete – aber sie sagt am wenigsten über Software aus. Oder anders: Ein Klassendiagramm kümmert sich nicht um das Wesentliche von Software und doch hält die Branche es hoch als Symbol für zeitgemäße Softwareentwicklung à la Objektorientierung.

Denn was ist das Wesentliche an Software? Seine Funktion, die Verarbeitung von Eingaben zu Ausgaben, EVA. Laufende Software ist ein Prozess, der knetet und transformiert Daten in vielen Schritten.

Wäre es da nicht naheliegend, dass es die vornehmste Aufgabe eines Softwareentwicklers sei, diese Schritte klar sichtbar zu machen, für jedermann nachvollziehbar?

Aber nein, die Softwareentwicklung tut alles, um die Funktionsweise von Software zu verschleiern. Einem Klassendiagramm können Sie nicht ansehen, wie die Prozesse ablaufen, für die es steht. Ebenso sind Paket- und Komponentendiagramme archaeologische Artefakte, die man lange studieren muss, um irgendetwas über die Funktionsweise einer Software herauszubekommen.

Das ist wieder kein Mangel an den Diagrammen, denn sie wollen Funktionsweise auch nicht repräsentieren. Wieder gehören sie aber zu den meist verwendeten Diagrammarten.

Was aber mit den Sequenzdiagrammen? Stehen die denn nicht für Funktionsweise?

Sicher, Sequenzdiagramme beschreiben Funktionsweise. Doch sie tun das in immer noch schwer verständlicher Weise. Das Problem ist die Schachtelung. Sequenzdiagramme visualisieren Callstacks.

Wenn eines aber schwer für Menschen zu verstehen ist, dann ist es Schachtelung. Wie man es dreht oder wendet, wir kommen damit nur schwer zurecht. Simples Beispiel: Beobachten Sie sich beim nächsten Gespräch mit Freunden oder Kollegen. Sie beginnen ein Thema, dann wirft jemand ein anderes Thema auf, ohne dass das erste abgeschlossen wäre… was nun? Sie werden entweder dafür sorgen, dass das erste Thema beendet wird, bevor Sie mit dem zweiten weitermachen. Oder Sie werden das zweite aufgreifen – und am Ende das erste nicht zuende führen.

Die dritte Alternative – Sie behandeln das zweite Thema als Einschub und kehren am Ende zurück zum ersten Thema – werden Sie nur sehr selten realisieren. Denn dafür braucht es ein gutes Gedächtnis und einigen Willen. Von einem weiteren Einschub während der Behandlung des zweiten Themas ganz zu schweigen.

Schachtelungen sind schwer zu verstehen. So ist das nun mal.

f(g(h(x)));

ist schwerer zu verstehen als

h(x).g().f();

oder

var rh = h(x);
var rg = g(rh);
f(rg);

Und so sind Sequenzdiagramme ebenfalls schwer zu verstehen. Sie zeigen zwar das Wesentliche einer Software, doch sie helfen nur suboptimal beim Verständnis, weil sie immer noch dem von-Neumann-Modell von Software folgen.

Vier der hauptsächlich verwendeten Diagramme der Softwareentwicklung verschleiern damit, worum es eigentlich geht. Undv om Code wir gar nicht erst reden. Aus dem Funktionsweise ablesen zu wollen, ist ein mühseliges Unterfangen, wie jeder bezeugen kann, der schonmal an Brownfieldcode arbeiten musste.

Das ist es noch einfacher, ein Sequenzdiagramm zu lesen. Nicht umsonst wurden die auch entwickelt, nämlich als Analyseinstrumente und nicht als Entwurfswerkzeuge.

Und das bedeutet?

Die Softwareentwicklung leidet unter selbstverschuldeter Verschleierung. Mit jedem Diagramm, das nicht die Funktionsweise leicht verständlich offenbart, mit jeder Zeile Code, die einschachtelt, macht sie es Softwareentwicklern schwer, das Wesentliche von Code zu verstehen. Sie erzwingt wieder und wieder, Softwarearchaeologie zu betreiben. Wohl dem, der dann noch mit den “Altvorderen” sprechen kann, die ein Artefakt hinterlassen haben.

Hochgepriesene visuelle und nicht visuelle formale Sprachen helfen also nicht, die Prozesse, die als Problemlösungen erdacht und dann in ihnen codiert wurden, anschließend aus ihnen abzulesen.

Das kann nicht anders beschrieben werden als Vernichtung von Information. Dadurch entsteht ungeheurer betriebswirtschaftlicher und am Ende auch volkswirtschaftlicher Schaden. Um den in Zukunft zu vermeiden, müssen wir den Fokus ändern.

Software ist fundamental dynamisch. Sie tut etwas. Das ist ihr ganzer Zweck. Sie ist kein Regal oder Bild, sondern eine Maschine. Dafür braucht sie Input, Daten. Aber noch wichtiger ist, wie diese Daten verarbeitet werden. Verständliche Beschreibungen von Funktionsweisen haben deshalb für mich Vorrang vor Datenbeschreibungen.

Am Ende müssen beide sein, doch die Funktionalität ist wichtiger, weil sie der Zweck von Software ist. Daten gibt es durchaus auch ohne Software. Funktionalität nicht. Dafür wird sie entwickelt.

Und wie sollte die geforderte Beschreibung von Funktionalität aussehen?

Sie sollte visuell sein und Schachtelung nur zum Zwecke der Abstraktion verwenden.

• Eine visuelle Beschreibung ist leichter zu überschauen als eine textuelle derselben Funktionalität – außer in trivialen Fällen.
• Und Abstraktion ist nötig, um Kompliziertes überhaupt überschaubar zu machen. Es kann dann auf verschiedenen Abstraktionsebenen dargestellt werden.

Eine visuelle Sprache, die die Funktionsweise einer Software auf verschiedenen Abstraktionsebenen darstellen kann, sollte das Hauptwerkzeug des Softwareentwicklers sein.

Nur so vermeiden wir teure Softwarearchaeologie. Davon bin ich fest überzeugt, auch wenn damit zwei Jahrzehnte Objektorientierung als Verirrung dastehen mögen. Denn die de facto Objektorientierung hat nie den Prozess im Fokus gehabt, sondern immer die Struktur.

Dass es die auch geben muss, ist unzweifelhaft. Aber die Objektorientierung hat sie auf ein Podest gehoben und angebetet. Jedes Domänenobjektmodell legt dafür lebendiges Zeugnis ab.

Die Zukunft der Software liegt daher aus meiner Sicht nicht in der Objektorientierung, sondern einzig in der Prozessorientierung. Ohne Fokus auf den Prozess und seine einfache Implementierung wie verständliche Darstellung auf verschiedenen Ebenen – von kleinen Funktionen bis zu großen Services –, kommen wir nicht aus dem Brownfieldmatsch heraus.

PS: Es gibt natürlich Hoffnung. Aktivitätsdiagramme, Datenflussdiagramme oder BPMN sind Mittel, um Prozesse darzustellen. Wir müssen ihnen nur den gebührenden Platz im Zentrum der Softwareentwicklung einräumen. Und natürlich gehören auch Event-based Components dorthin.

Rein in die Matrix!

Sind Event-Based Components (EBC) ne super Sache oder “krank” (wie gerade in einem Diskussionsforum behauptet wurde)? Tja… ich glaube natürlich, dass sie ziemlich cool sind und was bringen. Der Entwurf von Software wird damit einfacher, die Wartbarkeit, äh, Evolvierbarkeit steigt, die Verständlichkeit ebenfalls und automatisierte Tests brauchen keine Mock-Frameworks mehr.

Es gibt auch eine kleine Community um EBC, die dasselbe denkt. Die Majorität der Entwickler ist jedoch – wenn sie denn EBC überhaupt kennen – mindestens indifferent. Ist es deshalb aber besser, weiterzumachen wie bisher? Oder wären EBC ein Gewinn für sie? Wer hat nun recht? Und in welchen Fällen?

Ich glaube, da können wir Überzeugte uns noch lang den Mund fusselig reden und schreiben, am Ende zählt immer nur eine Gegenüberstellung. Wer die aber nicht kundig selbst macht oder machen kann, der wird nicht überzeugt. Also muss die Gegenüberstellung anders laufen. Sie muss präsentiert werden.

Deshalb möchte ich ein Angebot machen:

Wer glaubt, EBC brächten nichts oder würden irgendwie die Softwareentwicklung sogar noch behindern, der kann sich mit seinem Ansatz zur Planung von Software im fairen, harten aber herzlichen Wettstreit mit mir messen. Wie wäre das?

Das ist dann natürlich kein wissenschaftliches Experiment. Dennoch ließe sich was lernen. Auf beiden Seiten. Da bin ich mir sicher.

Ich schlage vor, dass ein solcher “Shoot Out” in einer .NET User Group stattfindet. Sicher gibt es eine, die den Event hosten würde. Diese User Group würde beiden Parteien – EBC und Non-EBC – eine Aufgabe stellen, die die dann in einer Timebox umsetzen müssen. Zeitaufwand ca. 3 Stunden von der Anforderungspräsentation bis zur Auslieferung.

Am Ende würde mit vorgefertigten automatisierten Akzeptanztests geprüft, inwieweit die Anforderungen erfüllt sind. Zwischendurch – vielleicht nach 1,5 bis 2 Stunden – würden noch neue Anforderungen nachgereicht. Und natürlich würde jede Partei ihre Lösung in einem Review vorstellen.

Die Akzeptanztests machen eine Aussage über die Korrektheit des Codes, den ein Ansatz produziert. Die Erfüllung auch der nachgereichte Aufgabe machen eine Aussage über die Fähigkeit, den Code zu verändern, d.h. die Evolvierbarkeit.

Die Größe der Aufgabe ist fast egal, würde ich sagen. Sie muss nicht mal komplett zu schaffen sein. Es reicht, wenn die Zahl der Akzeptanztests nicht zu klein ist und in der Timebox davon eine ganze Reihe schaffbar sind. Dann ließen sich sich Unterschiede im Erfüllungsgrad ablesen. Die nachgereichte Anforderung wäre allerdings eine Pflichtanforderung, die zumindest angegangen werden muss.

Was der Ansatz der anderen Partei ist, ist egal. Sie sollte nur mit C# programmieren. Ob dann streng OOP oder Cowboy Programmierung oder Komponentenorientierung oder Funktionale Programmierung oder sonstwas gemacht wird… alles ist recht.

Hm… einen Aspekt würde ich allerdings noch gern reinbringen: Entwicklung im Team. Wäre also vielleicht gut, wenn auf jeder Seite 3 Leute stünden. Das ist etwas realitätsnäher und ließe größere Aufgaben zu.

Wäre das nicht mal ein Coding Dojo der besonderen Art? Ein “Shoot Out” Dojo oder Contest Dojo.  EBC gegen den Rest der Welt :-)

Wer nimmt die Herausforderung an?