In diesem Blogbeitrag sollen die wichtigsten aufgekommenen Punkte des GDCR '19 in Karlsruhe bei Fiducia & GAD IT AG zusammengefasst werden.
In der Einleitung wurde der Ablauf des Tages, die Programmieraufgabe (View Gewinnt), Four Rules of Simple Design und PairProgramming vorgestellt.
Um die Teilnehmer in die Einleitung mit einzubeziehen, ließen wir sie nach ihrer "Hauptprogrammiersprache" Gruppen bilden. Somit konnten die Teilnehmer auch sehen, mit wem man in einer der Session ein Pair bilden könnte um eine Programmiersprache auszuprobieren.
Das Finden der ersten Pairs haben wir unterstützt, indem wir alle Teilnehmer gebeten hatten, sich nach ihrer Code-Retreat-Erfahrung in eine Reihe aufzustellen. Die Reihe wurde dann zusammengeklappt, sodass diejenige Person mit der meisten Code-Retreats mit derjenige Person mit am wenigsten Code-Retreats gepaired hat, diejenige Person mit den zweit meisten mit derjenigen Person mit den zweit wenigsten, usw.
Diese Constraint zwingt alle Teilnehmer ihre Finger auf der Tastatur zu behalten, einzige Ausnahme, dass auffinden des Shortcuts.
Auf Grund des sehr diversen Umfelds (alle Programmiersprachen, Tastaturlayouts, IDEs und Betriebssysteme) stellte sich der Constraint als durchaus große Herausforderung dar.
Diese Constraint war zum lockeren reinkommen gedacht, verfehlte aber ihren Zweck.
Beim diesem GDCR in Karlsruhe hatten wir TDD nicht mehr als verpflichtend vorgegeben sondern als eines der Werkzeuge, die man einsetzen bzw. ausprobieren kann. Zumindest in dieser Session sollte die Gruppe dieses Werkzeug aber einmal konzentriert und bewusst ausprobiert.
Das Constraint wurde positiv aufgenommen. Dadurch, dass man sich in der ersten Session bereits mit der Aufgabenstellung befasst hatte, fiel das schreiben des ersten Tests leichter.
Da TDD in den letzten Jahr teilweise öfters ein kontroverses Thema war, waren wir überrascht, dass die Rückmeldung durchweg positiv war. Daher fühlen wir uns bestärkt in der Entscheidung TDD als optionales Werkzeug anzubieten aber nicht für den ganzen Tag als gesetzt vorzugeben, jedoch eine einzelnen Session zum Fokus zu machen.
Dieses Constraint sollte den Fokus auf die Domäne und ihre Modellierung im Code legen. Die Vorgabe war, dass primitive Datentypen wie String
, int
, boolean
nicht direkt verwendet werden sollten, sondern immer in einer Objekt gekapselt werden sollte, das die Bedeutung für die Domäne beschreibt. Für String
also z. B. Name
.
Das Feedback aus der Gruppe war positiv. Ein Pair hat angemerkt, dass sie mehr über die Domäne diskutiert haben als in den Sessions davor.
Das Constraint scheint seinen Zweck erfüllt zu haben.
Beim Typen boolean
gab es noch die Diskussion, ob z. B. bei einer Methode isEmpty
dieser Typ nicht die Domäne schon ausreichend beschreibt, was man durchaus so sehen kann. Eine Alternative wäre ein Enum oder State-Objekt, dass z. B. die Ausprägungen Empty
, PartiallyFilled
und Full
hat einzuführen.
https://keybase.pub/chr1shaefn3r/slides/ka-gdcr19.pdf
Vielen Dank an alle Teilnehmer für das konzentrierte Mitmachen und das positive Feedback. Der zweite ganz groẞe Dank geht an Peter Fichtner der uns bei der Fiducia & GAD IT AG unter optimalsten Bedingungen gehostet hat.