So wird ein Coding Dojo zu einer ernstzunehmenden Lernveranstaltung

Was sich im Ruby- und Java-Umfeld schon lange etabliert hat, findet langsam auch in unserer (PHP- & JavaScript-) Welt seinen Platz- Coding Dojos! Die Idee vom gemeinsamen Programmieren in der Form eines Coding Dojos kommt vom Autor von The Pragmatic Programmer, David Thomas. Er sagt: „Developers should practise on small, not job related code base repeatedly so that they can master their profession like musicans“. Der Autor möchte dabei nicht zur Nutzung des JavaScript-Toolkits Dojo anregen, sondern vielmehr zum gemeinsamen Coden an kleinen Aufgaben, den Katas. Folgt die PHP- und JavaScript Community einem Hype aus dem Umfeld anderer Programmiersprachen oder kann wirklich jeder etwas in einem Coding Dojo lernen? Dieser Artikel erklärt, was es mit Coding Katas auf sich hat und wie ein Coding Dojo gestalltet werden sollte, damit jeder Teilnehmer dabei etwas lernen kann.

Wie sollte ein erfolgreiches Coding Dojo ablaufen?

Um ein Coding Dojo veranstalten zu können, wird nicht viel benötigt. Der Veranstaltungsraum sollte genügend Platz für alle Teilnehmer haben, über ein Whiteboard verfügen und im Optimalfall mit einem Beamer ausgestattet sein. Der Inhalt eines Coding Dojos ist immer eine Code Kata, an dieser kleinen Aufgabe wird im Pair Programming (Driver und Navigator) und Test Driven programmiert, sprich immer zwei Entwickler, kein Code ohne Test und immer Test first! Nach der Begrüßung durch den Moderator erfolgt eine kleine Abstimmung an welcher Kata programmiert werden soll. Anschließend geht es schon in die Umsetzungsphase. Dabei startet ein Paar mit der Programmierung und nach einem definierten Zeitintervall (3 – 8 Minuten) findet ein Wechsel im Pair statt- der Navigator wird zum Driver (er übernimmt also die Tastatur), ein neuer Navigator wechselt ins Pair und der vorherige Driver wechselt in die Zuschauerrolle. Was sich ein wenig wie die Reise nach Jerusalem anhört wird auch öfters als Randori bezeichnet. Sind mehrere Teilnehmer im Coding Dojo sollte spätestens nachdem jeder Teilnehmer einmal Driver und Navigator war eine Retrospektive erfolgen, ansonsten sollte spätestens nach 25min. eine Retrospektive abgehalten werden.

Mit einer Kata kann an seinen Programmierfähigkeiten gearbeitet werden- immer und immer wieder

Ich habe bereits schon öfter von einer Code Kata gesprochen, doch was ist das überhaupt? Das Wort Kata bedeutet soviel wie „Übung“ und wird oft in fernöstlichen Kampfsportarten gebraucht. Dort trainieren die Kämpfer ihre Schlagabfolgen und Griffe so lange, bis die Sequenz in Fleisch und Blut übergegangen ist und im Falle eines Kampfes ohne lange zu überlegen ausgeführt werden kann. Eine Code Kata ist für uns Entwickler eine Aufgabenstellung die ebenfalls immer wieder und wieder ausgeführt werden kann. Eine Kata ist begrenzt im Umfang und lösbar für jeden Entwickler, aber im Coding Dojo ist es nicht wichtig Probleme zu lösen, auch nicht welches Framework ich verwende- das einzig wichtige sind die Akteure und das WIE ich die Probleme angehe.

Test Driven Development und Baby Steps sind fester Bestandteil eines Coding Dojos

Die Lösung einer Kata soll immer im Test Driven Development (Stichwort „Red, Green, Refactor“) erfolgen; dabei wird in kleinen Schritten vorgegangen, den Baby Steps. Das hat zwei entscheidende Vorteile, durch TDD bekommt man klares, unmittelbares Feedback- gemachte Fehler werden sofort erkannt (Fail soon- learn fast!). Und durch die Entwicklung in kleinen einfachen Schritten schreibt man nicht nur sauberen sondern auch vollwertigen Quellcode.
Ein paar Tipps an dieser Stelle:

• Der TDD-Zyklus sollte am besten nicht länger als zwei Minuten dauern.
• Ein bekanntes Vorgehen beim Pair Programming im Coding Dojo ist Come Green- Go Green! d.h. man kommt zu fehlerfreiem Code und verlässt ihn auch wieder im fehlerfreien Zustand.
• Papier und Bleistift sollten Bestandteil eines jeden Coding Dojos bzw. einer TDD-Session sein, Design-Phasen sind keine Schande.
• Zum Refactoring: Pro Refactoring soll nur eine Designentscheidung getroffen werden.

