Gestern fand das erste .NET Coding Dojo für Experten in München statt. Ich war im Vorfeld schon ziemlich gespannt, zumal ja schon das Dojo für Einsteiger so gut gelaufen war.
Ich hatte mir für das erste Experten-Dojo zwei Dinge auf der Agenda. An erster Stelle stand nochmals die Implementierung des FizzBuzz-Katas auf dem Programm. Nach dem Dojo hatte ja auch schon Ralf das FizzBuzz Code Kata implementiert. Also dachte ich mir, zum aufwärmen ist das bestimmt eine gute Aufgabe.
Wir haben uns an die Aufgabe im Modus “Randori” herangewagt. Ich muss sagen, für diesen allerersten Versuch, eine Code Kata per Randori zu lösen lief es erstaunlich gut. Schnell haben alle Teilnehmer festgestellt, dass es eine Übereinstimmung über die Herangehensweise der Implementierung geben muss. Die Tests waren trivial und dementprechend weniger Gegenstand der Diskussion.
Darüber hinaus war es interessant zu beobachten, dass auch bei der geballten Ladung an Kompetenz und Erfahrung die Implementierungsgeschwindigkeit sich nicht daramatisch verkürzt. (Zum Vergleich: Im Einsteiger-Dojo wurde FizzBuzz in ca. 2 Stunden gelöst, die Experten Runde hat knapp 1 Stunde gebraucht). Der Grund dafür sind vorrangig weiche Faktoren wie Teamfindung und -bildung. Aber auch fachliche Bremsspuren waren zu beobachten: Die Teilnehmer haben sich z.T. bei der Implementierung um Designfragen gekümmert – wohl mit den Gedanken der Wierderverwendbarkeit und Generalisierung im Hinterkopf. Dieser Hauch von “Design-Upfront” wurde aber schnell erkannt und ausgeräumt.
Nach einer kurzen Denk- und Verschnaufpause haben wir uns an das zweite Code Kata “RPN Calculator” herangewagt. Dabei geht es um die Simulation eines Taschenrechners, welches mit umgekehrt polnischer Notation arbeitet.
Nach der Vorstellung des Kata und der dazu gehörigen Akzeptanzkriterien ging es wieder mit Schwung los. Unterschied zum ersten Mal: Es wurde nicht sofort mit den Tests losgelegt, sondern in der Runde eine grundsätzliche Einigung über das Verständnis der Aufgabe und damit “grobe” Design der Implementierung herbeigeführt. Erst dann ging es los mit dem klassischen TDD. Test – Rot – Implementieren – Test – Grün – Refaktorisieren – Test – Grün.
Nach der Implementierung der Grundfunktionalität (die Addition und Subtraktion waren funktional korrekt), ging es ans Refaktorisieren. Hier wurden zur Beseitigung von Code-Redundanz in mehreren Methoden einer Klasse zwei Lösungsansätze verfolgt.

Template Methode
Der zweite Lösungsweg war im Gegensatz zum ersten ein ein äußerst effektiver: Die Übergabe einer Lamda-Funktion auf eine private “Template Methode”. Im Endeffekt die selbe Lösung, halt funktional statt orientiert an der “reinen” OO-Lehre:
...
public void Add()
{
this.Calculate((x, y) => x + y);
}
private void Calculate(Func<decimal, decimal, decimal> op)
{
/* get x somewhere */
/* get y somewhere */
decimal result = op(x, y);
/* put result somewhere */
}
...
Ich möchte jetzt nicht zu sehr ins Detail eingehen – jedoch war deutlich erkennbar, dass die Teilnehmer für beide Lösungswege offen waren – abhängig vom gegebenen “realen” Kontext würde man die eine oder andere Verfahrensweise bevorzugen.
Abschliessend kann ich nur sagen, war dieser erste .NET Coding Dojo für Experten ein gelungenes Event – nicht zuletzt wegen der regen und aktiven Beteiligung der Teilnehmer. Ich finde diese Art des Lernens, Informationsaustausches und “Networkings” zunehmend attraktiv und spannend. Das macht Lust auf mehr!
Ich freue mich schon auf das nächste .NET Coding Dojo! Hier nochmal die nächsten Termine für die Dojo’s in München: am 7. Oktober das .NET Coding Dojo für Einsteiger und am 21. Oktober das .NET Coding Dojo für Experten! Auf geht’s: jetzt anmelden via Ning oder Xing! Ich bin dabei!
Comments