brainbits Blog

Coding Dojo bei brainbits

Phillip Look02.08.2016Anwendungsentwicklung • Code • Teamwork
Coding Dojo kurz erklärt

Die Begriffe „Kata“ und „Dojo“ stammen aus dem asiatischen Kampfsport. Dort bezeichnet Kata eine Übungsform, bei der meist gegen einen imaginären Gegner gekämpft wird. Eine Kata dient dazu, Bewegungsabläufe und Kampftechniken einzuüben und zu verfeinern. Ein „Dojo“ (japanisch „Ort des Weges“) ist der Übungsraum, in dem die Kampfsportler ihre Übungen durchführen.

Was ist eine Coding Kata?

Eine „Coding Kata“ ist üblicherweise eine einfache, kleine, in sich abgeschlossene Programmieraufgabe, mit der man als Software-Entwickler Programmiertechniken einüben und vertiefen kann. Dabei kommt es nicht darauf an, eine lauffähige Software zu entwickeln, - es steht vielmehr der Weg bzw. die Technik im Mittelpunkt, mit der die Aufgabe gelöst wird.

Neben Katas für reine Coding-Aufgaben (von kleinen Function-Katas über Class-Katas und Library-Katas bis hin zu großen Application-Katas) gibt es Architecture Katas, bei denen der Architekturentwurf im Fokus steht, und Agility Katas, bei denen die inkrementelle Anpassung und Erweiterung der Aufgabe wichtig ist.

Was ist ein Coding Dojo?

Bei einem „Coding Dojo“ treffen sich mehrere Entwickler, um gemeinsam eine oder mehrere Coding Katas durchzuführen. Im Fokus des Dojos steht der Gemeinschaftsaspekt und die Möglichkeit von anderen zu lernen - sei es, dass man sich Programmiertechniken abschaut oder den Umgang mit der Entwicklungsumgebung verbessert. Und natürlich geht es darum, Spaß miteinander zu haben.

Wie kann ein Coding Dojo ablaufen?

Die wohl gebräuchlichste Form ist das „Randori“: Dabei können sich alle Anwesenden an der eigentlichen Entwicklung beteiligen. Die Beteiligung hängt vor allem von der tatsächlichen Gruppengröße ab. Üblicherweise gibt es – vergleichbar mit dem Pair-Programming – zwei Hauptakteure: einen Driver und einen Navigator. Der Driver hat die Macht über die Tastatur und der Navigator ist für die Übersicht über die Implementierung und die umzusetzenden Testfälle verantwortlich. Alle anderen Beteiligten verfolgen das Geschehen und können Tipps und Vorschläge zur Umsetzung beisteuern. Hierbei ist es die Aufgabe des Moderators, dafür zu sorgen, dass die aufkommende Diskussion die Entwicklung vorantreibt und nicht behindert. Die Rollen der Teilnehmer können während des Randori gewechselt werden.

Eine weitere Form des Coding Dojo ist das „Code Retreat“ (engl. für Rückzug oder Zufluchtsort). Es dauert üblicherweise einen ganzen Tag und bietet im Gegensatz zum Randori die Möglichkeit, sich einer größeren Aufgabenstellung zu widmen. Die Coding Sessions werden regelmäßig durch kurze Retrospektiven unterbrochen, in denen man den Lösungsweg besprechen und die bisherige Arbeitsweise reflektieren kann.

Bei einer „Prepared Kata“ bereiten sich üblicherweise ein oder zwei Personen auf eine Kata vor und präsentieren ihren Lösungsansatz dann live während des Coding Dojos vor den anderen Entwicklern. Für die Teilnehmer besteht die Hauptaufgabe darin, dem Lösungsansatz und den Entwicklungsschritten der Vortragenden zu folgen. So ist es auch auf Konferenzen oder bei Workshops möglich, einer großen Teilnehmerzahl neue Lösungswege oder den Umgang mit neuen Entwicklungswerkzeugen oder -methoden zu präsentieren. Einige Entwickler stellen auch Screencasts der Durchführung ihrer Coding Katas als Videos ins Internet.

Wie kann eine einfache Kata spannend bleiben?

Ist eine Kata sehr simpel oder hat man eine Kata schon sehr oft gelöst, gibt es Variationsmöglichkeiten bei der Durchführung der Kata, so dass die Lösung der eigentlichen Aufgabe in den Hintergrund tritt.

  • Vor der Programmierung eine Testliste erstellen. Dies leitet den Fokus weg von der Umsetzung auf die Planung der Aufgabe, wie man sie z. B. für das Test-Driven-Development benötigt.
  • Nur mit der Tastatur arbeiten. So setzt man den Fokus auf den Umgang mit der Entwicklungsumgebung.
  • Nur einen einfachen Texteditor verwenden. Um sich mit vim, nano, joe oder Notepad vertraut zu machen.
  • Keine Conditionals verwenden. Also keine if-then-else, switch-case oder ?:-Konstrukte benutzten. Um die Logik der fehlenden Conditionals zu ersetzen, muss vor allem auf die Klassenarchitektur geachtet werden. So  können bereits an einfachen Aufgaben Design-Patterns eingeübt werden, die im produktiven Code erst bei viel komplexeren Aufgaben in Betracht gezogen werden würden.
  • Nicht sprechen. Driver und Navigator dürfen sich nur über das Schreiben von Code verständigen.
  • Wechsel zwischen Driver und Navigator. Es ist auch sinnvoll den Wechsel der beiden Hauptakteure zu systematisieren. Ein Wechsel könnte immer dann erfolgen, wenn der Driver den nächsten fehlschlagenden Test geschrieben hat.
  • Einwechseln bisher unbeteiligter Teilnehmer. Bei einem Randori mit mehreren „Zuschauern“ ist es möglich, diese auch mit Driver und Navigator durchzutauschen.

