Auf ähnliche Art und Weise geht es bei einem „Code-Kata" nicht darum, sich einem Feind in Form von ernsthaften, komplexen Problemen zu stellen. Man löst stattdessen in kleinen Gruppen oder im Pair Programming einfache, überschaubare Probleme. Der Sinn besteht darin, sich der einzelnen Arbeitsschritte bewusst zu werden. Nicht die Lösung ist das Ziel, sondern der Weg dorthin und die Erkenntnisse, die man dabei sammeln kann.
Eine mögliche Problemstellung ist unter dem Namen „FizzBuzz" bekannt. Dabei handelt es sich um ein Abzählspiel. Man beginnt bei 1 zu zählen, ersetzt dabei jedoch alle Zahlen, die durch drei teilbar sind, durch das Wort "Fizz" und alle Zahlen, die durch fünf teilbar sind, durch das Wort „Buzz". Ist eine Zahl sowohl durch drei als auch durch fünf teilbar, ersetzt man die Zahl durch das Wort "FizzBuzz". 1, 2, Fizz, 4, Buzz, …, …, Fizz, 13, 14, FizzBuzz, …, …
Ein Programm zu schreiben, welches dies leistet, stellt eher eine Fingerübung dar. Die fertige Lösung umfasst wenige Zeilen und sollte für einen halbwegs erfahrenen Entwickler nicht viel Zeit in Anspruch nehmen. Doch was ist zu beachten, wenn man die Lösung testgetrieben entwickelt? Welche und wie viele Tests schreibt man? Geht man kleinschrittig genug vor oder gar zu kleinschrittig? Können einige der Tests zusammengefasst werden? Selbst bei einem so einfachen Problem können sich viele Fragen stellen. Diese Fragen können dann mit den anwesenden Kollegen diskutiert werden. Und manchmal führt eine einfache Frage zu einer viel weitreichenderen Grundsatzdiskussion. Auch wenn solche Diskussionen manchmal sehr hitzig werden können, bleibt es trotz Kampfsportmetapher stets gewaltfrei.
Von dieser Art der Übung können die Teilnehmenden auf verschiedenste Art profitieren. Unabhängig vom Kenntnisstand gibt es immer ein paar Tricks und Kniffe, die man sich abschauen kann. Ein Kollege nutzt eine Tastenkombination um ein Refactoring durchzuführen. Welche Tastenkombination hat der Kollege da gerade benutzt? Ein anderer Kollege hat von einem neuen Sprachfeature gehört. Was halten die anderen davon? Gibt es technische Gründe dafür oder dagegen? Ist es besser oder schlechter lesbar als die alte Lösung?
Im Rahmen unseres „Open Fridays" haben wir durchweg positive Erfahrung mit „Code-Katas" gemacht. Sie fördern den Wissensaustausch und sorgen für ein einheitliches Bild von dem, was lesbaren, wartbaren Code ausmacht. Und auch wenn manchmal am Ende keine vollständige Lösung erarbeitet wurde, führte der Weg dorthin dennoch zu neuen Einsichten. Und das Ganze mit Spaß an der Sache.
