Coding Dojo und die Motivation für Upfront-Design

Übung macht den Meister – nicht nur im Sport. Coding Dojo erlaubt es, sich mit anderen Entwicklern auszutauschen und Ideen fließen zu lassen.

Kenji Midori

Die Softwerkskammer ist jene Plattform, an denen diverse Treffen angekündigt werden. Was passiert bei den Treffen? Teilnehmer bekommen Aufgaben gestellt und lösen diese meistens zu zweit. Zeit, um Denkweisen anderer Entwickler kennen zu lernen, Zeit um eventuell seine IDE besser kennen zu lernen oder womöglich bietet sich sogar eine Möglichkeit an, eine neue Programmiersprache zu lernen. In einem der letzten firmeninternen DOJOs haben wir ein CRC (Use Class, Responsibilities, and Collaboration) Spiel 2 x 45 Minuten gemacht. Das letzte Mal hatte ich CRC auf der TU vor 8 Jahren benutzt.

Die Aufgabe war relativ einfach. Die Steuerung des Mars Rovers auf einem 2 dimensionalen Gitter. Das Gitter hatte freie Zellen und Zellen, welche blockiert waren. In den letzten DOJOs war uns allen schon klar geworden, dass Zero-Upfront-Design immer zu Problemen führte – selbst in 2 x 45 Minuten Sessions. Diesmal hätte es wohl zu einer Katastrophe geführt, wenn die Teams an Teillösungen gearbeitet hätten und diese zum Schluss integrieren hätten müssen (übrigens auch eine lustige DOJO Übung). Initial warf sich gleich die Frage auf: Unser Roboter kann nach Links, Rechts und nach vorne bzw. zurück. Doch was bedeutet nach Links? Dreht es sich in der gleichen Zelle? Oder ist er in der Zelle links neben sich? Hat der Roboter überhaupt eine Orientierung? Viele Leute – viele Meinungen. 3 Meinungen machten die Runde:

  1. Der Roboter befindet sich eine Zelle weiter links – dreht sich aber nicht
  2. Der Roboter befindet sich eine Zelle weiter links, hat sich aber um 90 Grad nach links gedreht
  3. Der Roboter bleibt in der gleichen Zelle und dreht sich am Stand

Da u.a. umdrehen (180 Grad) mit Version 3 am einfachsten war und diese auch am wenigstens Nebeneffekte zu haben schien – Winner. Dieses kleine Beispiel spiegelte die Wichtigkeit der Anforderungsanalyse wieder. Hätte man ohne “Requirement Workshop”" (?) begonnen, so wäre die Frage erst recht spät aufgekommen. Das CRC “Spiel” zeigt auch recht schnell Design-Flaws auf. Teilnehmer fragen andere Teilnehmer “Warum willst du das von mir wissen? Ich habe die Daten nicht!”. Es zeigt, dass Interaktionsdiagramme durchaus Sinn haben. Sie helfen beim gemeinsamen Verständnis und schützen frühzeitig vor Design-Flaws. Und bekanntlich ist ein UML Refactoring billiger als ein Code Refactoring.

Für meine persönliche Entwicklung sind solche Veranstaltungen und so spezielle Sachen wie das CRC Spiel sehr wichtig, da sie zeigen, dass bei vermeintlich simplen Sachen ohne Design schnell alles in die Hose geht.