Der nachfolgende Text wurden mit KI erstellt und kann Fehler enthalten. Fehler gefunden? Bei GitHub editieren
Am 8. und am 9. November, also insbesondere am 9. November, den Samstag, ist eben der Global Day of Code-Retreat.
Der gibt es irgendwie in der ganzen Republik und sogar darüber hinaus, also im gesamten deutschsprachigen Raum und sogar weltweit halt irgendwie genau solche Code-Retreats.
Wir wollen einmal das Konzept vorstellen.
Bevor wir dazu kommen, Marco, möchtest du kurz zwei Worte über dich sagen?
Gerne.
Also ich bin IT-Consultant bei der CodeCentric, was vielleicht in dem Zusammenhang noch interessant ist, Co-Organisator der Softwarekammer in Nürnberg, wo wir halt auch solche Cutters und Code-Retreats auch hatten an Veranstalten.
Genau.
Und du machst tatsächlich, bist mit bei dem Code-Retreat von denen, die DATEV macht in Nürnberg.
Da kann man dich sozusagen dann live erleben, wenn da so Interesse ist.
Wir schauen mal, wie viele Teilnehmer kommen.
Also wenn es nicht so viele sind, mache ich vielleicht einfach selber auch mit.
Ansonsten aktuell sind wir, glaube ich, drei Moderatoren.
Und wenn viele Teilnehmer da sind, dann können wir die auch gut betreuen.
Perfekt.
So und reden wollen wir, glaube ich, erst mal über das Thema mit dem Game of Life.
Ich schaue mal auf die Folien um.
Da sind sie.
Conway’s Game of Life.
Das ist nämlich das, was man am Code-Retreat implementiert.
Und an der Stelle würde ich jetzt sozusagen an dich übergeben.
Was ist Game of Life und warum interessiert uns das?
Das mal kurz anschauen.
Erstmal ist es im Prinzip unser Vehikel, unsere Übung.
Natürlich wollen wir ein Code-Beispiel haben, das möglichst viele interessante Design-Herausforderungen auch stellt.
Und Conway’s Game of Life erfüllt so ein bisschen diesen Sweetspot.
Genau.
Um was geht es da?
Das ist im Prinzip eine Zellensimulation oder man könnte auch sagen, es ist ein Zero-Player-Game, das sich selber nach bestimmten Regeln spielt.
Eine Simulation, die nach bestimmten Regeln abläuft.
Und es gibt ein Grid von Zellen.
Feld könnte man auch sagen, auf dem diese Zellen angeordnet sind.
Und eine Zelle hat genau zwei mögliche Zustände.
Sie ist entweder tot oder sie ist lebendig.
Und das wird jetzt grafisch dargestellt, indem man sagt, ausgefüllt bedeutet lebendig, leer bedeutet tot.
Aber die grafische Darstellung ist was, das werden wir uns gar nicht anschauen.
Es geht jetzt nicht um die UI und um die Darstellung, sondern rein um die Simulationslogik.
Sorry, ein kurzer Einwurf noch.
Der Conway von dem Conway’s Game of Life ist nicht der Conway von Conway’s Law.
Das sind zwei unterschiedliche Conways.
Der andere Conway.
Sorry, ich habe dich unterbrochen.
Es gibt mehrere Conways.
Es gibt auch noch einen australischen Professor Conway, der bei Pearl 6 mitgewirkt hat.
Also sogar drei Conways, die in unserem Feld irgendwie von Interesse sind.
Genau, das sind die Regeln des Game of Life.
Und da geht es im Prinzip einfach nur darum, was passiert mit einer Zelle in der nächsten Generation.
Das sind diskrete Generationen.
Es wird immer eine neue Generation aus der alten gebildet.
Aber das kann sich selbst überschreiben, sondern das ist immer jeweils eine neue Generation, die auf dem State der alten basiert.
Und da muss man sich jetzt jede Zelle quasi individuell anschauen und schauen, wie viele lebendige Nachbarn hat die.
Also eine Zelle hat, das ist einfach ein zweidimensionales Kritis, immer genau acht Nachbarn.
Aber wie viele davon sind lebendig und abhängig davon, wie viele lebendig sind, hat das eben Auswirkungen auf die nächste Generation.
Da gibt es diese vier Regeln.
Wenn weniger als zwei Nachbarzellen, also hier im Beispiel jetzt zum Beispiel eine, lebendig sind, dann stirbt diese Zelle in der nächsten Generation.
Es geht immer nur um die mittlere Zelle, die wir jetzt hier gerade betrachten, also nur um die Regel, was mit dieser einen Zelle jeweils passiert.
Da ist es wie gesagt nur relevant, wie viele Nachbarn lebendig sind.
Wenn es genau zwei oder drei lebendige Nachbarn gibt, dann überlebt die Zelle in die nächste Generation.
Also eine lebende Zelle ist in der nächsten Generation weiterhin eine lebende Zelle.
Wenn es mehr als drei Nachbarn gibt, das ist die Overcrowding-Regel, also diese Regeln haben Namen, dann stirbt die Zelle auch in der nächsten Generation an Überbevölkerung, wie auch immer.
Und dann gibt es noch diesen Spezialfall, wenn eine Zelle tot ist und sie hat genau drei lebendige Nachbarn, dann kommt es zur Reproduktion und die Zelle lebt dann in der nächsten Generation.
Das sind vier eigentlich total einfache Regeln, aber wenn man die konsequent anwendet, können daraus eine ganze Menge interessante Konstellationen entstehen.
Und da gibt es ein paar ganz spannende Beispiele.
Also hier beispielsweise gibt es ein Pulsar.
Also einfach dadurch, dass es eine bestimmte Grundkonfiguration gibt und man die Regeln konsequent anwendet, fällt der nach mehreren Schritten wieder in seinen Originalzustand zurück und iteriert quasi immer zwischen diesen drei oder vier Zuständen und beginnt dann immer wieder von vorne.
Oder ein anderes Muster ist so ein Kleider beispielsweise, der bewegt sich sozusagen über das Feld, indem er sich immer wieder in kleine Stückchen versetzt nach rechts und nach oben wieder neu reproduziert.
Also reproduziert sich quasi selber, aber immer an einer anderen Position.
Und das sind alles so Dinge, die können einfach dadurch entstehen, dass man diese Regeln anwendet.
Deswegen war das auch für Conway glaube ich auch von mathematischem Interesse, daran so ein bisschen zu forschen, was denn aus solchen Regeln alles entstehen kann.
Und da ist noch ein Beispiel.
Das ist ein YouTube-Video.
Soll ich es kurz starten?
Ja, genau.
Starte es sehr gerne.
Dann wechsle ich hier mal kurz.
Okay, genau.
Und da sieht man auch, also auch da wieder eine Konfiguration von Zellen.
Es gibt eine Grundkonfiguration.
Dann lässt man die Simulation laufen.
Und das Spannende an diesem Beispiel ist, dass die Grundkonfiguration quasi so gewährt ist, dass das Game of Life, was im Kleinen abläuft, was diese Zellen im Kleinen manipuliert.
Jetzt sieht man es gleich.
Im Größeren quasi auch wieder ein Game of Life erzeugt, weil diese Zellen selber wieder Zellen auf einer Metaebene bilden.
Genau, die Kantenlänge.
Ich glaube, von so einer einen Zelle, die wir jetzt hier sehen, also wir sehen jetzt ein Gleiter beim Rauszoomen.
Die Kantenlänge erscheint mir sowas wie, weiß ich gar nicht, Hunderte von Zellen oder sowas zu sein.
Irgendwie sowas, nicht?
Also viel jedenfalls.
Es ist immer so ein klassisches Zeichen dafür, weil das Game of Life tatsächlich auch Turing vollständig ist.
Also man kann quasi beweisen, dass man theoretisch ein Game of Life auch jedes beliebige Programm entwickeln könnte, wenn man die Daten dann entsprechend interpretiert.
Turing-Vollständigkeit ist eben dieses theoretische Konzept, was eben sagt, alles, was man berechnen kann, kann man mit einer Turing-Maschine berechnen.
Und verschiedene andere Sachen, eben auch Game of Life, lassen sich darauf reduzieren, sind also letztendlich identisch.
Das heißt, alles, was man mit der Turing-Maschine berechnen kann, also alles, was man überhaupt berechnen kann, kann man eben lustigerweise auch mit Game of Life berechnen.
Und mir fehlt noch ein C++-Template-Expansion.
Also nur, dass man das Templates-Code generiert, ist bereits Turing vollständig.
Könnte man wahrscheinlich auch Game of Life komplett in C++-Template-Metalanguage schreiben oder so.
Stimmt, auch eine interessante Herausforderung.
Genau, also das ist jetzt das random Beispiel, was wir uns vornehmen wollen und implementieren wollen.
Also tatsächlich wollen wir es ja gleich tun.
Jetzt ist noch die andere Frage, wie tun wir das denn eigentlich nicht?
Ich glaube, das ist noch die Sache, die wir diskutieren müssen.
Jetzt hätte ich einen kleinen Einstieg, warum wir das überhaupt machen, was so die Idee hinter dem Code-Retreat ist.
Dann schauen wir uns das mal kurz an.
So ein bisschen die Idee, es heißt Code-Retreat, weil man sich eben zurückzieht aus dem Alltag.
Weil es eben gerade darum geht, dass man halt nicht die ganze Zeit gestört wird von Kundenanrufen, Anforderungen, was auch immer, sondern dass man sich den ganzen Tag mal darauf konzentrieren kann, sein eigenes Learning voranzubringen in irgendeiner Form.
Und da gibt es auch eine Webseite dazu, wo das Ganze eben auch zentral organisiert ist.
Das ist Code-Retreat.org und dort findet man auch viel, viel mehr Informationen noch.
Also auch, wie man beispielsweise selber einen Code-Retreat hostet und organisiert.
Und da sind eben auch diese ganzen Events eingetragen und man kann herausfinden, in welcher Stadt ist der nächste Code-Retreat.
Und natürlich haben wir jetzt mit dem Global Day eine ganze Menge Städte, die da auf einmal vorkommen.
Du wolltest noch was zum Organisatorchen dort sagen oder machen wir es später?
Nö, mach keine weiter.
Okay.
Die Idee ist, ja, wir wissen alle, wir sind nicht perfekt.
Wir sind alle keine Super-Coder, Super-Designer, Super-Architekten, sondern wir können immer noch neue Dinge dazulernen.
Und dazu versuchen wir zu üben, in der einen oder anderen Form.
Und im Grunde genommen könnte man jetzt argumentieren, naja, wir üben ja die ganze Zeit eigentlich schon on the job.
Also wenn wir in Projekten sind, lernen wir natürlich auch die ganze Zeit dazu.
Aber nur im Job zu üben, kann natürlich, wie hier so ein bisschen dargestellt, auch gefährlich sein.
Und wenn man das jetzt so mit Musikern vergleicht, ist es ein bisschen absurd, sich vorzustellen, die würden auf die Bühne gehen und dort erst anfangen zu üben.
Während bei uns in unserer Branche ist es eigentlich üblich.
Also wir üben eigentlich die ganze Zeit auf der Bühne.
Wir sind im Job, haben sozusagen einen Gig, sind live, sind dabei, für irgendjemanden was zu entwickeln und üben dabei aber gleichzeitig das Ganze noch.
Und was für einen Musiker undenkbar ist, wäre bei uns normal.
Aber natürlich wollen wir gerne versuchen, auch einfach vorher mal zu üben.
Und deswegen ist die Idee halt, deliberate practice, um einfach auch mal die Chance zu kriegen, außerhalb eben des Jobs, unsere Skills zu verfestigen.
Und eine Idee dabei ist natürlich auch einfach zu sagen, wir erweitern unseren Werkzeugkasten.
Werkzeug heißt jetzt nicht unbedingt jetzt Tool im technischen Sinne, sondern Werkzeugkasten auch im Sinne von mehr Methodiken, mehr Konzepte, die wir kennen, Dinge, die wir schon mal ausprobiert haben, Erfahrungen, die wir haben, die wir wiederverwenden können.
Und wir erweitern unseren Werkzeugkasten im Sinne von, wenn wir dann später in einem echten Projekt auf ähnliche Probleme treffen, dann haben wir die Lösung vielleicht schon parat, weil dann haben wir es vorher schon mal geübt, haben es vorher schon mal gemacht.
Und das ist eigentlich die ganze Idee bei der Geschichte.
Wichtig ist, so ein Kult-Retreat, das geht ja mal den ganzen Tag, das ist der No-Shipping-Day.
Also die Idee ist, wir müssen nichts liefern, wir müssen nichts ausliefern.
Es geht nicht darum, mit irgendeinem Feature schnell fertig zu werden.
Das ist ja häufig das Problem.
Wenn ich im Job unterwegs bin, dann muss ich liefern, dann muss ich fertig werden.
Und dann mache ich Dinge vielleicht einfach auf dem Weg, den ich kenne, auch wenn ich vielleicht schon weiß, es ist nicht der optimale Weg.
Aber ich habe nicht die Zeit, etwas anderes auszuprobieren, was vielleicht besser sein könnte oder auch nicht.
Hier nehmen wir uns die Zeit.
Hier müssen wir nichts ausliefern, sondern der Fokus ist auf der Learning Experience.
Der Fokus ist darauf, dass wir versuchen, möglichst viel von dem, was wir da tun, zu verstehen.
Und nicht, dass am Ende ein auslieferbar fähiges Produkt entsteht.
Das machen wir im Peer-Programming.
Das ist auch so eine Grundphilosophie, unterstützt auch beim Lernen.
Man darf sich auch nebeneinander setzen.
Das ist völlig okay.
Man muss das nicht so machen wie die zwei hier.
Und man kann es natürlich auch remote machen.
Und eine Sache, die auch sozusagen eine Grundvoraussetzung ist, wir machen das Ganze testgetrieben.
Wir wollen ja auch versuchen, gute Praktiken sozusagen zu üben.
Und das ist so traditionell beim Code Retreat.
Könnte man auch anders machen.
Aber es hat sich einfach etabliert, dass man testgetriebene Entwicklungen so als Grundmuster hat, dass man den ganzen Tag auch anwendet.
Ja, soweit so gut.
Genau, vielleicht kurz zu testgetrieben.
Also tatsächlich Test First.
Wir werden also tatsächlich einen Test schreiben, bevor wir eine Implementierung schreiben.
Und wir werden versuchen, diesen Zyklus durchzuhalten.
Das heißt, wir machen die Tests grün, indem wir eine Funktionalität implementieren.
Und dann refactoren wir, um es irgendwie hübsch zu machen.
Und dann machen wir den Test wieder grün, damit das Refactoring funktioniert und so weiter.
Das wollte ich nur kurz gesagt haben.
Also wir werden tatsächlich erst einen Test schreiben und dann die Implementierung.
Genau.
Und konsequent an diesem TDD-Zyklus eben noch zu halten.
Und du hattest jetzt schon umgeschaltet in die Idee.
Und ich weiß gar nicht, welche Idee ist das?
Das ist Visual Studio Code.
Also du hattest jetzt…
Genau, der Stack ist TypeScript und V-Test.
Also ein Testing-Tool für TypeScript.
So ein bisschen der inoffizielle Test-Nachfolger wird es manchmal so ein bisschen gehandhabt.
Ist, glaube ich, ursprünglich auch ein Fork gewesen.
Bin ich mir nicht ganz sicher.
Ist aber sehr, sehr ähnlich zu Test, was ja auch wieder sehr, sehr ähnlich zu Mocker ist, was es vorher halt in dieser TypeScript, JavaScript-Community gab.
Genau.
Sie haben alle diese Philosophie mit Described Int.
Also kommt so aus dem Behavior-Driven Development, dass man eben seine Tests so ein bisschen natürlich sprachlich eben auch organisieren kann.
Ist aber trotzdem vom Technischen her ein klassisches Unit-Testing-Framework.
Genau.
Und was wir jetzt eben sehen, ist eben ein Stück Code, wo im Moment getestet wird, ob 1.1 ist.
Also um halt zu schauen, dass halt das Tune-In funktioniert.
Das hat der Marco netterweise vorbereitet.
Und wir würden jetzt sagen, wir uns zu zweit daran setzen, dieses Ding zu implementieren.
Und logischerweise sitze ich nicht an der Tastatur.
Also wir wollen Hyper-Programming machen, sondern Marco sitzt an der Tastatur.
Und wir wollen…
Kurz aus dem Stack.
Vielleicht demonstriere ich das noch ganz kurz, bevor wir an der Stelle weitermachen.
Ich will nur noch eine Sache zeigen.
Also da ist jetzt auch ein Tool integriert, wo wir jetzt ein direktes Feedback in der IDE kriegen.
Das heißt Wallaby.
Und da können wir jetzt beispielsweise, wenn ich jetzt hier einen Fehler einbaue, dann kriegen wir sofort ein Feedback.
Und kriegen halt gesagt, der Test ist jetzt rot, weil 1 halt nicht gleich 2 ist.
Genau.
Das heißt, du hast jetzt Code geändert.
Und tatsächlich erscheint jetzt links neben der Code-Seite bereits ein roter bzw. ein grüner Punkt.
Du hast jetzt gesagt, ist 1, 2.
Und das ist Seite Minich.
Und das hat links daneben jetzt direkt der Hinweis, dass diese Seite fehlerhaft ist.
Genau.
Und wir können natürlich auch Fehler reinbekommen, einfach weil es nicht kompiliert.
Gilt ist für uns genauso rot.
Ob es jetzt nicht kompiliert oder ob der Test sozusagen rot zurückmeldet, betrachten wir beides als einen Fehler im TDD-Zyklus.
Genau.
Und wir würden jetzt tatsächlich ja mit loslegen.
Du wolltest was zum Pair-Programming sagen.
Sorry, ich habe dich unterbrochen.
Achso, ja.
Genau.
Also du sitzt an der Tastatur.
Und wir werden halt gemeinsam gleich diskutieren, wie wir damit loslegen wollen.
Ich will noch kurz so ein paar Fragen aus dem Chat klären.
Also währenddessen würden wir tatsächlich runterprogrammieren, damit wir da ein bisschen Fokus haben.
Da steht halt, ist das Konzept von sozio-technischem System auch etwas, was in deinen Werkzeugkopf verpasst?
Ja, aber das ist kein Thema für einen Code-Retreat.
Test first und Extensions.
Welches ist der häufigste Test, den man benutzt?
Und welches sind die wichtigsten Extensions, die man haben sollte in Visual Studio Code?
Das hast du, glaube ich, gerade beschrieben.
Richtig hast du, glaube ich.
Ja, also ich meine, wichtigste ist ja immer sehr, auch persönliche Präferenz spielt da ja auch mit eine Rolle.
Also das ist jetzt ein bisschen schwer zu sagen, aber ich sage mal, also es gibt so diese typischen Test-Frameworks.
Mocha, Jasmine, Jest, V-Test.
V-Test ist halt eins der moderneren auf jeden Fall.
Genau.
Und benutzt ihr auch AI zur Code-Generierung?
Nee, tun wir halt nicht.
Also das ist richtig oldschool, nicht?
Ich habe ein GitHub-Copilot installiert, aber ich habe den jetzt auch bewusst für die Session deaktiviert, dass der uns da jetzt nicht mit reinkrätscht.
Genau, weil das lenkt zu sehr ab von dem, was wir eigentlich zeigen wollen.
So.
Und damit ist sozusagen alles erstmal gesagt.
Das heißt, wir können jetzt irgendwie loslegen.
Und wir müssen irgendwie diese Regeln implementieren.
Das heißt, wir sollten uns halt irgendeine von den Regeln, die ich jetzt mal vorschlagen, nehmen.
Wir können zum Beispiel sagen, diese Regel mit dem, genau, du gehst ja nochmal irgendwie hin.
Diese Regel mit, wenn ich weniger als zwei Nachbarn habe, ist das Ding haben wir anschließend tot.
Die könnten wir uns ja jetzt hier vornehmen.
Da müssten wir ein Feld bauen.
Also mit Feld meinst du jetzt wirklich, dass das Feld im Großen, das mit allen Zellen und der Verbindung wäre eine Idee, oder?
Das wäre eine Möglichkeit.
Wenn wir das allerdings machen, dann laden wir uns gleich sehr viel Komplexität auf, weil wir dann gleichzeitig also einmal dieses Topologie-Problem lösen müssen.
Also wo stehen die Zellen?
Wie sind sie mit den anderen Zellen verbunden?
Wie sind die Richtungen sozusagen?
Und natürlich auch die Regeln, bei wie vielen lebendigen Nachbarn passiert eigentlich was?
Sodass man die beiden Sachen, sagst du, eigentlich eher trennen sollte.
Eine Sache, die vielleicht auch noch irgendwie spannend ist, so wie das Spiel halt gedacht ist, ist das konzeptionell ja unendlich groß.
Das heißt, wenn wir jetzt ein Array nehmen würden, was irgendwie so meine erste Idee wäre, würden wir das halt schon torpedieren.
Und wahrscheinlich ist das eben vielleicht nicht so toll.
Also das geht vermutlich, aber dann wirst du Probleme kriegen, wenn du quasi an die Ecken des Arrays kommst.
Und dann musst du dir überlegen, was du dann machst.
Also da gibt es sicherlich auch geschicktere Lösungen dafür.
Genau.
Also versuchen wir lieber vielleicht eine Zelle zu machen.
Aber fangen wir vielleicht mal mit einer Zelle an, finde ich eine gute Idee.
Dass wir uns erstmal auf die Regeln selbst konzentrieren und dann kann man ja später dann die Zellen dann versuchen in der Topologie dann auch wieder anzuordnen.
Genau.
Und da hätte man dann ja irgendwelche Möglichkeiten, dass wir Zellen auf andere Zellen verweisen oder wie auch immer.
Gut.
Okay.
Also nehmen wir eine Zelle.
Und die Zelle, sollten wir wahrscheinlich erstmal sagen, dass die lebendig ist.
Weil die Regel sagt, wenn das Ding lebendig ist, wird es halt bei zu wenig Nachbarn anschließend tot sein.
Die Frage ist, wie du es jetzt darstellen möchtest.
Also Zelle könnten wir jetzt natürlich als unterschiedliche Datenstrukturen auch darstellen.
Was wäre eine Datenstruktur, die für dich Sinn macht?
Also ich hätte jetzt eine Klasse gebaut und das hat so klassisch objektorientiert gemacht.
Also hat gesagt, eine Zelle hat einen Zustand und die ist halt lebendig oder tot.
Können wir gerne machen.
Also wir merken natürlich, wir sind jetzt mitten im Design.
Also in dem Moment, wo wir anfangen, diese Regel zu modellieren, müssen wir natürlich auch Gedanken über die Datenstruktur in irgendeiner Form machen.
Das heißt, wir sind jetzt mitten im Designprozess und genau diese Entscheidung müssen wir jetzt an der Stelle einfach treffen.
Okay, du hättest es jetzt gerne klassisch objektorientiert.
Ich lege eine neue Zelle an.
Ja, soweit?
Ja, genau.
Jetzt sind wir an einem Punkt, wo wir schon einen roten Test haben.
Also das genügt schon in dem Moment, um zu sagen, jetzt muss ich irgendwie ein Stück Produktionscode schreiben, um den wieder grün zu kriegen.
Genau, also du hast geschrieben Const Zelle gleich New Zelle und der sagt jetzt irgendwie, Zelle kennt er nicht.
Also die Klasse Zelle kennt er nicht.
Und jetzt kannst du dem Ding sagen.
Das muss ich jetzt, glaube ich, manuell machen.
Jetzt sehe ich die Klasse Zelle tatsächlich an und dann ist das soweit erstmal frei.
Gut.
Jetzt hast du gesagt, du möchtest gerne, dass die mit einer lebendigen Zelle startet.
Möchtest du das über einen Konstruktor machen?
Sollen wir das über einen Setter machen oder was wäre dein Bevorzug?
Ich würde es in einem Konstruktor machen, weil eine Zelle ohne einen Zustand macht irgendwie keinen Sinn.
Ich glaube, ich nehme mal ein Boolean.
Also lebend oder tot kann ich halt über ein Boolean sprechen.
Wir können sowas machen, dass wir sagen, wir packen einfach ein Zoo rein.
Wir können es auch anders machen, dass wir sagen, wir geben ein Property-Objekt rein oder wir geben einen E-Name live rein.
Gibt es verschiedene Möglichkeiten.
Aber wir können auch erstmal mit einer ganz einfachen Lösung anfangen.
Refraction können wir später auch noch.
Stimmt.
Eigentlich könnten wir einen E-Name nehmen, weiß ich gar nicht.
Was dir am liebsten ist.
Dann lass uns doch schauen, ob wir tatsächlich sagen können, you sell a live.
Also nicht, dass wir da einen live übergeben als einen Wert für einen E-Name, der tot oder lebendig sein kann.
Okay.
Dann bauen wir den mal kurz.
Gleicher Punkt.
Wir sind hier wieder bei einem Compile-Fehler, weil der Konstrukte erwartet jetzt keine Argumente.
Das heißt, wir sind jetzt gezwungen, wieder Produktionscode zu schreiben.
Da würde ich jetzt ein Stückchen weiter vielleicht ausholen und sagen, lass uns diesen Typ definieren.
Kann man in TypeScript auch unterschiedlich machen, aber darum geht es ja heute auch gar nicht.
Sondern es geht nur darum, dass wir sagen, wie würdest du den Typ nennen?
Irgendwie dead or alive, sell state, was wäre da ein guter Begriff dafür?
Sell state finde ich gut, ja.
Nochmal?
Sell state finde ich gut.
Okay.
Typkonvention ja groß geschrieben und dann könnte man hier sagen, das ist entweder dead oder es ist alive.
Also das ist eine Möglichkeit, in TypeScript einen E-Name zu definieren.
So genau.
Jetzt brauchen wir aber auch noch einen Konstruktor.
Nichts damit, aber es kombiniert.
Ja, und es ist ein grüner Test, von daher ist es ja frei.
So, dann würden wir halt, glaube ich, der Zelle sagen, dass sie zwei Nachbarn hat.
Okay.
Stimmt doch nicht.
Sorry, weniger als zwei Nachbarn.
Also wir würden der sagen, einen Nachbarn.
Okay, genau.
Also ein Test ist ja immer ein Beispiel.
Das heißt, wir suchen uns als Beispiel einen Nachbarn jetzt raus.
Okay, also einen lebendigen Nachbarn.
Wie machen wir das?
Ich würde sagen, das Ding sollte halt irgendwie ein Attribut haben oder so.
Die Anzahl der Nachbarn.
Okay, also wir können einfach auf ein Public Attribut zugreifen.
Ich kann ein Setter dafür schreiben.
Also auch damals wieder verschiedene Designmöglichkeiten.
Ich würde es als Attribut machen.
Also ich finde, das mit den Set-Methoden ist so ein Java-Überbleibsel.
Okay.
Also wenn ich hinter dem Attribut Logik haben kann.
Man kann diese Zuweisung später mit einem Setter abfangen, wenn man möchte.
Wir können aber einfach mit einem Public Property auch anfangen.
Also Number of Living Neighbors.
Und die soll eins sein, hast du gesagt.
Ja, genau.
Okay.
Gut, jetzt beklagt er sich natürlich, weil die Property gibt es noch nicht.
Dann würde ich jetzt mal anlegen.
Public Number of Living Neighbors.
Datentyp kann erst mal Number sein.
Wenn du nichts dagegen hast, kann man später vielleicht auch nochmal anders machen.
Genau, ich würde mir eigentlich Integers wünschen oder so.
Also nicht ganz optimal wäre halt, wenn ich sagen könnte, das ist ein ganz wichtiger Integer.
Leider gleich 8.
Also was wir machen könnten, wäre, dass wir einen Typ bauen, dem wir Number of Neighbors nennen.
Und sagen, der kann genau diese Werte 1, 2, 3, also quasi eine Art Inam haben.
Aber ist jetzt vielleicht auch ein bisschen Overkill.
Ich finde das so halt fein.
Also du hast jetzt gesagt, Cell Number of Living Neighbors ist 1.
Dann würde ich halt denken, berechne ich die nächste Generation.
Also Excel.CalculateNextGeneration oder sowas.
Nochmal, wie soll die Funktion heißen?
CalculateNextGeneration.
CalculateNextGeneration, jawohl.
Und das ist eine Methode, die wird aufgerufen einfach und macht das als Seiteffekt.
Genau, also die hat eine Wirkung.
Und dann müsste ich halt als Ergebnis haben, dass die Zelle jetzt nicht mehr lebendig ist, also tot ist.
Das heißt, wir fragen von der Zelle den State wieder ab.
Brauchen wir jetzt natürlich irgendwie eine Möglichkeit, darauf zuzugreifen.
Also wie möchtest du das nennen?
Der CellState oder der State.
State ist besser, glaube ich.
Weil wir den Kontext der Zelle schon haben.
Ja, genau.
Also Cell.State wäre dann.
Und der soll, was soll der jetzt sein?
Der soll jetzt dead sein.
Genau.
ToEqualDead.
Das wäre unsere Erwartungshaltung.
Genau.
Irgendwie ist die PropertyState existiert noch nicht.
Die musst du noch einbauen.
Richtig.
Also das ist jetzt wieder unser Rot, weil wir haben unsere Erwartungshaltung formuliert.
Und CalculateNextGeneration gibt es auch nicht.
Genau, das gibt es auch noch nicht.
Genau, das heißt, wir können auch erstmal hier wieder das definieren.
Und können sagen, es gibt ein CellState.
Das ist natürlich ein Typ CellState.
Ja, da ist aber nur State.
Sorry.
Da ist nicht CellState, da ist nur State.
Das ist ein Typ State.
Und die Methode gibt es auch noch nicht.
Achso, da können wir CDE benutzen.
Wir können tatsächlich sagen, DeclareMethod.
Genau, das macht er auch.
Fällt die Position zwar nicht.
Aber gut, das ist.
Okay.
So.
Und dann würde ich mal den Straw hier rausnehmen.
Der sagt, die Methode ist noch nicht implementiert.
So.
Und jetzt kompiliert es zwar.
Aber der Test sagt, er erwartet irgendwie, dass der CellState hier tot ist.
Aber wir kriegen ein Undefined.
Weil wir haben noch nichts zu bewiesen.
Dann kannst du ja jetzt einfach sagen, der CellState ist eben tot.
Also, nicht?
Klar, das wäre natürlich die einfachste Lösung.
Wir können jetzt erstmal nur sagen, es ist Punkt State heißt das.
Genau.
Und jetzt bietet er mir hier an.
Es gibt nur die beiden Möglichkeiten.
Er ist tot.
Ist der Test erstmal grün?
Ja.
Wir haben noch keine Logik implementiert.
Das ist halt natürlich jetzt gefakt.
Aber der Test ist grün.
Genau.
Und damit haben wir ja jetzt sozusagen das Ziel erreicht.
Ich glaube, der Test ist noch nicht so cool.
Also da steht jetzt, it should run a test.
Da sollte irgendwie was anderes stehen.
Also, die Regel heißt irgendwas von…
Wir können nochmal ganz kurz auf den anderen Screen gucken.
Die heißt Underpopulation.
Genau, dann schreib du das mal hier mit dem Underpopulation, oder?
Okay.
Also, wir könnten sagen, it executes…
It dies if underpopulated, oder sowas?
Nochmal?
If underpopulated?
Ah, okay.
Also, it shall dies if underpopulated.
Das ist ja eigentlich das, was wir haben.
Aber wenn du es so machen willst…
Ich kann dann nochmal sagen, wir describen nicht das ganze Game of Life, sondern wir describen die Cell.
Deswegen gibt es hier dieses It.
Das ist immer so die Idee, dass man den Kontext in der Sprache halt mit benutzt.
Also, das ist so der Gedanke, gleich so ein bisschen verhaltensgetrieben vorzugehen.
It dies…
Muss man nicht machen, aber bietet das Framework einfach an.
Cell dies if underpopulated.
Das wäre die Regel dazu.
Und das ist ja eine Spezifikation.
Also, der Test ist eine Spezifikation, die sagt, das passiert eben im Falle der underpopulated Regel.
Genau.
Also, eigentlich müsste man schreiben, if neighbored is underpopulated, aber weiß ich nicht, ob das einstimmig ist.
Ja, gut, gut.
Nee.
Wir können es ja verbessern.
Nee.
Neighbor.
Gut, ich weiß es gar nicht.
Habe ich das richtig geschrieben?
Ich glaube, das hängt davon ab.
Ja, du bist konsistent.
Also, du schreibst es mit nur O, und ich glaube, das ist British English.
Auch British.
Ich glaube, also…
Wir orten uns jetzt gerade als Leute, die keine Ahnung von Englisch haben.
Gut.
Dann lasst uns doch schauen, ob wir die nächste Regel implementiert bekommen, das wäre die Regel mit…
Welche wollen wir denn nehmen?
Ich würde halt sagen, wir nehmen mal die mit, die überlebt, wenn es halt zwei sind, oder?
Also, it survives, if it has two living neighbors, survival rule.
Richtig?
Genau.
So, und dann können wir eigentlich dasselbe…
Also, ich glaube, den Code unten kann man kopieren, oder?
Oder wollen wir so eine Testmethode schreiben, die halt irgendwie Parameter übernimmt?
Okay.
So, genau.
Also, kopiert habe ich es jetzt.
Stimmt es natürlich nicht.
Was müssen wir denn ändern?
Die Anzahl der living neighbors ist zwei.
Okay.
Und dann soll es alive sein.
Dann soll es alive sein.
Gut, verstanden.
Genau, und jetzt kriegen wir auch das Feedback.
Das funktioniert noch nicht.
Also, diese Spezifikation ist noch nicht erfüllt, denn er erwartet…
Genau, er erwartet alive, aber er bekommt halt expected dead.
Das ist das, was er kriegt, dass es eben identisch sein sollte mit…
Weil unsere Implementierung…
Genau, weil unsere Implementierung bei Calculate Next Generation im Moment sagt, this.state ist dead.
Das heißt also, dieses Überleben ist halt einfach nicht drin.
Richtig.
Dann würde ich da jetzt reinschreiben.
If the state…
Also, falls die Anzahl der Nachbarn zwei ist, mache ich da alive.
Okay.
Wir können auch mal kurz ein kleines Experiment machen.
Wenn ich jetzt einfach mal, spaßeshalber, alive reinschreiben würde, fest, dann wäre der neue Test erfolgreich, aber der alte würde brechen.
Okay, guter Punkt.
Das heißt, wir müssen ein If-Statement schreiben.
Es reicht nicht, dass wir jetzt irgendwie das ändern auf dead.
Wir müssen also tatsächlich das If-Statement schreiben.
Das ist halt gezwungenermaßen.
So, was für eine Bedingung soll da jetzt rein?
Number of living neighbors ist zwei.
Number of living neighbors ist zwei.
Und dann soll gelten, this.state gleich…
Sorry.
Ganz kurz.
Tut mir leid.
Klingel deaktivieren.
This.state is alive.
Genau.
Und das andere, mache ich hier kurz, paar syntaktische Geschichten und das wäre dann der Alternativfall.
Richtig?
Genau.
So wolltest du das haben.
Und jetzt haben wir das Grün.
Genau.
Ich glaube, wir können da an der Stelle jetzt sozusagen auch aufhören.
So aus meiner Perspektive, also nur um ein paar Hinweise zu geben.
Die eine Sache, die jetzt natürlich ein Problem ist, ist eigentlich müsste man den Fall bei drei, überlebt die Zelle auch?
Das haben wir jetzt nicht.
Also da muss sich was ändern.
Da müssten wir wahrscheinlich einen Testcase schreiben.
Das wäre jetzt ein nächster Schritt, den ich sehen würde.
Und das andere…
Sorry.
Ich denke, es gibt halt beide Möglichkeiten.
Also ich meine, es ist immer die Frage, wie weit willst du gehen?
Wenn uns das wichtig ist zu sagen, wir wollen den Dreierfall dediziert auch prüfen, dann sollte man natürlich auch nochmal einen eigenen Testcase dafür schreiben.
Aber man könnte natürlich auch sagen, diese beiden Testcases wären in der gleichen Äquivalenzklasse und es wäre okay zu sagen, wir ändern das Verhalten, ohne dass wir an der Stelle jetzt einen speziellen Testfall dafür haben und gehen halt hier auf bei zwei oder drei.
Also gut, wir müssen dann sagen, es muss…
Also in dem Fall wäre es ein größerer Gleichzweig.
Also man sieht schon, auch bei diesen trivialen Dingen vertut man sich dann schnell.
Die Tests sind total hilfreich.
Macht wahrscheinlich immer Sinn, einen Test mehr zu schreiben.
Ja, definitiv.
Und das andere, was mir jetzt gerade auffällt, also das andere, was mir aufgefallen ist, was sozusagen ein To-Do wäre, wir haben jetzt irgendwie so ein Code, der hat gesagt, ich nehme eine lebende Zelle, ich sage halt, die hat so und so viele Nachbarn und ich schaue dann, ob sie hat überlebt oder stirbt.
Und das könnte man daraus faktorisieren.
Also die beiden Tests sehen halt sehr ähnlich aus.
Da könnte man halt irgendwie eine Methode schreiben, die halt irgendwie sagt, okay, ich sage, alive, also nicht alive, ein Nachbar sollte tot sein.
Also da habe ich halt eine Methode, die generell sagt, ich nehme einen Zellzustand, ich nehme eine Anzahl an Nachbarn und ich nehme einen gewünschten Zielzustand und teste halt ab, ob das so weit stimmt.
Da waren jetzt noch Fragen, also Random hatte auf YouTube geschrieben, besser wäre ein Name, ich weiß nicht, worauf sie das bezog, das war um 13.23 Uhr, und hat weiter noch geschrieben, eine Zelle sollte keine Nachbarn haben, sondern Augen, die prüfen, ob ein Nachbar existiert auf dem Grid.
Und dem hat der Jan Wirt bei YouTube zugestimmt.
Genau, das bedeutet, wir haben jetzt eine andere Entscheidung getroffen, das anders zu machen.
Und das führt so ein bisschen zu diesen Retrospektiven.
Also wir sind jetzt irgendwie auf der Retrospektive-Ebene von Code.
Und das, was mir, wir hatten es heute Vormittag auch nochmal kurz zu zweit ausprobiert.
Und was ich halt total spannend fand war, also ich muss gestehen, ich habe mich jahrzehntelang nicht mehr an einem Code Retreat mitgemacht, ich finde das Format irgendwie spannend und ich wollte halt gerne diese Episode machen, weil wir eben so kurz vor dem Global Dev Code Retreat sind.
Was ich halt so spannend fand, war das erste Ding, der erste Test, der nichts tut.
Der tut zwar nichts, aber der ist total hilfreich, um sich klar zu werden, wie ich das Ding überhaupt fundamental aufbaue.
Und beim Vorgespräch war es tatsächlich so, dass ich irgendwie reingegangen bin und gesagt habe, hey, lass uns halt das Feld machen.
Und dann hast du, so wie hier jetzt auch, irgendwie gesagt, nee, das ist ja keine gute Idee.
Lass uns lieber mit der Zelle anfangen.
Und random hätte jetzt eben angefangen und hätte halt irgendwie schon mal diese Beziehung zwischen den Zellen aufgebaut.
Und dann hätten wir halt, und das ist etwas, was wir bei dem allerersten Test, der im Prinzip überhaupt gar keine Logik hatte, der ja nur gesagt hat, als Implementierung in der nächsten Generation ist es tot.
Der hat ja keine Regel implementiert, aber ich habe sozusagen die API festgeklopft.
Und das fand ich halt spannend.
Und das zeigte halt auch, wie wahnsinnig feingranular wir vorgehen.
Also ich weiß nicht, wie viele Testläufe wir jetzt eigentlich hatten.
Also jetzt ja, der Testlauf nicht explizit, sondern der läuft halt im Hintergrund.
Und wir sind halt tatsächlich extrem feingranular, aber auch Test first vorgegangen.
Also das ja vorbildlich halt gesagt, okay, ich schreibe es halt hin.
Da habe ich einen Kompanierungsfehler.
Ich habe halt ein rotes Ding und dann fixe ich es halt so lange, bis es sozusagen grün ist.
Und das war mir nochmal aufgefallen.
Die Idee ist auch immer, dass man eigentlich, sage ich mal, unter 30 Sekunden zwischen Produktions- und Testcode wechseln sollte.
Also dass man wirklich in so einen Mikrozyklus reinkommt, um einfach ein sofortiges Feedback zu bekommen.
Weil je mehr Code du schreibst, bevor du von der anderen Seite wieder ein Feedback bekommst, umso höher ist natürlich auch das Risiko irgendwo, dass das mentale Modell nicht mehr zu dem passt, was eben in Wirklichkeit passiert.
Genau.
Und das ist halt eine von den Sachen, wo man sonst vielleicht irgendwie sagt, das geht ja gar nicht.
Aber hier kann man es irgendwie ausprobieren und es geht halt tatsächlich.
Vielleicht kurz noch zu dem Kommentar von Random.
Also ich meine, es ist natürlich so, dass es hier nicht die eine Lösung gibt.
Es gibt ja ganz viele richtige Lösungen.
Man kann natürlich auch ganz andere Designentscheidungen treffen.
Aber es wäre durchaus möglich, dass wir irgendwann an einen Punkt kommen, wenn wir jetzt sagen, okay, wie funktioniert denn die Typologie?
Jetzt geben wir die Zahl der lebendigen Nachbarn nicht mehr fest vor, sondern es muss die irgendwo ermittelt werden.
Und dass wir dann genau bei so einem Konzept auch landen.
Also das kann auch zu einem späteren Zeitpunkt passieren.
Ich glaube, eine der schönen Möglichkeiten bei Test Room Development ist auch, dass du auch an unterschiedlichen Stellen anfangen kannst.
Also man könnte auch erst die Typologie implementieren und sich erst mal keine Gedanken um die Regeln machen.
Es würde auch funktionieren.
Genau, das sagte ich nämlich auch gerade.
Also sozusagen in der nächsten Iteration wäre das halt etwas, was ich vielleicht Lust hätte dann auszuprobieren.
Man hat diese beiden Rollen gesehen, nicht?
Also ich habe diese Navigator-Rolle übernommen und habe irgendwie gesagt, da will ich halt irgendwie hin.
Und du warst dann der Driver, also der Mensch, der tatsächlich an der Tour saß.
Die Rollen kann man auch wechseln.
Das hatte ich jetzt nicht gemacht.
Also weil ich ehrlich gesagt kein TypeScript kann.
Aber das wäre jetzt auch eine Möglichkeit gewesen.
Wobei das vielleicht auch spannend gewesen wäre, nicht?
Also das wäre jetzt eine Möglichkeit für mich gewesen, sozusagen TypeScript zu lernen an der Stelle, indem du mir halt irgendwie erzählst, was ich halt sozusagen eintippen muss.
Das hätte dann vielleicht irgendwie für eine Änderung der Rollen ganz gut gewesen.
Das ist technisch für uns auch ein bisschen schwierig natürlich, weil wir den Code natürlich auch irgendwie dann teilen müssen.
Und das macht es halt ein bisschen aufwendiger.
Aber ich sage mal, in einem echten Code-Retreat, wo man dann eben noch physisch sitzt oder man hat halt irgendwie eine andere Technik, mit der man den Code sharen kann remote, geht das natürlich auch gut.
Wobei das hier ein Zoom-Call ist, nicht?
Und ich kann ja jetzt einen Rechner fernsteuern, wenn du das zulässt.
Von daher könnte man das halt tatsächlich machen.
Also eigentlich war das halt eine Missed Opportunity.
Aber ich will jetzt Leute nicht damit nerven, dass ich TypeScript lerne.
Das ist jetzt auch nicht der Fokus.
Einfach nur, damit man weiß, also in einem echten Code-Retreat ist es natürlich eher üblich, dass man diese Rollen halt auch häufiger mal wechselt.
Vielleicht auch noch eine andere Anmerkung dazu, was man auch bei uns ganz gut gesehen hat.
Das finde ich auch so elegant an diesem Rollen-Konzept.
Also man kann das noch weiter treiben.
Also wenn man jetzt echtes Strict-Style-Pairing macht, wie das beispielsweise von Lulen Forko beschrieben wird, dann ist die Idee, dass der Navigator halt nur High-Level-Commands gibt.
Und das hast du ja auch im Prinzip gemacht.
Und der Driver macht sich zwar keine Gedanken über das Design, kann aber dem Navigator diesen Low-Level-Teil abnehmen.
Das heißt, du sagst, schreibe eine Klasse, und ich weiß, wie eine Klasse geschrieben wird, und schreibe die Sonntags hin.
Aber du musst dir in dem Moment keine Gedanken darüber machen, wo jedes einzelne Zeichen steht, sondern kannst halt in einem höheren Abstraktions-Level denken.
Genau, also wir haben, das hatten wir vorher auch abgesprochen, dass wir die Rollen sozusagen ein bisschen entspannt haben.
Und wir kommen ja gleich sozusagen noch zu den Constraints.
Das kann man irgendwie auch anders machen.
Also man könnte das jetzt eben…
Ich glaube, es gibt nicht so eine fiese Variante davon, wo man…
Also so könntest du die Rolle auch gestalten, dass du irgendwie sagst, ich mache das, was mir gesagt wird, und ich denke absichtlich nicht darüber nach.
Und dann merkt man halt sozusagen, was dabei rauskommt.
Und dann wäre ich in absoluter Kontrolle.
Aber ich hätte halt nicht dieses…
Du hast ja jetzt Feedback gegeben und hast gesagt, nee, das können wir halt irgendwie so machen.
Und gerade diese Diskussion zu der Zelle, da hätten wir irgendwie auch anders arbeiten können.
Und das kann man auch explizit steuern.
Da gibt es ganz viele verschiedene Pairing Games, die man auch machen kann, um solche Dinge halt auszuprobieren.
Also es gibt tatsächlich ein Constraint, das nennt sich Evil Coder.
Da ist aber eigentlich schon die Idee, dass beide auch abwechselnd Driver sein können.
Nur die Besonderheit ist, dass eine Person quasi die Tests schreibt und die andere Person die Implementierung.
Und die Person, die die Implementierung macht, die hat eigentlich nur das Ziel, die Tests grün zu bekommen.
Egal, ob das jetzt Sinn macht oder nicht.
Und dann bist du als die Person, die die Tests schreibt, irgendwo in der Verantwortung, wirklich richtig gute Tests zu schreiben, die dich dazu zwingen, oder die die andere Person dazu zwingt, dass am Ende des Tages auch eine sinnvolle Implementierung rauskommt.
Genau, da sind wir wieder bei dieser Diskussion, nicht Number of Living Neighbors, also mehr sagen ex act.
Zwei kriegen wir, dann ist es halt lebendig, dann kriegen wir den Test grün.
Aber das ist natürlich nicht das, was wir eigentlich wollen.
Und da wäre jetzt bei Ivo Coder wäre es eben so, dass man dann den dazu zwingen müsste, eine weitere Testmethode zu schreiben, die man halt sagt, okay, machen wir bitte noch den Test mit drei.
Sondern muss ich eben auch diesen frei sozusagen abfangen.
Genau.
Also natürlich will man das nicht in der Praxis so machen, aber man kann daraus halt einiges lernen darüber, wie man Tests halt sehr explizit halt auch schreibt.
Ja.
Also ich befürchte, ich muss noch mal auf dieses Resource Management Thema zurückkommen.
Also das ist auch etwas, was eben im Flugverkehr so ist.
Da ist halt die eine Person am Steuer und die andere ist eben diese Person, die dann auf dieser anderen Ebene arbeitet.
Das hat sich hier ja auch ein bisschen etabliert.
Man kann da halt auch sehr gut erkennen, dass irgendwie dieser Feedback-Zyklus, so wie wir es jetzt gemacht haben, eben deutlich produktiver ist, als wenn man jetzt irgendwie sagt, nee, wir arbeiten sogar ein bisschen sozusagen gegeneinander.
Genau, du hast noch Folien vorbereitet, weil wir haben ja jetzt nur einen sehr kleinen Ausschnitt gesehen, wie das sozusagen sonst darüber hinaus noch laufen würde.
Genau, das waren die Regeln.
Ja, was wir jetzt zwar im Grunde genommen auch schon gemacht haben, aber auch vielleicht nicht so explizit gesagt haben, das sind die Four Rules of Simple Design, also auch ein Konzept von Kent Beck.
Wobei die Idee ist, dass man halt so vier Regeln hat, die man grundsätzlich folgt und die halt in einer bestimmten Reihenfolge auch ganz bewusst angeordnet sind.
Und da ist halt die erste Regel, sollten alle erfolgreich sein, die sollten alle grün werden.
Das ist immer so die Voraussetzung, dass man sich erst mal darum kümmert, dass es funktioniert.
Und wenn es dann funktioniert, und dann kann man eben in den Refactoring-Mode gehen und kann sagen, was können wir jetzt verbessern?
Wir können Duplikation rausnehmen, wie du ja auch schon erklärt hast.
Also beispielsweise auch im Test kann man natürlich Duplikation ausnehmen, aber auch im Produktionscode.
Also sobald wir halt in der Lage sind zu sagen, wir haben grüne Tests, können wir die Duplikation versuchen zu verringern.
Wir können Refactoring machen, um den Code lesbarer zu gestalten.
Maximize Clarity.
Da kann man sich so ein bisschen streiten, welche der beiden Regeln ist wichtiger.
Manchmal spielen die auch so ein bisschen gegeneinander.
Da muss man dann halt kluge Entscheidungen treffen.
Und die letzte Regel ist, has fewer elements.
Also wenn die anderen Regeln erfüllt sind und man schafft das Ganze mit weniger Methoden, mit weniger Klassen, mit weniger Variablen, was auch immer, weniger Codezeilen hinzubekommen, dann versucht man das eben auch zu minimieren.
Aber deswegen haben die Regeln eine Reihenfolge.
Wenn ich dadurch Klarheit verliere oder auf einmal wieder Duplikation reinkriege, dann habe ich lieber mehr Elemente, wenn damit die anderen Regeln sozusagen besser erfüllt sind.
Also wenn sich mehr Code oder mehr Elemente verringern.
Das Design im Prinzip getrieben wird, nicht?
Also wir haben jetzt uns gerade nicht hingesetzt und haben gesagt, lass uns mal kurz den Stift rausholen und schauen, wie wir dieses Ding überhaupt aufteilen und bauen.
Sondern wir haben im Prinzip reingesprungen und haben gesagt, wir machen diese Geschichte mit der Nachbarschaft und das versuchen wir irgendwie sauber zu machen mit diesen vier Regeln.
Und dann kommen wir mit den nächsten Themen, nicht?
Und du hast es ja gesagt, also ich hätte jetzt auch mit der Nachbarschaft anfangen können und Quatsch mit der Gesamt-Topologie anfangen können oder nicht random, hatte halt noch mal eine andere Idee.
Und ich komme dann sozusagen von unterschiedlichen Stellen, gehe ich halt dahin, aber ich habe nicht den großen Plan vorher mehr gemacht.
Da will ich eigentlich auch eine Frage loswerden. Überfordert es nicht die Leute?
Also klappt das immer, dass man sagt, schreibt mal ein bisschen, schreibt mal bitte ein bisschen Code und denkt nicht über das Große nach, das wird sich schon herausstellen.
Also das ist mindestens ungewohnt.
Aber führt das irgendwie auch dazu, dass dann irgendwie komische Entwürfe entstehen und man irgendwie das Gefühl hat, dass das funktioniert irgendwie gar nicht?
Also wie ist da deine Erfragung?
Ist das eine große Hürde?
Die Idee sagt ja nicht, dass du das immer so machen musst.
Also das ist ja erst mal nur.
Also ich meine, wir haben jetzt sozusagen die extreme Form praktiziert.
Also tatsächlich ist es sogar extremer als das, was Ken Beck in der Original Chicago School selber vorschlägt.
Weil was Ken Beck machen würde normalerweise, ist erst mal eine Liste von, also quasi das, was wir in den Int-Blöcken beschrieben haben.
Also eine Liste von potenziellen Tests erst mal zu finden.
Also er würde erst mal hingehen und hier erst mal mehrere Ints hinschreiben und sagen, was sind denn alles Testfälle?
Könnte man beispielsweise hier im Framework auch als To-Do markieren.
Was sind dann alles Testfälle, die wir uns schon mal überlegen könnten?
Was brauchen wir denn?
Damit hast du auch schon mal so ein bisschen ein Vorausdenken.
Das wäre tatsächlich das ganz klassische Vorgehen.
Wir haben sozusagen noch extremere Formen gewählt.
Aber es gibt eben auch andere TDD-Schulen, also beispielsweise die Hamburg School von Ralf Westphal, die macht genau das Gegenteil.
Also was Ralf macht, ist, er wird also ganz klassische objektorientierte Analyse und Design machen im Vorfeld.
Erst wenn er dann weiß, sozusagen so sieht mein Design aus, erst dann fängt er an, die einzelnen Elemente per TDD zu treiben.
Also er würde da eine einzelne Methode beispielsweise testgetrieben entwickeln.
Aber er würde sich jetzt nicht das Design der Klasse von TDD grundsätzlich liefern lassen, sondern das hätte er im Vorfeld sich schon überlegt am Reißbrett sozusagen.
Also es gibt da unterschiedliche Schulen, unterschiedliche Denkweisen, wie man das in dem Umfeld auch einsetzen kann.
Und meine persönliche Meinung ist, es gibt da nicht die eine Wahrheit, sondern es kommt halt einfach sehr auf die Situation und auf die Leute an, was gerade am besten funktioniert.
Also ich glaube, da gilt halt so dieses alte Goldilocks-Prinzip.
Also zu viel Design upfront ist meistens nicht gut.
Also wir kennen das von früher noch, die ein halbes Jahr vergraben, UML-Diagramme bauen.
Elfenbein-Architekt hast du ja auch schon öfter mal erwähnt.
Den Begriff ist sicherlich nicht gut.
Sich überhaupt keine Gedanken machen und immer sofort mit dem Code loslegen, ist aber sicherlich in vielen Fällen auch nicht die perfekte Praxis, sondern die Wahrheit liegt halt irgendwo dazwischen.
Und wo sie genau liegt in diesem Spektrum, kann halt sehr unterschiedlich sein.
Und das würde jetzt bedeuten, ich könnte diese unterschiedlichen Schools, die du halt genannt hast, eben dann auch, nehme ich an, in so einem Kulture-Retreat einführen als Constraints, dass man halt in diese Richtung gebracht wird.
Genau, das haben wir auch schon öfter gemacht.
Das war so gezielt sagen.
In dieser Session machen wir diese speziell, diese eine TDD-School, um halt mal diese Vorgehensweise zu lernen.
Genau.
Zu sehen, wie gut sie für uns auch funktioniert.
So, dann hattest du, genau, können wir eigentlich zur nächsten Folie übergehen, glaube ich.
Genau, da geht es jetzt schon mal so ein bisschen um die Fragestellung, und was wir jetzt im Prinzip gezeigt haben, war ja eine Cutter, die wir beide halt zusammen durchgeführt haben.
Coding-Dojo ist noch so ein Begriff, was so ein Setup wäre, in dem man so eine Cutter machen kann.
Was ist jetzt das Besondere am Kulture-Retreat?
Genau, vielleicht kurz dazu.
Also Cutters sind halt motiviert durch das, was man im Kampfsport, glaube ich, hat, wo man halt bestimmte Bewegungen halt immer öfter mal durchführt.
Und das gibt es ja irgendwie für Coding auch.
Und wir machen aber einen Kulture-Retreat und da gibt es eben einen Unterschied.
Und das ist das, was wir gerade diskutieren.
Genau, also im Grunde ist eine Cutter eigentlich eine Übung, die man auch häufiger wiederholen kann, wo man dann auch bei jeder Wiederholung vielleicht nochmal neue Aspekte lernt.
Und genau das will man im Kulture-Retreat weiter treiben.
Und deswegen macht man fünf Sessions auf 45 Minuten.
Also wenn man viel Zeit hat, kann man auch mehr Sessions machen.
Also ich kann mich erinnern, in der frühen Zeit haben wir sieben Sessions gemacht.
Hat sich aber herausgestellt, dass das für die meisten Beteiligten, inklusive der Moderatoren, deutlich viel zu anstrengend war nach so einem langen Tag.
Deswegen so typischerweise macht man fünf Sessions auf 45 Minuten.
Und in jeder Session fängt man jedes Mal wieder komplett von vorne an, das Game of Life zu bauen.
Genau, was halt bedeutet, es ist ein ganz tägiges Ding.
Und dieser Global Day of Culture-Retreat ist eben an einem Samstag, was eben auch bedeutet, dass es Leute in erster Linie anspricht, die hier drinnen sich motiviert sind und da gerne hingehen wollen.
Natürlich hält einen niemand davon ab, so etwas firmenintern zu machen.
Der ursprüngliche Gedanke war halt dieser Retreat-Gedanke, dass man nicht gestört wird von typischen Business-Themen, die man im Alltag einfach hat, sondern dass man sich konzentriert zurückziehen kann.
Nach diesen 45 Minuten wirft man quasi die Lösung komplett wieder weg.
Das ist auch am Anfang immer so ein bisschen schockierend.
Ich habe doch jetzt gerade eine tolle Lösung geschrieben.
Und warum soll ich die jetzt wieder wegwerfen?
Aber das ist tatsächlich ein wichtiges Element, dass man das tut.
Weil es einem eben auch befreit, weil es dazu führt, dass quasi jedes Mal man wieder Greenfield anfängt, dass man auch gar nicht in die Versuchung kommt.
Irgendwie Code aus der letzten Lösung zu kopieren und man einfach die Chance hat, neue Design-Entscheidungen auszuprobieren, neue Wege zu gehen, um zu anderen Erfahrungen zu gelangen.
Ja, genau.
Du hattest im Vorgespräch, glaube ich, gesagt, dass das eine von den Sachen ist, die irgendwie schwer vermittelbar ist, sozusagen für AnfängerInnen.
Mir ging das am Anfang genauso.
Also in meinem ersten Code-Retreat, wo ich teilgenommen habe, und dann hieß es auf einmal, jetzt bitte alle den Code löschen.
Das ist halt erst mal so ein Schock, weil du bist es halt nicht gewohnt, in deinem Daily-Business irgendwie Code wegzuwerfen.
Das ist ja immer…
Also eigentlich wäre es auch da ab und zu total sinnvoll.
Aber das ist immer erst mal so eine Überwindung, die man da schaffen muss.
Genau.
Und was hier jetzt…
Also wir kommen ja gleich noch zu den Constraints.
Also das heißt, eine Sache, warum das vielleicht sinnvoll ist, weil man halt vielleicht dann in den nächsten Iterationen was anderes macht, also anders halt testgetrieben zum Beispiel vorgeht.
Und ich muss halt gestehen, ich hätte jetzt irgendwie total Lust darauf, gerade das Gegenteil zu machen, also nicht mit Zellen, sondern irgendwie zu sagen, ich nehme mir erst mal das Feld vor und versuche irgendwie herauszufinden, wie ich ein Feld baue, welche Datenstruktur ich benutze.
Also wahrscheinlich irgendwie kein Array und wie ich dazu was halt bekomme.
Mivo hat geschrieben, in der London School machen sie ja theoretisch relativ viel Design im Vergleich zu Kent Beck Style.
Ich glaube, das hatten wir gesagt, nicht?
Also ich weiß nicht, ob du da noch was zu sagen willst.
London School ist eine TDD-School, bei der man eben noch outside-in vorgeht.
Das heißt, man fängt sehr, sehr high-levelig an und bricht es dann in kleinen Schritten runter.
Das ist absolut richtig, ja.
Dann hat man natürlich auch viel mehr Design ab Front.
Keine Frage.
Wie würde ich denn dafür Game of Life vorgehen nach der London School?
Kannst du das illustrieren?
Du würdest einen Akzeptanztest am Anfang schreiben.
Also tatsächlich so ein bisschen in die Richtung, was du ganz am Anfang vorgeschlagen hast, dass man eben auch ein Feld schon designt in irgendeiner Form.
Also das heißt nicht unbedingt, dass man jetzt die komplette Datenstruktur schon hat, aber dass man sich die äußere API überlegt.
Und einen Akzeptanztest schreibt, wo man sagt, ich habe eine Grundkonfiguration.
Ich sage mal, der Klassiker wäre so was wie ein Oszillator, wo ich dann vier Zellen in einer bestimmten Konfiguration und ich weiß, wie die nächste Generation aussieht.
Und dann bestücke ich das komplette Feld, schaue mir die nächste Generation an und prüfe tatsächlich das komplette Feld.
Also ob alle Zellen in der nächsten Generation sich richtig verhalten haben.
Das heißt, du kannst dann auch quasi in einem Test gleich mehrere Regeln auf einmal testen, wenn du das möchtest.
Und hast dann halt einen sehr umfangreichen Akzeptanztest, der aber sehr, sehr lange rot bleiben wird.
Und dann kommentierst du den erst mal aus, sorgst erst mal dafür, dass der nicht ausgeführt wird und nimmst dir dann aus diesem Akzeptanztest den ersten kleinen Schritt raus, den du dann wiederum als Unit-Test formulieren kannst, um dich dann Schritt für Schritt reinzutesten.
Und dabei verwendet man die ganze Zeit halt Mocks oder Stubs, also im Wesentlichen Mocks bei der London School, um dann eben den Code, den man ja noch nicht hat, dann erst mal auf der höheren Ebene quasi zu simulieren.
Okay, alles klar.
Gut, hört sich spannend an, nicht?
Also wäre auch ein Versuch, was man versuchen könnte, auszuprobieren.
Und dann kriegt man halt auch raus, wie sich das anfühlt, nicht?
Also ich finde das, für mich hört sich das jetzt gerade komisch an, weil du ja richtig gesagt hast, der Test bleibt ja lange Zeit rot.
Wir haben nur 45 Minuten, am Ende habe ich dann einen roten Test.
Keine Ahnung, also wäre ja zu meinem Gefühl, dass das vielleicht dann tatsächlich gerade in so einem Code-Ruleshield ein bisschen komisch auswirkt.
Aber das könnte man ja genau ausprobieren.
Und nach den Iterationen, ich glaube nicht, ich weiß nicht, ob du das gesagt hattest, würde man ja auch genau das nochmal machen, nicht?
Also irgendwie sagen, okay, was habt ihr gelernt?
Was sind so Themen?
Das so ein bisschen retrospektiv betrachten.
Da haben wir gar nicht drüber gesprochen, aber du hast es vorhin schon mal erwähnt.
Also das ist ja ein ganz wichtiger Aspekt auf jeden Fall, ob man nach jeder dieser Sessions auch nochmal eine Retrospektive macht und nochmal drüber redet.
Was habe ich jetzt eigentlich gelernt?
Was habe ich mitgenommen?
Manchmal treibt man Dinge auch ins Extreme, um zu sehen, dass sie eben auch nicht gut funktionieren, um eben genau auch dieses Learning mitzunehmen, zu sagen, okay, wir haben es mal ausprobiert.
Ich weiß jetzt, bis wann diese Methodik nützlich ist und ab wann sie eben eher problematisch ist, als dass sie mir hilft.
Genau.
Das andere, um nochmal zu diesem Greenfield zurückzugehen, ist natürlich, man kann auch völlig einen Chunk-Code schreiben und das ist okay.
Also ich meine, die Idee ist halt auch, wir wollen experimentieren.
In der Praxis sind wir immer irgendwo getrieben zu sagen, wir müssen den Code schreiben, der uns jetzt irgendwie weiterbringt, der das Feature halt irgendwie erfüllt und auf jeden Fall auch auslieferbar ist.
Aber hier haben wir auch mal die Chance zu experimentieren und zu sagen, wir schreiben mal was, einfach weil wir mal verstehen wollen, was dann passiert.
Und es muss uns nicht peinlich sein, weil wir wissen genau, in spätestens oder sagen wir mal in durchschnittlich 22,5 Minuten ist der Code wieder weg.
Das heißt, dieses Löschen befreit einen auch so ein bisschen im Sinne von, ich weiß noch nicht, ob ich so weit gehen würde, dass ich sagen kann, Psychological Safety, aber es bringt eine gewisse Sicherheit mit.
Also was auf dem Code-Retreat passiert, bleibt auf dem Code-Retreat.
Ich kann mich austoben.
Ich kann Dinge lernen, ohne Angst zu haben, mir irgendwo die Blöße geben zu müssen.
Ja, und ich bin mir gar nicht sicher, ob man diesen Faktoren, also ob du den, ich glaube, der ist halt tatsächlich wichtig.
Also genau dieser Faktor, den du ansprichst, dass man irgendwie danach das Zeug halt nicht mehr hat und halt darüber, weiß auch nicht, ob ich es Psychological Safety nennen würde, aber nicht, dass man halt einfach sagt, okay, ich habe halt das Learning und das Zeug ist halt irgendwie weg und damit muss ich mich halt nicht mehr belasten und das war’s.
Also der Experimentiergedanke wird dadurch halt, glaube ich, noch viel stärker.
Und genau, deswegen hatte ich ja eben auch mir gedacht, dass ich das eben tatsächlich selber mache, weil ich hatte es ja gesagt, ich habe irgendwie keine Ahnung von Typescript, aber man kriegt es halt trotzdem hin.
Gerade so aus einer Driver-Position brauche ich halt nicht dieses Know-how und ich hatte es gerade eben gesagt, also wenn ich jetzt die Intention hätte, Typescript zu lernen, wäre das vielleicht eine Option.
Also ich erinnere halt auch immer, dass, als ich mal bei einem Code-Reachit war, dass halt jemand war, der halt mit irgendeiner Python oder so gearbeitet hat und halt gemeint hat, hey, ich will halt gerne mit jemanden zusammenarbeiten, der java macht, weil die haben ja irgendwie diese tollen Ideen, die irgendwie ganz viele coole Features haben und ich will das gerne mal sehen.
Und das sind so Sachen, die man da irgendwie auch ganz gut mal sich antun kann.
Auch super wichtiger Aspekt.
Also zum einen, genau, kann man das einfach mal machen, dass man sagt, ich arbeite mal bewusst in der Programmiersprache, die ich nicht kenne, um es mal zu sehen, um es mal zu lernen.
Und das andere ist halt, dadurch, dass du im Code-Reachit, das haben wir, glaube ich, auch nicht gesagt, also wir machen ja Pair-Programming, aber wir machen diese fünf Sessions ja auch nicht mit demselben Pairing-Partner, sondern im Code-Reachit wechseln ja auch die Pairs.
Das heißt, man hat immer einen anderen Pairing-Partner und da ist ja auch die Idee, dass man sozusagen von anderen Leuten ja auch Wissen abgreifen kann.
Wenn ich jetzt mit jemandem paire, ich bin kein Java-Entwickler, der aber einfach fit ist in seiner Java-Idee und dann bekomme ich mal einen Eindruck davon, wie arbeitet man denn überhaupt mit Java?
Wie können einem die IDE-Features denn da auch supporten?
Das ist eine Erfahrung, die ich sonst selber gar nicht so bekommen könnte.
Aber wenn ich mit jemandem paire, der das halt kennt, habe ich eine sehr schnelle Möglichkeit, das auch zu lernen.
Genau, und die Teilnehmerinnen bringen auch ihre Laptops mit.
Das heißt also, das, was wir jetzt hatten, dass du eine besonders vorbereitete Entwicklungsgewohnung hast, das würden wir eben auch erwarten, dass das eben bei den Teilnehmerinnen typischerweise dabei ist.
Ich glaube, wir haben noch eine Folie.
Du hast noch eine Folie.
Vielleicht noch ganz kurz einen Aspekt noch dazu.
Also, was ich auch spannend finde, also wir fragen oft am Code Retreat auch, mit welchen Sprachen die Leute unterwegs sind.
Und da trifft man halt auch mal auf Sprachen, die vielleicht nicht so häufig vertreten sind.
Also z.B. habe ich auch schon mal APL in dem Code Retreat kennengelernt, was schon eine relativ exotische Sprache ist.
Man kann das Game of Life tatsächlich in einer Zeile APL-Code lösen.
Das komplette Game of Life habe ich gelernt.
Und ich finde es eine spannende Gelegenheit, auch mal mit jemandem zu paaren, der eben vielleicht mit einer exotischeren Sprache unterwegs ist, um halt, sage ich mal, eine Erfahrung zu kriegen, die man sonst eigentlich gar nicht die Gelegenheit hätte.
Der Miwo hat noch gefragt, Outside-In wäre dann der ingoing-Port in Hexarch oder wirklich UI oder so?
Ich verstehe im Moment die Frage noch nicht so ganz.
Die ist tatsächlich…
Ich meine ja meine hexagonale Architektur.
Ja, das ist klar.
Also wo ich eben sage, ich habe halt den Business-Hogelkern und da habe ich halt drumherum diese Adapter, die halt irgendwelche Ports implementieren.
Der hat von der Geschäftsforschung gekommen und da hat er geschrieben, Outside-In wäre dann der ingoing-Port in Hexarch oder wirklich UI oder so?
Das Problem ist, dass wir jetzt hier unterscheiden müssen zwischen Methodik und Code.
Also mit Outside-In ist jetzt ja keine bestimmte Konfiguration oder kein bestimmtes Design gemeint, sondern es geht um die Vorgehensweise, dass ich außen anfange.
Also das eine hat mit dem anderen eigentlich wenig zu tun.
Du kannst natürlich, wenn du Outside-In arbeitest, auch eine hexagonale Architektur verwenden oder ein hexagonales Architekturmuster verwenden.
Aber das eine ist die Methodik und das andere ist halt das konkrete Design.
Das sind zwei unterschiedliche Aspekte.
Okay, Outside-In ist dieses, wo ich sage, ich fange mit dem Akzeptanz-Test an und dann baue ich halt das freien Granulare.
Also ich kann mir schon vorstellen, dass es da einen Zusammenhang gibt, weil ja bei der hexagonalen Architektur der Vorteil ist, dass ich von draußen Tests haben kann und Akzeptanz-Tests, der sozusagen dann eben…
Du könntest deine Akzeptanz-Tests an den Ports deiner Applikation andocken und müsstest halt nicht durch die Adapter gehen sozusagen.
Da kannst du auf Logik und Wissen arbeiten und hast erst mal nicht die ganze Technicality ist halt erst in den Adaptern.
Also es hilft auf jeden Fall.
Also hexagonale Architektur würde auf jeden Fall unterstützen, das Ganze testbarer zu machen.
Keine Frage, ist auch eins der Ziele.
Genau, gut.
So, jetzt haben wir noch die letzte Frühe, glaube ich.
Genau, und das war jetzt einfach nur noch mal als Info, dass man halt im Kurzbetriebs eben auch Constraints hat.
Wir haben ja auch schon viel drüber gesprochen, tatsächlich, und bei einem Constraint ist es halt tatsächlich so die Idee, dass man sich quasi so eine Handschelle irgendwie an den Arm macht und sich einfach Dinge wegnimmt, die man normalerweise hat, die man normalerweise gewohnt ist zu nutzen.
Also ein Constraint könnte zum Beispiel sein, in dieser Session darf ich kein If-Statement verwenden.
Das ist ein Constraint, weil normalerweise ist man es gewohnt, haben wir jetzt auch gerade genutzt.
Wenn ich diese Möglichkeit nicht habe, muss ich eine andere Möglichkeit finden, zu einer Lösung zu kommen.
Und die Idee von Constraints ist, dass man sich quasi zwingt, andere Wege zu erforschen.
Also vielleicht noch ein klassischeres Beispiel wäre, ich darf keine Schleifen verwenden, dann muss ich vielleicht mit Higher-Order-Strukturen wie Map-Filter-Retuse arbeiten und kann daraus eben was lernen.
Wenn ich es nicht gewohnt bin, mit Map-Filter-Retuse zu arbeiten, zwinge ich mich dann dazu, indem ich halt vorher sage, ich darf halt keine Loops verwenden, oder ich komme zu einer anderen Lösung.
Aber das ist so, ja, Constraints gibt es auch auf ganz unterschiedlichen Ebenen.
Man kann auch sagen, beispielsweise ich mache ein Constraint, wo es mir darum geht, vielleicht die Keyboard-Shortcuts meiner IDE besser zu verinnerlichen.
Und dann ist das Constraint, ich darf die Maus nicht anfassen.
Dann nehmen wir die Maus und legen die woanders hin, oder schalten das Touchpad vom Laptop ab und zwingen uns dann sozusagen zu gucken, wie kann man das Ganze mit der Tastatur steuern und lernen halt durch dieses Constraint wieder andere Dinge.
Genau.
Wir sind tatsächlich ein bisschen über die Zeit.
Ich will trotzdem, also Hinweise geben, nicht grübelt ihr auf Kultus-Field.
Es gibt wahrscheinlich bei euch in der Nähe halt auch welche, wir hatten gerade eben noch mal auf die Webseite geguckt.
Das sind halt eine Vielzahl.
Das heißt, im deutschsprachigen Raum würde ich halt erwarten, dass man da wahrscheinlich irgendwie was auf die Reihe bekommt.
Die Folien und so packe ich irgendwie auch noch mal als Links da rein.
Und ich glaube, das ist halt so ein bisschen ein guter erster Schritt, dass man eben sagt, okay, ich nehme halt an so einem Kultus-Field teil.
Wie würdest du vorgehen, wenn du selber so was durchführen willst?
Also in deiner Firma beispielsweise oder wie auch immer?
Würdest du dir das, also für mich wäre, also der offensichtliche Weg, so habe ich es gemacht, ist teilnehmen und dann halt selber machen und sich das halt irgendwie zutrauen und Chances are, es funktioniert halt irgendwie und es gibt auf CodeRetreat.org irgendwie auch Unterlagen.
Würdest du dich daran wagen, während, also hast du eine andere Idee?
Würdest du dich daran wagen, wenn du nicht vorher schon mal in einem CodeRetreat warst?
Also, ja, wie du schon sagst, das ist natürlich die beste Lösung, erst mal irgendwo teilzunehmen.
Das ist ja auch relativ einfach, weil es gibt ja viele CodeRetreats in verschiedenen Städten oder man kann auch remote dran teilnehmen.
Das würde ich auf jeden Fall empfehlen, wenn es diese Möglichkeit nicht gibt oder man es nicht schafft.
Auf der CodeRetreat.org Seite hast du ja auch schon gesagt, gibt es auch eine Menge Lernmaterialien tatsächlich, wo das auch relativ genau beschrieben ist.
Also was muss ich als, also typischerweise gibt es ja zwei Rollen.
Es gibt den Moderator und es gibt den Host und dann, da steht dann auch drin, was muss ich als Host machen?
Was muss ich vorbereiten?
Was brauche ich denn für eine Umgebung?
Was muss ich als Moderator tun?
Aber ich sage mal so, es ist eigentlich ein so stabiles Format und selbst, also man kann eigentlich auch wenig falsch machen.
Und selbst wenn man Dinge anders macht.
Man kann ja nur daraus lernen, also es kann ja nichts.
Also was soll das Outcome sein?
Also im schlimmsten Fall hat man gemerkt, man hat es ein bisschen anders gemacht, als der offizielle Wegen CodeRetreat zu machen.
Und wenn alle dabei was mitnehmen, was daraus lernen, ist das ja auch okay.
Also von daher glaube ich, man kann das einfach machen.
Man kann sich das einfach trauen.
Und es gibt ja keine, man muss das ja nicht beide Bruch machen.
Sonst kann ja auch jeder seine eigene Form finden.
Ja, ich finde, das ist ein ganz wichtiger Hinweis, nicht?
Also es kann sozusagen nicht schiefgehen.
Ich glaube, das ist halt bei vielen von diesen Moderationsgeschichten wir hatten auch die Episode mit dem Martin Günther, diese, das Vertrauen darin, dass dabei schon was Sinnvolles rauskommt.
Und du hattest am Anfang eben auch, du hattest beim Vorgespräch gesagt, das ist ja auch was, was durch mehrere Iterationen tatsächlich entwickelt worden ist.
Also für mich wirkt das ja natürlich, wie es halt so häufig halt ist, ist das aber etwas, wo es halt viele, glaube ich, viele Iterationen davor gab, sodass es eben wahrscheinlich wenig schiefgehen kann.
Dann, was ich mitgenommen habe, ist, man sollte sich halt jemanden noch dazu holen.
Und das finde ich halt auch ein guter Punkt.
Diese Rollenteilung ist, glaube ich, gut.
Ja, dann haben, also mir wurde noch geschrieben, mich jetzt um die Akzeptanz.
Das frage mich manchmal, wo der Startpunkt ist, wenn man outside in entwickelt.
Finde ich auch ein sehr spannender Punkt, also weil man kann auf unterschiedlichen Höhen anfangen, natürlich.
Also ich meine, es gibt auch Leute, die machen A-TDD, also Akzeptanz getriebenes Test Driven Development und da ist es tatsächlich üblich.
Also für Martin Gärtner gibt es beispielsweise ein Buch darüber auch, wo er das sehr genau beschreibt.
Und der startet tatsächlich bei der UI, also wo wirklich die ganze Anwendung sogar nicht nur von der Business-Logik aus entwickelt wird, sondern wo der Akzeptanz-Test auf UI-Ebene erst mal startet.
Und das ist natürlich auch noch mal ein ganz anderer Ansatz.
Genau, bleibt mir noch zu sagen übrig nicht.
Also wenn euch das interessiert hat, geht gerne zum Global TF Code Research.
Es gibt da ganz viele Sachen.
Du bist bei der Date für Nürnberg dabei und ich verlinke das alles.
Und nächste Woche wird es alle Voraussicht nach eine Episode geben.
Ich muss mal schauen, wie ich das genau organisiere.
Wahrscheinlich nicht am Freitag.
Genau, würde ich sagen.
Vielen Dank.
Schönes Wochenende und bis dahin.
Danke für die Einladung.
Hat Spaß gemacht, wie immer.
Schönes Wochenende.