Ein Dojo ist im Japanischen bekannt als Trainingsort für fernöstliche Kampfkünste. In diesem Gebäude, das oft einem Tempel gleicht und durchaus spirituellen Charakter hat, werden Bewegungsabläufe trainiert, die sogenannten Katas. Was die Spiritualität der fernöstlichen Kampfkünste und Softwareentwicklung gemeinsam haben, soll in diesem Beitrag näher betrachtet werden.
SoftwareentwicklerInnen sind Profis. Sie verdienen ihren Lebensunterhalt damit Probleme zu lösen, indem sie Algorithmen entwerfen, anwenden und in Form von Code zur Verfügung stellen. Dabei ist die Bandbreite an Werkzeugen die den EntwicklerInnen zur Verfügung steht so groß und schnelllebig, dass die gute alte Phrase „lebenslanges Lernen“ in der Softwarebranche besonders zutrifft.
Basistraining im Dojo als Fundament für Großes
Es stellt sich die Frage wie EntwicklerInnen diese Schnelllebigkeit und das scheinbar unendliche Spektrum an Tech-Stacks bewerkstelligen können. Ein Aspekt zur Beantwortung dieser Frage stellt sich schnell ein: Es ist nicht möglich. Die vielen Technologien, Frameworks und Programmiersprachen kommen und gehen, einige früher, andere später. Aber während das ständige „am Ball bleiben“ EntwicklerInnen fordert und deren Weiterbildungszeit in Anspruch nimmt, bleibt das Training der technologie-unabhängigen Basistechniken, Paradigmen und Algorithmen auf der Strecke.
Das wäre in etwa so, als ob MusikerInnen ständig neue Stücke lernen, ohne dabei ein Instrument in die Hand zunehmen, oder wenn FußballerInnen dauernd nur über Taktik und Laufwege theoretisieren ohne auch nur einmal gegen einen Ball zu treten.
Und eben diese Problematik zeigt sich auch in der Softwareentwicklung. Wie viele Senior Developer würden sich wohl zutrauen, einen Quick Search Algorithmus zu implementieren, ohne nachzulesen? Wer könnte „freihändig“ eine qualitativ hochwertige Test Suite coden, ohne die Unterstützung moderner IDEs, Code Completion, Test Coverage, Quality Gates und mehr? Wie viele EntwicklerInnen sind in der Lage, eine Abstract Factory „freihändig“ zu implementieren? Denken alle daran, dass ihr Code auch noch in einigen Jahren von fremden Developern verstanden, erweitert und getestet werden muss?
Hier schließt sich der Kreis zu den fernöstlichen Kampfkünsten. Das Dojo ist in der Welt der Softwareentwicklung ein Ort, um die eigenen Fertigkeiten und Basistechniken üben und letztendlich auch meistern zu können. Fernab vom Projektalltag dienen die „Katas“, die im Coding Dojo praktiziert werden, dem Feinschliff der EntwicklerInnen. Darüber hinaus fördert das gemeinsame Üben eines Coding-Katas den Wissenstransfer in Entwicklungsteams und ermöglicht für einzelne Developer den Blick über den Tellerrand. So werden Lösungs- und Denkansätze durch KollegInnen aufgezeigt, an die man selbst vielleicht noch nie gedacht hat.
Ohne TDD kein Coding Dojo
Dojos werden üblicherweise mithilfe von Test Driven Development (TDD) durchgeführt. Das „Red-Green-Refactor“ Mantra ist so etwas wie die „Etikette“ im Coding Dojo. Durch den Einsatz von TDD wird das strategische Programmieren gefördert, also die Strategie eines langlebigen, qualitativ hochwertigen und dauerhaft wartbaren Codes.
Der Schwerpunkt eines Coding Dojos kann entweder beim Üben von TDD liegen, oder bei anderen Aspekten der Softwareentwicklung: Refactoring von Legacy Code, Anforderungsanalyse, objektorientiertes Design, Algorithmen und vieles mehr.
Organisation von Coding Dojos
Die Durchführungsformen sind vielfältig und der Fantasie keine Grenzen gesetzt. Bewährt hat sich die Aufstellung mehrerer Teams die jeweils dieselbe Aufgabe (das Kata) bekommen. Pro Team sollten nicht mehr als drei Personen vorhanden sein, da sonst das aktive Engagement aller Teammitglieder schwierig wird.
.jpeg)
Ein praktikabler Zeitraum für ein Dojo spannt sich über 2–3 Stunden, wobei abhängig von der verfügbaren Zeit und dem gewünschten Umfang nach oben hin keine Grenzen gesetzt sind. Je nach Schwierigkeit lässt sich innerhalb von 2 Stunden ein Kata ganz gut bewältigen. Wer mehr machen möchte, muss entsprechend mehr Zeit einplanen. Um die produktive Arbeit nicht zu sehr in den Hintergrund treten zu lassen, empfiehlt es sich, das Dojo aber vorab als relativ strikte Time-Box festzulegen.
Die Auswahl des Katas, das im Dojo bearbeitet werden soll, ist unendlich groß. Einerseits ist das Internet voll von Beispielen, angefangen von klassischen Aufgaben wie der Implementierung eines „String Calculators“ über Sortier- und Suchalgorithmen bis hin zu komplexen Katas, die sich über mehrere Dojos strecken können. Andererseits können auch konkrete Teilprobleme aus Kundenprojekten herangezogen werden, die als Kata dienen, oder man überlegt sich kreative User Stories aus fiktiven Projekten, die entsprechend herausfordernd sind.
Ein weiteres Element, das sich im Dojo bewährt hat, ist der Abschluss dessen in Form eines kurzen Reviews, wobei man je zwei Stunden Dojo, in etwa 20 Minuten Review einplanen sollte. Dabei berichten alle Teams über ihre Lösungsansätze, Schwierigkeiten und persönlichen Eindrücken, die bei der Bearbeitung des Katas aufgekommen sind.
Die richtigen Fragen stellen
Wie wirken sich Coding Dojos auf die einzelnen EntwicklerInnen aus? Diese Frage lässt sich nur subjektiv beantworten. Man kann aber beobachten, dass mit jedem neuen Dojo, die TeilnehmerInnen beginnen Fragen zu stellen, Fragen, die sich indirekt auf das Coding-Mindset, die Strategie beim Programmieren und letztendlich auch auf den Code auswirken: Decken meine Tests alle Edge-Cases ab? Gibt es eine einfachere Architektur meines Moduls? Ist das Klassendesign auch in Zukunft erweiterbar und testbar?
Vor allem hinsichtlich des Mindsets ist das konsequente Befolgen von TDD in den Dojos von großer Wirksamkeit. EntwicklerInnen die zuvor lediglich der Meinung waren, dass „dies ohnehin eine private Methode in meiner Klasse wird und man dafür keinen Test braucht“, fangen plötzlich an den TDD Zyklus anzuwenden und die Requirements in Form von Unit Tests zu spezifizieren, bevor der zugehörige Production-Code implementiert wird. Das führt zu Code, der jederzeit leicht testbar ist und dem wohl nicht das Schicksal von nicht wartbaren legacy Code zuteilwird.
Coding Dojos und deren Mehrwert
Neben den genannten Vorteilen bringt ein Coding Dojo auch viele positive Nebeneffekte mit sich: So eignet es sich hervorragend, um neue Programmiersprachen anhand konkreter Problemstellungen zu erlernen. Letztendlich hat es aber auch einen mentalen Aspekt. Im Projektalltag kann es hin und wieder vorkommen, dass ein Dev-Team in schwierigen Situationen ist: Ungewollte Stehzeiten, herausfordernde Features, ausgefallene Pipelines, etc. Das Coding Dojo hilft in solchen Situationen wieder den Blick auf das Wesentliche zu schärfen und Stehzeiten effizient zu nutzen.
Um noch einmal eine Metapher aus dem Sport heranzuziehen: Wie auch Fußballteams abseits von ihren Meisterschaften stetig trainieren müssen, um individuelle und mannschaftliche Fähigkeiten zu verbessern, brauchen auch EntwicklerInnen eine Trainingsumgebung abseits von Projekten, um Skills zu erhalten und steigern zu können. Davon profitieren letztendlich nicht nur die teilnehmenden Developer selbst, sondern auch Kunden und deren Projekte.
Du möchtest auch Teil des #Teamobjectbay werden?
Dann schau dir doch mal unsere freien Stellenanzeigen an.