Coding Dojo im brainbits-Selbsttest

Nachdem in letzter Zeit einige Team-Kollegen im Rahmen von User Groups oder bei den Symfony Hack-Days an Coding Dojos teilgenommen hatten, kam der Wunsch auf, auch bei brainbits ein Coding Dojo durchzuführen.

Unser erstes Coding Dojo sollte auf praktische Mitarbeit aller Teilnehmer fokussiert sein und nicht zuviel Zeit in Anspruch nehmen. Daher entschieden wir uns für ein zweistündiges Randori, bei dem jeweils teamübergreifende Zweier- oder Dreier-Gruppen zusammen an einer Lösung arbeiten sollten.

Angesichts des engen Zeitrahmens entschieden wir uns für die sehr einfache FizzBuzz-Kata. Bei der FizzBuzz-Kata geht es darum, nach einem Regelsatz zu einer Zahl eine Ausgabe zu erzeugen. In der Basisversion der Kata gibt es vier Regeln:

  • Ist die Zahl durch 3 teilbar, lautet die Ausgabe Fizz.
  • Ist die Zahl durch 5 teilbar, ist die Ausgabe Buzz.
  • Ist die Zahl durch 3 und 5 teilbar, lautet die Ausgabe FizzBuzz.
  • Ansonsten wird die Zahl selber ausgegeben.

Wir wollten im Dojo als ersten Schritt den FizzBuzz-Algorithmus quick-and-dirty umsetzen. So konnte sich jedes Dojo-Team in die Aufgabenstellung hineindenken. Damit keine Zeit zur Einrichtung der Entwicklungsumgebung und für den Aufbau einer lauffähigen TDD-Umgebung verbraucht wird, wurde der Source-Code-Rahmen inklusiver einfacher Tests als Github-Projekt bereitgestellt. Damit hatten die Teams nur noch die Aufgabe, das Projekt auszuchecken und eine einzige Methode mit der FizzBuzz-Logik zu füllen.

Für den Hauptteil des Coding Dojos wurde die Aufgabenstellung folgendermaßen angepasst:

  • Die FizzBuzz-Regeln bleiben vorerst unverändert.
  • Bei der Implementierung soll die leichte Erweiterbarkeit im Auge behalten werden, so dass die Architektur auch bei einer Erweiterung der FizzBuzz-Regeln so wenig wie möglich angepasst werden muss. (Open-Close-Prinzip).
  • In jeder Klasse darf nur eine Schleife (for, foreach, while, ...) oder eine Condition verwendet werden (if, switch, ?:, ...), so dass auch schon für dieses einfache Problem mehrere Klassen angelegt werden müssen.
  • Die Umsetzung soll test-driven erfolgen.
  • Die Rollen (Driver, Navigator und in Dreier-Teams der Zuschauer) sollen ständig rotiert werden.

Zwei von vier Teams entschieden sich, die Aufgabe in PHP zu lösen, die anderen beiden Gruppen wählten JavaScript. Nach dem einführenden Vortrag stellte die erste schnelle Umsetzung kein Problem dar und war auch zügig erledigt. So stand für das Refactoring mit den angepassten Vorgaben noch ausreichend Zeit zur Verfügung. Interessanterweise ging die Entwicklung bei allen vier Teams zu Beginn in die gleiche Richtung. Erst nach einiger Zeit entwickelten sich die Lösungswege leicht auseinander.

Eines der JavaScript-Teams wollte sich von den zu erwartenden objektorientierten Lösungen absetzen und wählte bewusst einen funktionalen Ansatz unter besonderer Verwendung von ECMAScript 6 Features wie z. B. Arrow Functions. Trotz dieser sehr unterschiedlichen technischen Herangehensweise war der grundlegende Gedanke hinter dem Lösungsansatz der gleiche wie bei den objektorientierten Lösungen.

Unser Fazit: Gerne wieder - dennn das Coding Dojo hat gleich mehrere positive Aspekte mitgebracht: Durch die freie Teameinteilung kamen oft Programmierer zusammen, die nicht tagtäglich an den gleichen Projekten arbeiten, so dass der teamübergreifende Austausch gefördert wurde. Der freie Rahmen ließ den Teams Platz, auch einmal Lösungswege abseits der ausgetretenen Pfade zu testen. Und letzten Endes hat es einfach Spaß gemacht, sich zwischendurch losgelöst von konkreten Projekten mit Coding-Aufgaben zu beschäftigen.

Weitere Informationen im Netz

Team-Kata-Finale der Damen - Karate-WM 2014:
https://www.youtube.com/watch?v=lFjz8LIfzC0

Keynote der International PHP Conference (IPC) 2012 zum Thema Kata:
https://www.youtube.com/watch?v=kFe01104ovg

„The Coding Dojo Handbook“ von Emily Bache:
https://leanpub.com/codingdojohandbook

Pair Programming:
https://de.wikipedia.org/wiki/Paarprogrammierung

Screencasts zu Umsetzungen der Roman Number Kata in PHP:
https://www.google.de/search?q=roman+number+kata+php&tbm=vid

Clean Code Developer School – Überblick über Coding Katas:
http://ccd-school.de/coding-dojo/

Open Closed Prinzip (SOLID):
https://de.wikipedia.org/wiki/Open-Closed-Prinzip

Zurück zur Übersicht