Die Komplexität der Kata bestimmt die Zeit im Randori

Ein wichtiger Faktor im Randori ist die Zeit! Gerade für Teilnehmer die das erste mal ein Coding Dojo besuchen ist es nicht einfach vor mehreren Leuten zu coden. Da hilft es, den Entwickler aufzuzeigen, dass die Zeit im Randori so bestimmt wird, dass nicht zu viel kaputt gemacht werden kann oder im Umkehrschluss, dass kein Super-Entwickler die Kata alleine lösen kann. ABER: je komplexer die Kata umso mehr Zeit ist notwendig!! Wählt man eine zu kurze Zeitspanne, sind zu viele unüberlegte Tests sind das Resultat, man schweift immer mehr vom Pfad ab. Eine Runde sollte zwischen 3 und max. 8 Minuten dauern, dann sollte ein Wechsel im Pair stattfinden.

Nach dem Coden muss eine Retrospektive erfolgen

Aus gemachten Fehlern sollte man seine Lehren ziehen! Als Ergebnis zählt auch die Erkenntnis, dass man etwas falsch gemacht hat! Somit kann man seine Schwächen herauszufinden und an ihnen arbeiten.

In der Retrospektive helfen die Fragen:

• Was haben wir gut gemacht?
• Was haben wir gelernt?
• Was wollen wir das nächste mal anders machen?
• Was stellt uns immer noch vor Herausforderungen?

Typische Erkenntnisse aus einem Coding Dojo könnten sein:

• Tests waren zu lange rot
• zu große Schritte zwischen den Tests (keine Baby Steps)
• falsches Domainverständnis (keine Designphase)

aber auch:

• wir kennen nun die Refactoring-Potentiale und den richtigen Zeitpunkt dazu
• Design-Pattern können angewendet werden

Mit einem Motto für das Coding Dojo lernt jeder etwas

Als häufiges Gegenargument für Coding Dojos hört man oft, dass nur unerfahrene Entwickler von dieser Art des gemeinsamen Programmierens profitieren können. Diesem Argument kann man entgegentreten indem für das Coding Dojo ein bestimmtes Motto/Thema gewählt wird z.B. SOLID, Design Pattern, Pair Programming Training, Merciless Refactoring (wie weit macht Refactoring Sinn?) oder Break & Re-Enter the TDD Cycle, Domain Driven Design, oder einmal ohne Testframework (No Testing Tools), oder ohne Maus, nur mit Shortcuts…. Den Variationen sind dabei keine Grenzen gesetzt.

Zusammenfassung: Lerneffekte aus einem Coding Dojo

Jeder sollte von einem Coding Dojo nach Hause gehen und das Gefühl haben etwas gelernt zu haben. Was konnte ich bis jetzt aus den Coding Dojos an denen ich teilgenommen habe lernen?

• gemeinsam programmieren fördert die Kommunikation und zeigt auf, dass Pair Programming unheimlich effektiv sein kann.
• gemeinsam besser Entwickeln (Stichwort Collective Code Ownership): es wird gemeinsam eine Lösung erarbeitet, man beschäftigt sich mit unterschiedlichen Coding Styles(z.B. Formatierung, Namensgebung, Design Pattern), gemeinsame Code Guidelines.
• Pair Programming: Viele Besonderheiten des Pair Programmings können im Coding Dojo gelernt und geübt werden.
• Test Driven Development kann optimal ausprobiert und trainiert werden.
• Refactoring: Man lernt vieles über Refactoring (-Tools) und den richtigen Zeitpunkt dafür.
• YAGNI: durch die Umsetzung in Baby Steps konzentriert man sich auf das Wesentliche, jede Zeile Code soll einen Wert schaffen.
• Done is better than perfect: bessere Fokusierung, weniger Grundsatzdiskussionen, „einfach mal machen!“
• Evaluierung: Coding Dojos sind die optimale Gelegenheit um andere Setups auszuprobieren.

Ich hoffe, ich konnte mit diesem Artikel aufzeigen, dass ein Coding Dojo durchaus eine ernstzunehmende Lernveranstaltung ist. Wie komme ich zu einem Coding Dojo? Mayflower veranstaltet in regelmäßigen Abständen an beiden Standorten in München und Würzburg ein Coding Dojo.