Nachdem in den Blogs von Steffen und Ilker bereits über verschiedene Aspekte von Dojos diskutiert wurde habe ich den Eindruck, dass ein Aspekt der mir persönlich wichtig ist, bei diesen Diskussionen noch nicht beleuchtet wurde oder sogar misverstanden ist. Es geht mir dabei um den dargestellten Konflikt zwischen den “Codern” und den “Knoblern”. Dabei beziehe ich mich konkret auf das Dojo im Rahmen der dotnetpro powerdays in München. Ich und andere aus der “letzten Reihe” haben in diesem Dojo den Einwand gebracht, wir mögen doch vor dem ersten Test ein klein wenig planen. Leider konnte ich mich mit diesem Vorschlag nicht durchsetzen. Dabei sehe ich folgende Probleme:
- Die Beschlüsse wurden per Abstimmung herbeigeführt. Das halte ich für suboptimal. Zum einen, weil die Alternativen nicht inhaltlich diskutiert wurden. Dadurch konnten diejenigen, die den Vorschlag ablehnten, nicht wirklich deutlich machen, aus welchem Grund sie ihn ablehnen. So wurde ich am Lernen gehindert. Denn selbstverständlich kann ich ja auf dem falschen Dampfer sein. So musste ich mich auf das Experiment, direkt mit einem Test zu beginnen einlassen. Das Ergebnis ist bekannt. Ich war nicht damit zufrieden. Und ich bin immer noch überzeugt, dass wir mit etwas mehr Planung weiter gekommen wären. Dazu später mehr. Zum anderen halte ich Abstimmungen in Dojos für suboptimal, weil es neben dem Konsens noch den Konsent gibt. Eine Grundidee dabei: so lange niemand etwas wirklich gewichtiges gegen einen Vorschlag einzuwenden hat, wird er angenommen. Damit wird erreicht, dass Minderheiten nicht per Abstimmung ohne Argumente abgebügelt werden. Vielleicht gab es ja inhaltlich gewichtige Einwände gegen etwas mehr Planung. Ich habe sie bislang leider nicht erfahren.
- Ich war nicht konsequent genug, hätte versuchen sollen besser darzulegen worum es mir geht. Einen Schuh muss ich mir selber anziehen: ich habe vielleicht nicht wirklich deutlich gemacht, was ich mit “Planung” genau gemeint habe. Es wäre einfach gewesen, denn ich selbst habe mir eine Skizze angefertigt. Diese hätte ich auch an die Flipchart malen können. Vielleicht wäre dann klar geworden, dass es mir nicht um Big Design Upfront geht.
Was ich hier mit “Planung” meine, möchte ich deutlich abgrenzen vom Begriff der “Knobler”. Bei der Kata BankOCR gab es nichts zu knobeln. An den wenigen Diskussionen die sich inhaltlich mit der Lösung der Aufgabe befassten, konnte man erkennen, dass ganz
offensichtlich alle Beteiligten eine Vorstellung ihres Lösungswegs im Kopf hatten. Mir geht es darum, diese diffuse Vorstellung explizit zu Papier zu bringen. Zum einen, um mir Klarheit darüber zu verschaffen und darüber nachzudenken, ob der gewählte Weg zum Ziel führt. Zum anderen, um in der Gruppe eine gemeinsame Diskussionsbasis zu schaffen. Meine SKizze war in wenigen Minuten angefertigt. Das nebenstehende Bild zeigt meine Skizze vom Dojo in München. Ich glaube nicht, dass eine solche Skizze der Gruppe schwer gefallen wäre oder sie lange aufgehalten hätte. Durch eine solche Skizze wäre aber jedem klar gewesen, wo wir stehen, wovon wir sprechen. Und wir hätten anhand der Skizze überlegen können, wo wir mit dem ersten Test beginnen. Stattdessen wurde munter drauf los gecoded und irgendwann erkannt, dass wir offensichtlich von “innen nach außen” entwickelt haben.
Ich möchte betonen, dass ich keinen Konflikt sehe, zwischen der testgetriebenen Entwicklung und einer Planung vorab. Und ich spreche im Kontext dieser Kata nicht von Architektur. Es geht um das Design der Lösung, um die Zerlegung des Problems in Teilprobleme. Meinen Code entwickle ich ausschließlich testgetrieben. Völlig egal, ob es sich dabei um Produktionscode oder Beispiele für Artikel oder Vorträge handelt. Der einzige Unterschied zur Vorgehensweise beim Dojo ist, dass ich vorher eine Skizze mache. Immer! Denn in Zeiten, in denen ich das nicht gemacht habe, hatte ich am Ende ein Ergebnis, mit dem ich nicht ganz zufrieden war. Seit ich vorher plane, hat sich meine Codestruktur deutlich verbessert. Ferner kann ich dann viel entspannter loslegen, weil ich stehts weiß, wo ich stehe. Ferner ist die Qualität der Tests besser, da Teilaspekte isolierter getestet werden. Da ich mir nicht sicher war, ob meine Beobachtung richtig war und das bessere Ergebnis an der Vorplanung lag, habe ich zeitweise die Planung wieder weggelassen. Heute bin ich mir sehr sicher, dass ich mit Planung besser entwickle als ohne.
Damit möchte ich nun nicht behaupten, dass dies der einzig richtige Weg sei. Ich möchte lediglich darauf hinweisen, dass meiner Einschätzung nach in der einschlägigen Literatur zu TDD die Planung zu kurz kommt. Und die von mir besuchten bzw. durchgeführten Dojos haben mir ebenfalls gezeigt, dass es ohne Planung schwieriger ist, zum Ziel zu kommen. Einen weiteren Hinweis geben mir die Seminare und Workshops die ich in den letzten Monaten, meist gemeinsam mit Ralf Westphal, gehalten habe. Auch dort hat sich die Planung als vorteilhaft gezeigt.
Die Planung auf einem Stück Papier hat gegenüber dem “sofort loscoden” meiner Einschätzung nach den Vorteil, dass es ein nicht-linearer Prozess ist. Auf dem Papier kann ich wild springen, meinen Ideen freien Lauf lassen, Dinge verbinden, schnell etwas ergänzen oder auch wieder wegstreichen. Ganz anders ist die Arbeit an einem Test. Dies ist ein linearer Prozess. Ich bin gezwungen, den Code in einer bestimmten Reihenfolge einzugeben. Bevor ich überhaupt eine Zeile tippen kann, muss mindestens ein Projekt aufgesetzt werden. Das mag in trivialen Beispielen ebenso trivial sein, oft ergibt sich die Projektstruktur aber erst aus der Planung. Die Vorgehensweise beim TDD ist linear. Ohne dass ich vorher in einem kreativen nicht-linearen Prozess Ideen gesammelt und sortiert habe befinde ich mich in diesem linearen Prozess gefangen. Denn ich habe ständig die Sorge, dass ich eigentlich nicht genug von der möglichen Lösung weiß. Und oft genug kommen Probleme um die Ecke, die einen zur Umkehr zwingen. So war es auch beim Dojo in München. Wir haben irgendwann gemerkt, dass etwas nicht stimmt. Diese Erkenntnis hat mir meine Skizze bereits viel früher gebracht.
Nun will ich aber nicht nur Behauptungen aufstellen und von Alternativen schreiben, sondern auch anbieten, es mal anders zu versuchen. Der genaue Rahmen ist mir noch nicht klar, aber es wird Gelegenheit dazu geben, mal ein Dojo mit Planung durchzuführen. Ich werde rechtzeitig darauf hinweisen.
erkennen. Der liegt nämlich nicht nur in einer verbesserten Korrektheit, sondern vor allem in einer besseren Evolvierbarkeit. Das liegt daran, dass TDD einen starken Einfluss darauf hat, wie man seinen Code strukturiert. Denn es entsteht, oft wird behauptet ganz von alleine, gut testbarer Code. Meiner Erfahrung nach verbessert sich die Qualität des Codes zwar nicht so ganz von alleine, aber ich bestreite nicht, dass schon allein die Reihenfolge, erst Test, dann Implementierung einen positiven Einfluss auf die Codequalität hat. Deutlich besser wird die Qualität durch einen vorgelagerten Planungsschritt. Damit rede ich nicht dem “Big Design Upfront” das Wort, sondern ich meine, als Entwickler müssen wir uns die Zeit nehmen, vor dem Codieren ein paar Skizzen auf Papier zu machen.
Das Bild beschreibt TDD als Prozess. Was mir sofort auffiel ist die Tatsache, dass es auf dem “Repeat” Pfad vom Refaktorisieren zurück zum nächsten Test keine Entscheidung gibt. Zwischen Test und Implementierung liegt eine Entscheidung: man geht erst zur Implementierung über, wenn man einen Test geschrieben hat, der fehlschlägt. Auch beim Übergang von der Implementierung zum Refaktorisieren kommt es zu einer Entscheidung. Diesmal geht es erst weiter zum Refaktorisieren, wenn alle Tests erfolgreich verlaufen. Doch dann die Überraschung: vom Refaktorisieren geht es einfach so wieder zurück zum nächsten Test. Da stellt sich mir doch die Frage, wann bin ich denn mit dem Refaktorisieren fertig? Und in der Tat taucht diese Frage bei Entwicklern in der Praxis ebenfalls auf, ohne dass sie sich den Prozess anhand eines solchen Bildes bewusst machen. Und auch beim Coding Dojo in München im Rahmen des dotnetpro-powerday kam kurz die Diskussion auf, ob denn nach der Implementierung nicht refaktorisiert werden solle. Die Frage ist also ganz offensichtlich nicht nur, wann bin ich fertig mit dem Refaktorisieren, sondern soll ich überhaupt refaktorisieren?
