Coding Dojo I am 31.03.2010

Teilnehmer

Anton, Rico, Robert und Mike

Aufgabenstellung

Zu unserem ersten Treffen hatte Mike zwei Kata's vorgestellt. Die FizzBuzz-Kata und die DictionaryReplacer-Kata. Nach kurzer Diskussion wurde sich für die Umsetzung der FizzBuzzKata entschieden.

Dojo-Organisation

Nachdem Robert und Mike die verschiedenen Coding-Dojo Varianten noch einmal kurz erläuterten, entschlossen wir uns für die organisatorisch einfache Variante die Lösung gemeinsam mit einem Code-Monkey umzusetzten. Mike übernahm an diesem Abend diese Aufgabe.

Vorgehen

Kein wildes losgehacke!-"Erst denken, dann coden."

Sehr interessant war, dass wir uns sehr schnell darüber einig waren, als erstes unser prinzipielles Vorgehen zu besprechen und ein kurzes für und wider einander darzulegen. Unsere wichtigsten Themen waren:

  • Code-Versionsverwaltung
  • Anwendungsarchitektur/-design
  • Definition von Schnittstellen (Anwendungsgrenzen)
  • die damit verbundene Projektstruktur
  • Erläuterung und Definition von Grenzfällen abseits der beschriebenen Anwendungsanforderungen
  • Vor- und Nachteile Test-getriebener Entwicklung (Unit- versus Integrations- versus Akzeptanztests)
  • Aufwandsabschätzung in Minuten
Code-Repository
Unsere gemeinsame Code-Versionsverwaltung wurde Git mit GitHub.com als Sharing-Host. Das ermöglicht uns schnelle lokale Commitments und damit die Entwicklung in kleinen Schritten ohne Ängste. Unserer Coding-Dojo Repository mit allen auch zukünftigen Lösungen findet ihr hier.

Anwendungsarchitektur/-design
Eine kleine OneNote-Skizze mit den wichtigsten Modulen der Anwendung sollte allen den gemeinsamen Weg bildlich zeigen und gleichzeitig die anvisierte Projektstruktur beschreiben.


Definition von Schnittstellen (Anwendungsgrenzen)
Die von Rico geforderte Definition von technischen und/oder semantischen Schnittstellen, vor allem am Domänen-Modul, blieb leider aus. Als Gegenargumente wurden YAGNI und KISS, im Bezug auf die Einfachheit der Aufgabe, genannt. So verblieb die gesamte Lösung ohne explizite Schnittstellen zur Außenwelt.

Projektstruktur
Aus der Architekturskizze ergab sich dann sehr schnell unsere Projektstruktur.


Wie unschwer zu erkennen ist, unterscheiden sich die Namen aus der Skizze und die der Projektstruktur. Das Bedarf einer Besserung.

Klärung von Grenzfällen
Die Klärung von Grenzfällen war ein weiteres Thema das uns vor und während der Entwicklung beschäftigte. Wir entschlossen uns, trotz der Unzufriedenheit einiger, alle Grenzfälle in der ersten Iteration außen vor zu lassen und uns auf die Kernaufgabe zu konzentieren.

Test-getriebene Entwicklung
Ein großes Thema war die Methodik des Testens. Test-getrieben, ja schon aber wie und mit welchem Aufwand? Sind Akzeptanz- und Intergrationstests effektiver als Unit-Tests? Benötigen wir für diese einfache Funktionalitäten überhaupt Unit-Tests? Machen Unit-Tests die Aufgabe nicht unnötig schwierig? Entspricht der Einsatz von Unit-Tests überhaupt noch den Regeln von KISS? Die Gruppe war gespaltener Ansicht, konnte sich allerdings zu einem Kompromiss in Form eines(!) Integrationstests hinreißen lassen. Die ersten Refaktorierungen der Lösung könnten noch einige AHA-Effekte erzeugen. Wir sind gespannt.

Aufwandsabschätzung
Auch hier ergaben die Schätzung große Unterschiede. Die Vorstellungen reichten von 20 Minuten hin zu 90 Minuten.

Umsetzung

Nachdem wir ca. 45 Minuten über den generellen Aufbau und unser Vorgehen gesprochen und das VS-Projektsetup abgeschlossen hatten, gingen wir in unsere verdiente Pause von ca. 15 Minuten. In dieser besprachen wir das Geschaffene Werk und waren uns einig... Jetzt geht es ja schnell! Einen kleinen Test schreiben und die entsprechende Umsetzung runtertippen. Fertig! Dennoch waren einige Zeitschätzungen jetzt schon hinfällig geworden.

Weiter gehts - zweite Runde!
Im zweiten Teil schrieben wir einen Integrationtest. Dieser sollte die Funktionalität des Algorithmus sicher stellen und erste Gehversuche ermöglichen.

    [TestFixture]
    [Category("Integrationstests (Happy Day)")]
    public class FizzBuzzTester
    {
        [Test]
        public void Wenn_FizzBuzz_1_bis_100_sollte_ein_Ergebnis_laut_Anforderung_zurück_geben()
        {
            var sut = new FizzBuzzer();
            var actual = sut.MacheFizzBuzzVon1Bis100();
            Assert.That(actual.Substring(0,24), Is.EqualTo("1 2 Fizz 4 Buzz Fizz 7 8"));
        }
    }

Jetzt saß Anton am Keyboard. Ihm war der Algorithmus schon jetzt klar. Nur wie wollen wir die Aufgabe umsetzen. Klasse mit Membervariable war ein möglicher Weg. Also wurde dieser, pragmatisch eingeschlagen. Keine 10 Minuten später war die Lösung umgesetzt. Nach dem ersten Testlauf stellten wir einen kleinen Fehler im Test fest. Anton fixte und der Test wurde Grün. Fertig war die Lösung!

Eine kontroverse Diskussion über den Einsatz von Membervariablen und Multithreaded-Umgebungen ergab sich am Rande der Implementierung und hatte die erste kleine Refaktorierung zur Folge. Hier wurde versucht die Implementierung so anzupassen, dass eine Lösung ohne tückische Membervariablen lauffähig ist. Multithreading und parallele Ausführung sind somit ein Thema von großem Interesse und es wurde beschlossen, auch dazu einen Themenabend vorzubereiten.

Fazit

Am Ende nahmen wir uns noch kurz Zeit für eine kleine Feedback-Runde. Alles im alles fanden wir unser ersten Treffen sehr spannend und beschlossen weitere Treffen folgen zu lassen. Für alle Beteiligten wäre ein Refaktorierung oder komplexere Aufgabe ein lohnenswertes neues Ziel für ein weiteres Treffen. In diesem Sinne freuen wir uns auf das nächste Coding-Dojo.


Comments