Gestern fand das erste .NET Coding Dojo in Hamburg statt und es war aus meiner Sicht ein voller Erfolg. Als erstes möchte ich mich an dieser Stelle bei der Firma masters of arts für die Räumlichkeit und natürlich bei allen Teilnehmer für die aktive Mitarbeit bedanken.
Durchgeführt haben wir das Dojo im Randori-Stil, d.h. es gab einen Entwickler, einen “Co-Piloten” und das Publikum. Nach jeweils 5 Minuten bzw. jedem neuen Testfall wurden die Positionen mit neuen Teilnehmer aus dem Publikum getauscht.
Nach einer kurzen allgemeinen Einführung in das Thema “Coding Dojo” habe ich die Aufgabenstellungen der Kata.FizzBuzz und Kata.DictionaryReplacer vorgestellt. Durch kurze Abstimmung haben wir dann (vermutlich durch meine Wortwahl beeinflusst) die Kata.DictionaryReplacer gewählt.
Mit der Wahl dieser Kata war ich nicht ganz unglücklich, da wir DictionaryReplacer schon im Online Dojo durchgenommen haben und ich deshalb die Fallstricke schon etwas einschätzen konnte.
Kata.DictionaryReplacer
Create a method that takes a string and a dictionary,
and replaces every key in the dictionary pre and suffixed with a dollar sign,
with the corresponding value from the Dictionary.Tests
input : "",
dict empty
output: ""input : "$temp$",
dict ["temp", "temporary"]
output: "temporary"input : "$temp$ here comes the name $name$",
dict ["temp", "temporary"] ["name", "John Doe"]
output : "temporary here comes the name John Doe"
Nach kurzer Einführung in die Vorgehensweise des Test-Driven Developments (TDD) und Diskussion über sinnvolles Naming ging es dann auch richtig in die Entwicklung. Die Kata eignet sich in dieser Form auch sehr schön um tatsächlich “Test first” zu arbeiten. Die Implementierung folgt quasi als logische Konsequenz.
Interessant und ungleich komplizierter wurde es dann als wir eine zusätzliche Anforderung eingebaut haben. Da es sich bei der Kata um eine Art Templatesystem handelt liegt es nahe auch in den Values des Wörterbuchs neue Keys zu erlauben und somit eine beliebige Ersetzungstiefe zu erreichen. Diese Anforderung ist ein wunderbares Beispiel dafür wie sehr man mit Aufwandsabschätzungen daneben liegen kann. 😉
Die rekursive Ersetzung wurde noch sehr schnell gelöst, aber richtig schwer haben wir uns dann mit der Erkennung von zyklischen Ersetzungen und der daraus folgenden Endlosschleife getan. Nach und nach wurden immer kompliziertere Lösungsmöglichkeiten genannt, die aber in der gegebenen Zeit nicht fehlerfrei umgesetzt werden konnten. Als Folge haben wir immer noch einen Test “rot”. Wer Lust hat kann sich also die Quellen vom github Repository ziehen und als Hausaufgabe den verbleibenden Test “grün” machen.
In der Nachbetrachtung haben wir noch einige Sachen festgestellt:
Was lief gut?
- Die Rotation der Teilnehmer klappte problemlos
- Lösungsideen sprudelten förmlich aus dem Publikum
- Interessante Edge-Cases wurden gefunden
- Viele kleine Tipps (z.B. Resharper Shortcuts) wurden ausgetauscht
- TDD wurde als erfolgreich für die Kata angesehen
- Die Randori-Form sorgt für Aktivität
- Ganz wichtig: Es hat Spaß gemacht!
Was wollen wir besser machen?
- Schneller den ersten Test schreiben
- Intensivere Diskussion des Interfaces
- Noch mehr Wert auf das Naming legen
- Versuchen die einfachste Lösung zu wählen
- Mehr Wert auf Refactoring legen
- wurde etwas vernachlässigt, da wir viel Zeit an der Endlosschleife verbraucht haben
- Die Rollen Driver, Co-Pilot und Publikum klarer trennen
- Nach jedem implementierten Testcase bzw. jeder Rotation der Teilnehmer in das git Repository einchecken
- Von Anfang an externe Tastatur und Maus für den Laptop bereit stellen
- Internetverbindung um Syntaxfrage schneller klären zu können
Als möglichen Termin für das Dojo haben wir jetzt grob jeweils den 3. Mittwoch im Monat vorgeschlagen. Über die Xing-Gruppe der .NET User Group Hamburg werden wir natürlich auch wieder entsprechende Einladungen verschicken.
Tags: .NET User Group Hamburg, CodingDojo, TDD, Test Driven Design