Mir fällt eine Lösungsfindung ohne die Struktur einer Skizze immer etwas schwer, deshalb zeichnete ich neben der parallel stattfindenden Implementierung im Randori-Stil meine kleine Welt der Problem-Domäne.
Mir hilft diese Art der Anwendungsplanung - ohne Code - Klarheit über Code-Struktur, Funktionseinheiten und Datenstrukturen, die Funktionsweise, ihrer Interaktion und der Anwendungszustände zu erhalten. Das entscheidende für mich dabei ist, der grobe Überblick und Trennung der Aufgaben in Teilaufgaben. Ich versuche dann, wärend der Implementierung den Gedanken zu halten und in die gewünschte Funktionsweise umzusetzen. "Schwierige" Fälle beantworte ich vorerst nicht - sie bleiben mit einem gedanklichen Fragezeichen offen und werden an geeigneter Stelle mit einem test-, trace- und/oder debugger-getriebenen Vorgehen explorativ-iterativ bis zu Erfüllung der Akzeptanzkriterien "ausgecodet". Ich bin kein TDD-Hardliner, daher stellen Unittests auf verschiedenen Abstraktionsebenen meine Akzeptanzkriterien, und die aus Skizze erstellte Code-Struktur mein "System under Test" bereit. Aus diesem Mix, Planung und TDD Setup entsteht die API. In diesem Falle auch meine Variante der KataTennis.
Ganz besonders hat mir, da ich sonst kein Freund von Enums bin, die Idee "Game-States über Enums" abzubilden gefallen. Die Domäne wurde, auch im Code, um einen wichtigen Punkt, der verständlicheren Domänensprache, erweitert. Toll - ich hab das übernommen, aber ein kleiner Wermutstropfen bleibt - Operationen auf Enums, wie Increment (++), Decrement(--) sind zwar möglich, können allerdings zu ungewollten Exceptions führen. Hier gilt: Aufpassen bei Operationen über das maximale oder minimale Enum-Value-Scope hinausgehende.
Lehre
Die inzwischen entstandene Breite der Lösungsvarianten zeigt mir, wie unterschiedlich abstrakt das Problem der Spielstatushaltung, des Gameplays, des Code-Verständnisses und des Testens interpretiert werden kann. Mir war eine Trennung von Game-Play und Game-State, eine zentrale Steuerung der Transitionen über Constraints sowie eine relativ "natürliche" Verwendung der API wichtig. Schwer tat ich mich bei den Unittests der Game- und Play-States. Obwohl ich von der Notwendigkeit überzeugt bin, empfand ich das im Szenario als etwas lästig. Ich halte meine Augen und Ohren für eine umgängliche Lösung offen.
Fazit
Für mich ist es immer wieder erstaunlich, wie viele Lösungen eines Problems mit unterschiedlichen Ansätzen und Ideen verwirklicht werden können. Cool - da freue ich mich schon auf das nächste .NET Coding-Dojo.
Cool, dass du dir eine Ubiquitous Language Concept Map gemalt hast.
AntwortenLöschenCool, dass du deinem Code eine Modellskizze beigegeben hast.
Schade, dass dein Modell nicht konsequent auf EBC basiert. Es sieht mir eher wie ein Flowchart aus. Und mir ist auch nicht klar, an welchem Punkt eines Spiels du damit ansetzt oder bei welchem API-Aufruf.
In jedem Fall finde ich es aber einfacher, Ansätze auf Modellebene zu vergleichen Da sieht man sehr schnell im wahrsten Sinn des Wortes, was einer anders macht.
:-) Kein EBC - ja das finde ich in der Implementierung auch schade. Irgendwie gelang es mir in der Timebox nicht, State und Transitionen in der Implementierungphase schnell zu entkoppeln und in EBC zu überführen. Ich werde versuchen, die KataTennis noch 2-100 :-) mal zu Implementieren und mich dadurch einer EBC-Lösung zu nähern.
AntwortenLöschenJa, meine Skizze ist eher ein FlowChart; genauer sollte es ein StateChart werden. Die Bubbles sollen den aktuellen State innerhalb der Transitionvorgänge verursacht durch "Player Wins" (Methode Wins(Player player)) darstellen. An den Pfeilen stehen die Condition des Transitionsvorgangs. Ich finde Deine Notation mit der Kette an Transitionsvorgängen auch ganz passend. Ich hab es über die Schleife zum Ausdruck bringen wollen. Bedarf sicher noch Nachsteuerung ;-).
Ich finde eine Skizze/Diagramm des angepeilten Modells auch einfacher verständlich und bemerke in Fachdiskussionen mit Kollegen immer wieder den großen Wert eines solchen Mittels. Der konsequente Versuch eine Idee in ein Modell und dieses in eine reduzierte und visualisierte Notation zu überführen empfinde ich in meiner Arbeit inzwischen recht zielführend. Nun gelingt es mir, wie offenbar in meiner kleine Skizze der Tennis-Kata geschehen, nicht immer die ausdrucksstärkste oder eleganteste Notation passend zum gedachten Lösungsmuster zu finden. Die nächste KataTennis kommt bestimmt, und dann wird sie wieder ein bisschen anders, vielleicht auch "besser", im Code und in der Notation gelöst.