Im Podcast erwähnte Verlinkungen

• FizzBuzzEnterpriseKata

Weitere Ressourcen

Katas / Dojos Online: Cyber Dojo

Plattformen für Katas: Exercism, Codewars

Blogartikel über Katas

Blogartikel über Coding Dojos

Blogartikel über Coderetreats

Matthias: [00:00:03.58] Hallo zusammen, hier sind Matthias

Alex: [00:00:05.71] und Alex. Und das ist die Macht der Kraft.

Matthias: [00:00:09.04] Heute reden wir darüber, wie du dich im Bereich der Softwareentwicklung verbessern kannst.

Alex: [00:00:14.65] Das Zauberwort heißt Übung. Übung macht den Meister.

Matthias: [00:00:19.12] Wir sprechen heute über drei Methoden, die uns helfen, unsere Fähigkeiten zu schärfen. Code Katas, Coding Dojos und Coderetreats.

Alex: [00:00:27.37] Das sind drei Möglichkeiten zu trainieren. Je nachdem, ob du alleine oder in einer Gruppe bist, bietet sich eine andere Methode an.

Matthias: [00:00:35.23] Damit du in deinem Alltag besser mit wiederkehrenden Problemen umgehst. Es ist wichtig, diese hin und wieder in einer sicheren Umgebung gelöst zu haben.

Alex: [00:00:43.15] Höre dir diese Folge an, um zu erfahren, wie diese Methoden funktionieren und wie du sie zu deinem Vorteil verwendest.

Off: [00:00:52.10] Die Macht Der Craft arbeitet für dich.

Alex: [00:00:58.23] Ich erinnere mich an eine Zeit in der Softwareentwicklung, in den ich zu einem gewissen Grad überhaupt keinen Bock mehr hatte auf die Arbeit, der hat keinen Spaß mehr gemacht. Es war nicht mehr schön, was wir da gemacht haben. Es war, wie arbeiten am Fließband. Am Anfang des Projekts stand schon fest, wann es fertig sein soll. Aber keiner wusste genau, was eigentlich zu tun ist. Lauter vage Vermutungen und immer am lebenden Patienten herumdoktern. Einfach ins kalte Wasser geschmissen und Code Code Code, es muss fertig werden. Es hat überhaupt keinen Spaß gemacht. Die Qualität hat auch darunter gelitten. Alles dauert länger als gedacht. Warst du schon mal in so einer Situation? Matthias oder kannst ein bisschen davon erzählen?

Matthias: [00:01:40.62] Oh ja, selbstverständlich. Ich kenne ähnliche Probleme. Also gerade das immer am lebenden Patienten herumdoktern. Kann man froh sein, dass der Patient noch lebt. Aber ja, also ich kenne das Problem und auch die Geschichte wie Arbeiten am Fließband kommt mir sehr vertraut vor. Aus meiner früheren Arbeitstätigkeit und das Problem höre ich auch immer wieder. Das haben sehr viele Softwareentwickler, weil häufig auch einfach Prioritäten seltsam gesetzt werden. Man wird von einem Problem auf das nächste geworfen, ohne wirklich zu gucken, dass ein Problem wirklich gelöst wird, sondern es geht eigentlich nur darum, gerade eine Kuh vom Eis zu bringen und im nächsten Moment knackt das Eis an einer anderen Stelle und dann wirst du dorthin geworfen, um die nächste Kuh vom Eis zu schieben.

Alex: [00:02:35.43] Irgendwie wollte ich mir das nicht mehr ansehen. Sagen wir mal so, denn das muss sich halt mal ändern, sonst brauche ich einen anderen Job. Aber eigentlich liebe ich die Softwareentwicklung und wollte nichts unversucht lassen, weiter tätig bleiben zu können. Und ich denke, ich habe die Kurve gekriegt, indem ich auf Qualität deutlich mehr geachtet habe und indem ich Software versuche zu schreiben, die den Kunden zufriedenstellt, die eine höhere innere und äußere Qualität hat. So nicht nur die die äußere Merkmale sind wichtig, aber auch die innere Qualität der Software. Code zu schreiben, die man auch später verstehen kann. Das leicht zu warten ist, die Erweitert werden kann und so weiter. Du weißt, was ich meine.

Matthias: [00:03:15.42] Was würdest du dann als äußere Qualität sehen?

Alex: [00:03:19.14] Performance und solche Geschichten.

Matthias: [00:03:22.77] Okay, also etwas, was der Kunde eher sieht.

Alex: [00:03:25.50] Ja UX, Wie die Ganze Sache aussieht, dass es schön aussieht. Das ist bedienbar ist. Dies ist alles wichtig, keine Frage. Aber auch, wie der Code geschrieben ist, dass man es später verstehen kann, dass man warten kann. Es war für mich halt der Erkenntnis.

Matthias: [00:03:40.63] Und wenn wir über innere Qualität sprechen, sprechen wir über Sachen wie, wie verständlich ist der Code geschrieben, hab ich Variablennamen, die aus einem Buchstaben oder aus einem ganzen Wort bestehen. Das ist dann eher das, was du da siehst,

Alex: [00:03:55.26] Das auch, innere Qualität beinhaltet aber, in meine, in meinen Augen noch deutlich mehr als nur das.

Matthias: [00:04:02.22] Werden wir im Verlauf der Zeit noch wahrscheinlich öfters drauf eingehen,

Alex: [00:04:07.17] Ja mit Sicherheit.

Matthias: [00:04:09.48] Okay.

Alex: [00:04:09.75] Und ich habe viele Bücher gelesen über unterschiedliche Themen, die in Bezug auf Software Craftsmanship und Agile Softwareentwicklung solche Geschichten erzählt haben. Ich war auf etliche Konferenzen, hab auch ab und an irgendwelche Vorträge gehalten, mit Kolleginnen innerhalb und außerhalb der Firma ausgetauscht. Eine der wichtige Quellen für mich waren die SoCraTes Konferenzen.

Matthias: [00:04:31.62] Auf der SoCraTes war ich auch schon. Allerdings nur auf dem SoCraTes Tag. Noch nicht auf einer Konferenz.

Alex: [00:04:37.53] Kannst du nachholen. Und da hab ich auch herausgenommen, dass Qualität vor Quantität geht. Es geht nicht darum so viel Code runter zu rotzen, wie man kann, sondern so viel Code zu coden wie man kann, mit eine gute Qualität. Man muss immer abwägen wieviel man in Qualität investieren soll. Muss man da goldene Hähne machen? Oder reicht auch Silber oder Bronze sozusagen? Und vor allem, dass die Automatisierung von Aufgaben eine verdammt wichtige Sache ist.

Matthias: [00:05:06.51] Vor allem von so Geschichten wie Test, die will man nicht manuell machen.

Alex: [00:05:12.21] Zumindest nicht alle.

Matthias: [00:05:14.79] Ja, genau.

Alex: [00:05:16.68] Ich hatte mal einen mittelgroßes Projekt, die auf mehrere Jahre ausgelegt war und am Anfang, am Anfang war es ziemlich klassisch aufgesetzt. Es war die Ablösung, einer bestehenden Anwendung und weißt nicht, ob du das Begriff kennst, aber es sollte am Anfang eine Eins zu eins Ablösung sein. Das hasse ich wie die Pest

Alex: [00:05:36.81] Weiß nicht warum.

Matthias: [00:05:37.20] Soll heißen, das neue Produkt sollte alle Features beinhalten, die das alte Produkt bereits hatte.

Alex: [00:05:45.15] du sollst irgendetwas neu programmieren, aber es soll das gleiche können wie vorher. So die kurze Fassung

Matthias: [00:05:50.85] und ab Tag 1

Alex: [00:05:52.41] Natürlich sofort.

Matthias: [00:05:54.36] Genau.

Alex: [00:05:57.38] Und wir haben uns vorgenommen, in einem Team, wo ich damals war, die Sache etwas anders anzugehen, haben wir uns ausgetauscht und haben entschieden, andere Wege zu gehen, andere Entwicklungsmethoden zu verwenden. Auch mit Kolleginnen, die am Anfang etwas skeptisch waren, haben wir versucht, agile Methoden, Software Craftsmanship Techniken, XP und DevOps mal mit reinzubringen. Das ist aber natürlich nicht so leicht. Der Weg ist volle Herausforderung. Eine der Schwierigkeiten ist Wie kann man das machen in eine Umgebung, die noch anders arbeitet, als wo du hin willst? Wie begegnest du Menschen, die dir sagen Das haben wir schon immer so gemacht?

Matthias: [00:06:39.38] Letztendlich hilft nur Überzeugung, glaube ich.

Alex: [00:06:42.98] Ich finde, Überzeugung alleine reicht manchmal nicht. Ich finde es sehr hilfreich, auch es zeigen, wenn man was machen kann.

Matthias: [00:06:49.13] Das meinte ich tatsächlich mit mit überzeugen. Also indem man, indem man einfach wirklich zeigt, dass es vor allem, weil das ist ja häufig die die Sorge, die alle haben, fängst auf einmal an Qualität in ein Produkt zu bringen und du wirst langsamer, weil immer die die These im Raum steht, wenn du Tests schreibst oder anderweitig schaust, deine Qualität hoch zu bringen, dass du immer mehr Aufwand reinstecken musst. Was in meinen Augen Humbug ist. Aber das muss man den Leuten halt zeigen.

Alex: [00:07:23.57] Zum Beispiel einer der Sachen, die wir ausprobiert haben, war Testautomatisierung, also Tests zu schreiben, die automatisch bei jedem Checkin ausgeführt wurden, damit wir Sicherheitsnetz und so weiter haben. Wir hatten das Problem, dass wir ein bisschen in Verzug gekommen sind und dann kommt die Kurzsichtigkeit von manchen Menschen zur Geltung und diese schnell, schnell, wir mussten schnell fertig. Lass die Tests weg. Hauptsache es geht. Rotz irgendwas raus. Egal. Hauptsache es funktioniert. Und dagegen zu kämpfen kostet viel Energie, viel Energie, macht müde. Du fühlst dich wie Don Quixote, die gegen Mühlen kämpft. Aber nichtsdestotrotz lohnt sich das zu tun. Was ist deiner Meinung nach, warum es sich lohnt?

Matthias: [00:08:05.20] Naja, weil mich interessiert letztendlich bei einem Projekt nicht der kurzfristige Erfolg, sondern der mittel bis langfristige. Und das ist das Problem, finde ich, das bei sowas immer übersehen wird, ist, dass ich ja, wenn ich vor allem wenn ich vorher noch nie mich damit beschäftigt habe, wie ich automatisierte Tests und sowas im Projekt reinbringen kann, dann werde ich erst mal langsam sein. Das ist vollkommen korrekt, das ist vollkommen normal und es ist auch nichts schlimmes. Nur ist es halt so, dass in dem Verlauf von dem Projekt, da gibt’s auch zig Grafiken und Berichte darüber, wenn man danach sucht, dass im Laufe des Projekts sich dieser Effekt umkehren wird, weil wenn man erstmal in dieses in ein Testing-Framework sich eingearbeitet hat, wenn es zu seinem Arbeitsablauf einfach dazugehört Tests zu schreiben, dann wird man deutlich schneller werden dadurch und auf der anderen Seite die, die auf Tests verzichten, die werden im Laufe eines Projekts immer langsamer werden, weil sie unbe… also nicht unbewusst, aber sie werden durch Änderungen an einer Stelle unvorhergesehene Effekte an einer anderen Stelle bekommen. Unweigerlich, das wird früher oder später passieren, Niemand ist so perfekt, dass das nicht passieren wird und die fallen unter Umständen erst gar nicht auf. Das heißt, es vergehen zwei Wochen, dann kommt irgendein Qualitätstester oder sowas, der das Ganze manuell testet und stellt fest da funktioniert an Stelle XY etwas nicht mehr, so und dann ist das Problem, dass der Zeitpunkt, wo der Fehler in den Code gebracht worden ist und der Zeitpunkt, wo der Fehler gefunden worden ist durch manuelles Testen, so weit auseinander liegen, dass schon gar keine Verbindung mehr von der Änderung zu dem Problem hergestellt wird und dann ist die Fehlersuche länger. Das Lösen des Problems, also, kann auf ganz anderen Stellen im System wieder ein Problem auslösen, das ich nicht sofort feststelle, wenn ich keine automatisierten Tests dafür habe. Und deswegen meine Meinung ist ja ganz klar Tests schreiben am Anfang wird ein bisschen mehr Zeit kosten, aber im Laufe eines Projekts wird es sich mehr als rentiert.

Alex: [00:10:14.15] Wie du sagst, genau das hat sich bei uns gezeigt und zwar gegen den Willen von einige der Team-Mitglieder haben wir gesagt: „nein, das machen wir jetzt trotzdem. Wir schreiben Tests. Wir automatisieren diese Test. Wir schreiben Test für alles Mögliche“. Wir haben nicht ausschließlich TDD gemacht, aber wichtig war uns, dass wir Tests haben. Nach einige Monate haben wir überrascht festgestellt, dass die Anzahl an von Kunden gemeldeten Fehler immer weniger werden. Wurden mit der Zeit immer weniger. Und sagen wir mal so Die Kunden, die noch die alte Anwendung benutzt haben, hatten immer wieder die gleichen Probleme. Natürlich. Aber auch kamen immer wieder neue Probleme, sodass die Anzahl an Meldungen in der alten Anwendung immer nach oben ging. Und im Gegensatz dessen beide neue Anwendung gingen die Fehlermeldungen immer nach unten, es gab immer weniger Fehler zu melden. Und dies war, was mich dazu gebracht zu zu zu erkennen, nun zu sehen und auch die anderen Kolleginnen, dass es tatsächlich etwas bringt. Eine der Sachen, die aber ein Problem darstellt, ist der Panik-Modus.

Matthias: [00:11:22.98] Absolut Ja.

Alex: [00:11:24.33] Wir haben das alles sagen wir mal gemacht und ausprobiert und es hat funktioniert. Und zu einem bestimmten Punkt kam irgendjemand mit rote Fähnchen. Panik, Panik, Panik und zu dem Zeitpunkt haben wir auf einmal alles vergessen, was wir gemacht hatten bis jetzt. Und es ging wieder mal nur darum, schnell irgendwas zu korrigieren, irgend ein Problem zu beheben. Alles, was wir neu gelernt haben, wurde ganz schnell über Bord geschmissen.

Matthias: [00:11:53.28] Ich kenne dieses Problem, ja. Es ist auch, also das ist unglaublich schwierig dem zu widerstehen, glaube ich. Vor allem, wenn man noch Vorgesetzte über einem hat, die entsprechenden Druck ausüben, dann kann es unglaublich schwer sein, diese Disziplin aufrechtzuerhalten. Sehe ich haargenau so.

Alex: [00:12:11.61] Genau in diese Kerbe schlägt die heutige Folge meiner Meinung nach, weil das, was auf jeden Fall hilft, um diese neue Techniken, neue Methoden zu verinnerlichen und sich nicht aus der Ruhe bringen zu lassen, weil man diese Methoden beherrscht, ist das üben.

Matthias: [00:12:29.76] Absolut ja und vor allem es quasi so in seinen Arbeitsmodus zu integrieren, dass es sich schon fremd anfühlt, wenn man es nicht macht.

Alex: [00:12:41.07] Die Geschichte hat sich ein bisschen gezogen und ich würde aber jetzt mal gerne über drei Methoden mal reden, die wir uns heute vorgenommen haben, nämlich Code Kata, Coding Dojo und Coderetreat.

Matthias: [00:12:55.08] Perfekt.

Alex: [00:12:55.83] Es sind drei Methoden, um alles Mögliche zu üben. Man kann alleine, im Team, auch in größeren Gruppen. Dafür gibt es die unterschiedliche Methoden und ich würde sagen, wir fangen an mit der Code Kata. Kannst du mal uns erzählen, was eigentlich eine Kata ist?

Matthias: [00:13:10.26] Eine Kata, ja.

Matthias: [00:13:12.30] Also es ist ganz interessant, wo das herkommt. Weil, man man denkt zuerst mal gar nicht, weil es mit programmieren erst mal gar nicht zu viel zu tun hat, aber es kommt tatsächlich aus dem Sport, nämlich aus dem Karate, wo das im Prinzip benutzt wird, um Bewegungsabläufe, die zu einer bestimmten Übung gehören, so zu verinnerlichen, dass sie wirklich im ja, in die ins Muskel Gedächtnis übergehen und dass man sie einfach aus dem Effeff kann und eine Kata in der Programmierung ist eigentlich etwas ganz Ähnliches. Man nimmt sich ein Problem, ein relativ überschaubares kleines Problem, das vollkommen losgelöst ist vom beruflichen Alltag meistens. Also es sind eher so Geschichten, wie wenn zum Beispiel eine Zahl durch etwas Bestimmtes teilbar ist, dann mache dies, wenn durch etwas anders teilbar ist, dann mache das und das kann man dann mit unterschiedlichen, wie soll man sagen, Bedingungen dann noch erfüllen. Also löse das Problem zum Beispiel ohne eine if zu verwenden oder kannst das Problem lösen, ohne Strings zu verwenden, da muss alles mit Objekten lösen. Also da gibt’s dann verschiedene Abstufungen, die auf den Schwierigkeitsgrad von so einer Kata dann beliebig erhöhen oder niedriger machen lassen. Und ja,

Matthias: [00:14:33.39] Genau,

Alex: [00:14:34.35] Meinst du Man könnte sagen, eine Code Kata ist nichts anderes als eine kleine Aufgabe, die wir wiederholt ausüben und uns dazu helfen soll, unser Handwerk als Softwareentwickler besser zu beherrschen?

Matthias: [00:14:45.96] Das wäre eine sehr schöne Zusammenfassung.

Alex: [00:14:50.73] Das freut mich

Matthias: [00:14:51.24] viel Kürzer wie meine, auf jeden Fall.

Alex: [00:14:55.35] Wie ich bereits erwähnt hatte, ist Üben recht wichtig. Wir müssen die Sachen öfters machen, öfters wiederholen, damit sie auch ins Blut übergehen können und wir uns keine Gedanken machen müssen, wie bestimmte Methoden oder bestimmte Praktiken funktionieren.

Matthias: [00:15:08.55] Genau.

Matthias: [00:15:09.30] Im Muskelgedächtnis. Unseres größten Muskels.

Alex: [00:15:12.81] Genau. (Das Gehirn) sehr, sehr gut gesagt, Matthias, sehr gut. Es hilft uns aber auch, ähnliche Probleme zu erkennen. Wenn wir öfters mal ein Problem auseinandergenommen haben, können wir Ähnlichkeit mit andere Problemen sehen und auch gewisse Ideen haben, wie man ein Problem lösen kann. Also, wie läuft bei dir eine Kata? Was machst du da? Wie lange es dauert? Was machst du denn so? Machst du überhaupt Katas?

Matthias: [00:15:36.44] Also mittlerweile nicht mehr so viele, wie früher. Also gerade in den Anfangszeiten, wie ich mich mit TDD, also Test Driven Development und ähnlichem auseinandergesetzt habe, habe ich relativ viel Katas gemacht, weil ich einfach diese losgelöste Umgebung sehr genossen habe. Von von der Arbeit. Also wir haben nämlich bei uns im Team auch ganz am Anfang versucht, in ein großes Legacy Projekt Tests reinzubringen. Und wir sind gescheitert und gescheitert und wieder gescheitert, haben Zeit verbrannt und hatten nur noch mehr Druck bekommen. Deswegen wollte ich dieses ganze Tests schreiben und so weiter und so fort. Wie geht man damit um? Wie macht man das? Das wollte ich außerhalb der Arbeit mir aneignen. Und da bieten sich Katas wunderbar an. Man kann sich halt eben ein kleines Problem nehmen. Nimmt sich eine halbe Stunde Zeit und schaut einfach mal, probiert aus und es gibt da tatsächlich auch ein paar Plattformen. Die können wir dann nachher auch mal verlinken, wo man im Prinzip sogar die Tests schon vorgegeben bekommt und du bist dann quasi, deine Aufgabe ist es, diese Tests grün zu machen. Und das ist auch schon mal sehr interessant für jemanden, der noch keine Tests geschrieben hat zu sehen. Wie sehen denn solche Tests überhaupt aus? Und was muss ich machen, um so einen Test hinzubekommen? Das fand ich dann zu dem Zeitpunkt sehr interessant. Mittlerweile arbeite ich mehr an einem Pet Projekt, tatsächlich also weniger mit Katas, sondern ich habe ein kleines Projekt für mich selbst, an dem ich versuche, mir solche Sachen dann anzueignen.

Matthias: [00:17:10.54] Genau.

Alex: [00:17:11.86] Bei mir ist es ähnlich wie bei dir. Ich hab früher sehr oft Katas gemacht, mit der Zeit wird es weniger. Das heißt aber nicht, dass ich aufhöre zu üben, sondern ich übe an anderen Stellen, nicht nur über die Katas. Das hat mir aber auch viel gebracht. Für mich lief eine Kata so an. Es dauerte etwa 30 40 Minuten. Man muss sich so, nicht allzu viel Zeit dafür nehmen. Einfach eine halbe Stunde z.B. ist okay. Dann versuchst du die Programmieraufgabe zu lösen, man muss nicht fertig werden. Es geht darum, dass man versucht, auf unterschiedlichen Wege eine Aufgabe zu lösen, um das Gehirn zu trainieren, diese Art von Aufgaben zu lösen. Es ist schön, wenn man ungestört arbeiten kann und das lässt sich in einem Zeitraum von einer halben Stunde noch relativ einfach bewerkstelligen. Für mich ist es wichtig, die Sache muss regelmäßig sein. Also einmal im Jahr eine Kata zu lösen, ist jetzt nicht all zu fordern, sagen wir mal so

Matthias: [00:18:07.09] und auch nicht förderlich, also ich meine, weil man vergisst alles, was man bei der einen Kata gelernt hat, ja, in kürzester Zeit auch wieder. Also man sollte schon zumindest ein paar Wiederholungen haben.

Alex: [00:18:18.13] Ja, also eine gewisse Regelmäßigkeit ist für mich wichtig. Wie oft kann man nicht pauschal sagen. Ich denke, da muss jeder entscheiden, was er oder sie leisten kann. Da muss jeder entscheiden selber, wie oft. Ein paar Mal die Woche ist Okay. Ich habe es damals tatsächlich zwei, drei, viermal die Woche, in der Früh, bevor ich angefangen habe zu arbeiten, mal 30 Minuten genommen und eine Kata gelöst. Natürlich, wenn ich eine neue Kata genommen habe, war das erste Mal nicht fertig, aber irgendwann ein Mal im Laufe der Zeit bei jedem Versuch kommt man immer weiter und hat andere Ideen, neue Wege. Wichtig ist erst einen Weg zu versuchen, eine Lösung zu finden und dann kannst du auch versuchen, andere Variationen zu finden, wie man das Problem anders lösen kann und wie gesagt, es ist völlig in Ordnung, wenn es nicht auf Anhieb klappt. Was hat mir das gebracht? Ich habe verdammt viel TDD geübt. Ich könnte am Ende die Shortcuts in meine Entwicklungsumgebung auswendig. Ja, ich könnte unterschiedliche Lösungswege für ein Problem ausprobieren und perfektionieren. Und ich könnte auch gezielt üben, mir Schwerpunkte setzen z.B. Ich möchte mit dieser Kata jetzt dieses oder jenes Pattern ausprobieren. Und Wie kann ich dieses Pattern verwenden, um dieses Problem zu lösen oder diese Art von Probleme zu lösen? Und da haben mir Katas sehr geholfen eigentlich.

Matthias: [00:19:36.79] Wo ist sie heute noch sehr gerne einsetze ist, wenn ich mir zum Beispiel eine neue Programmiersprache ansehe. Also weil da will ich nicht direkt in ein echtes Projekt rein oder so, sondern wenn ich mir z.b. aktuelles Beispiel mir Kotlin anschaue, was im Prinzip kompiliert letztlich zu Java aber die Syntax ist gut anders und da ist dann so, dass ich dann tatsächlich am Anfang erst einmal Katas mache, einfach um in die Syntax rein zu kommen, wie kann man dort vielleicht Dinge anders machen als in den anderen Sprachen? und ganz wichtig wie kann ich Tests schreiben? Also ich will, weil ich will wirklich nicht mehr mit einer Sprache sprechen, mit einer Sprache programmieren, die mir Steine in den Weg legt, wenn es um testen geht. Und es ist mir persönlich sehr wichtig und deswegen, da finde ich Katas ein ideales Mittel, um da einen Einstieg zu haben in der Sprache. So Funfact. Wir haben ja vorhin schon gesagt, man kann unterschiedliche Katas mit unterschiedlichen Lösungen und Lösungsansätzen und Patterns und so weiter lösen und ich schätze, von der FizzBuzz Kata hat schon mal jeder was gehört. Falls nicht einfach mal googlen, ist eine relativ einfache Karte, also sehr Einsteigerfreundlich, leicht zu lösen, kein großes Problem, aber es gibt da eine Implementierung von dieser Kata, die nennt sich FizzBuzz-Enterprise-Edition und es ist tatsächlich die FizzBuzz-Kata gelöst mit Enterprise Pattern. Da können wir dann einen Link posten, kann man sich mal anschauen, also das kann von ganz einfach so eine Lösung sein bis zu hochkompliziert.

Alex: [00:21:16.75] Ich würde jetzt dann weitermachen und unsere nächste Kandidat, ja der Coding Dojo. Welche Erfahrungen hast du damit gemacht? Oder kannst du uns erzählen, was das so ist?

Matthias: [00:21:26.50] Ja, also letztendlich. Ich erzähl mal mein Verständnis davon. Ich habe es ja nicht erfunden. Aber für mein Verständnis ist es so ein Coding Dojo, eine Gruppe von Menschen findet sich zusammen, die Katas zusammen lösen wollen, in einer Gruppe. Teilen wir da die Meinung. Also.

Alex: [00:21:43.90] Jaaa.

Matthias: [00:21:44.44] Bis dahin?. Ok, alles klar.

Alex: [00:21:46.90] Soweit so gut.

Matthias: [00:21:48.13] Meine persönliche Erfahrung, muss ich gestehen, ist aus meiner Arbeit in meinem alten Job, wo wir versucht haben, eben auch diese ganzen Praktiken zu etablieren und wir hatten so unsere Problemchen. Das Problem ist halt, also ich glaube, du hast es vorhin in deiner Geschichte auch erwähnt, es gibt halt die Skeptiker und Leute, die das als Zeitverschwendung sehen und wir haben da tatsächlich, obwohl wir ein relativ kleines Team von nur acht Entwicklern oder so waren, mit relativ viel Widerstand aus dem Entwicklerteam auch schon arbeiten müssen und es also bei uns hat nicht gut funktioniert, muss ich gestehen. Und ja, an so einem offiziellen Coding Dojo habe ich tatsächlich noch nicht teilgenommen. Also es gibt ja hier organisiert, in manchen Städten gibt’s ja Boutros, aber da hab ich noch nicht teilgenommen. Nur selbst organisiert quasi.

Alex: [00:22:41.93] Ja, da sind die Widerstände weniger, aber da geht nur jeder, die das machen will. Von daher es ist ein sehr angenehme Umfeld.

Matthias: [00:22:50.61] Ja, das kann ich mir vorstellen.

Alex: [00:22:52.19] Ich kenne das von der Softwerkskammer Nürnberg, die machen das ab und an und da war ich.

Matthias: [00:22:56.70] Bei denen war ich tatsächlich schon mal!

Alex: [00:22:59.84] Siehst du, dann warst du vielleicht bei einem Dojo.

Matthias: [00:23:01.43] Ja Stimmt.

Alex: [00:23:02.69] Siehst du, hattest du vergessen. Nur mal kurz zur Begrifflichkeit. Das Begriff Dojo kommt, genauso wie die Kata aus den unter anderem japanischen Kampfsportarten wie Karate, Aikido, Judo und so weiter und ein Dojo ist der Ort, an dem man sich zum Trainieren zusammentrifft, im übertragenen Sinne auch die Gemeinschaft sich dort trifft und sinnbildlich findet also ein Coding Dojo statt, wenn sich eine Gruppe Softwareentwickler trifft, um gemeinsam eine Übungsaufgabe. Und ich verweise eine Kata zusammen zu lösen, findest du das gut zusammengefasst?

Matthias: [00:23:36.96] Ja, wieder mal besser als meins, ist einfach so.

Alex: [00:23:41.21] Besser nicht, anders vielleicht, aber besser nicht

Matthias: [00:23:43.55] Anders, ne sehr schön.

Alex: [00:23:45.92] Ein Dojo ist für mich ein sicheren Ort, in dem man zusammenarbeiten kann, ohne sich Gedanken über die Arbeit zu machen, wo man Sachen ausprobieren kann, wo kein Konkurrenzdenken da ist. Wir arbeiten alle zusammen, um besser zu werden.

Matthias: [00:23:59.66] Ich wollte grad sagen kein Wettbewerb, richtig? weil das war nämlich eines der Probleme, das wir hatten, das war auch einer der Fehler, die wir gemacht haben. Weil ich hab das mit einem Kollegen zusammen organisiert in dem Team damals und wir haben leider vorher die Katte gesagt, die wir machen wollen. Und dann gab’s Leute, die sich halt im Prinzip schon vorher die Lösung gezogen haben, sozusagen. Wir waren in diesem Meetingraum von uns. Wir haben das auf irgendwie zwei, drei Stunden erst mal angesetzt gehabt. Das machen zu wollen. Nach fünf Minuten kommen halt die ersten. Ja, wir sind fertig. Wir sind fertig. Super. Das war halt überhaupt nicht Ziel der Übung. Aber okay.

Alex: [00:24:42.89] Aber schön, dass ihr dabei war.

Alex: [00:24:46.61] Ja. Und das war dann leider sehr frustrierend damals.

Alex: [00:24:49.79] Kann ich nachvollziehen, kann ich nachvollziehen. Wie läuft ein Coding Dojo ab? Nach deine Meinung. Wie sollte es… Wie läuft der perfekte Coding Dojo Matthias?

Matthias: [00:24:59.15] Das perfekte Coding Dojo… Ja also aus heutiger Sicht würde ich sagen, man findet sich eben in einer gruppe von mehreren Leuten zusammen, also so 10 Leute vielleicht, bildet Pairs und macht dann eine Übung zusammen. Da kann man dann auch unterschiedliche Modis haben. Also man kann z.B. sagen, hier der eine schreibt einen Test und die andere macht den Test grün und dann wenn der Test grün ist, wird getauscht. Das heißt, dann schreibt das andere Teammitglied den nächsten Test und man gibt wieder ab an den anderen Entwickler, an die andere Entwicklerinnen und dann wird dieser Test wieder grün gemacht. Nach einer gewissen Zeit, also keine Ahnung, vielleicht eine halbe Stunde oder so, können sich die Gruppen dann ihren Code gegenseitig vorstellen und man kann darüber diskutieren, z.B. warum Dinge gelöst worden sind, wie sie gelöst wurden. Und da finde ich, kommt ein ganz wertvoller Austausch dann zustande.

Alex: [00:26:03.80] Klingt gut. Für mich, wäre zu erwähnen, noch dazu, dass die Dauer des Coding Dojos etwa sich zwischen halbe Stunde – 45 Minuten bis zu zwei Stunden erstrecken sollte, aber auch nicht mehr. Also man muss nicht zwei / drei Stunden einen Dojo arbeiten, sondern 45 Minuten sind auch völlig okay. Wichtig ist auch für mich die Regelmäßigkeit, wie wir es für die Katas erwähnt haben. Und wie gesagt, am Anfang des Dojos pflege ich zu entscheiden mit den Kolleginnen, was wir heute machen, falls wir es nicht bereits besprochen hatten. Und wie gesagt, dann gibt es die Arbeitsteil und am Ende eine kurze, würde ich es jetzt nicht Retrospektive nennen, aber ein kurzes Zusammenkommen und mal darüber reden was hat heute gut geklappt? Was war schlecht? Was hat mir das gebracht? Was haben wir gelernt? Und so weiter, und so fort. Bezüglich die Arbeitsweise für die Arbeit in den entsprechenden Kata und mit dem entsprechenden Problem. Da gibt es natürlich unterschiedliche Methoden, ich kenne jetzt die einfachen, wären zum Beispiel die Randori Kata oder die Ping-Pong Kata. Wie gesagt, da gibt’s unzählige Möglichkeiten.

Matthias: [00:27:10.04] Ping-Pong ist ja das, glaube ich, was ich beschrieben habe.

Alex: [00:27:12.16] Ja, da müssen wir z.B. Termini wie Driver und Navigator, erst mal ins Spiel bringen. Bei der Randori Kata z.B. da gibt es ein Driver, gibt es ein Navigator und die andere hören erst einmal zu. Der Treiber schreibt den Code, der Navigator oder der Copilot sagt, was geschrieben werden soll, also welchem Weg wir verfolgen zur Problemlösung und dann gibt es eine Timebox. Jede 2 Minuten, jede 3 Minuten, jede 5 Minuten wird gewechselt. Und zwar der Driver geht raus aus der Tastatur. Der Navigator nimmt die Tastatur und eine andere, die in der Gruppe war, von den Leuten, die bis jetzt nichts sagen durften, kommt als Navigator rein. So alle paar Minuten wechselt das und jeder hat die Möglichkeit am besten mehrmals Driver und oder Navigator zu spielen.

Matthias: [00:27:59.03] Ok. Aber dann bedeutet das eigentlich auch, was ich jetzt vorhin gesagt habe, dass man im Pair arbeitet. Oder, was ich mir so vorstelle ist gar nicht mal so richtig, sondern du bist eigentlich eine große Gruppe, also mehr einen Mob und rotierst da dann komplett durch,

Matthias: [00:28:14.81] Oder?

Alex: [00:28:14.81] Ja, du hast ein Pair. Das sind der Treiber und der Navigator. Sie haben aber zwei bestimmten Rollen. Der eine ist für die Tastatur und für das Tippen zuständig und der andere ist für die richtungsweisend zuständig.

Matthias: [00:28:25.58] Das Dojo an sich ist ein Mob, wo durch diese Rollen durchrotiert wird.

Alex: [00:28:32.18] Wenn du das so nennen möchtest ja, Mob Programming hat viel mehr Implikationen. Das sind nicht nur die Entwickler da, sondern z.B. auch fachliche Ansprechpartner, auch andere Stakeholder können dabei sein. Das ist bei einem Dojo nicht so normal. Im Dojo trifft sich nur eine Entwicklungsgruppe und versucht, wie gesagt, der eine Problem zu lösen. Und da gibt es diese Randori ist ein Beispiel, es gibt die Paris Methode, es gibt Ping-Pong. Bei Ping-Pong, wie du vorher auch erwähnt hast, es funktioniert so, Driver und Navigators sind da und der Driver hat die Aufgabe, der schreibt einen Test, die noch rot ist, der noch nicht funktioniert, dann geht er raus und der nächste Driver hat die Aufgabe den Test grün zu machen und einen neuen Test zu schreiben. Dann wird wieder gewechselt, also anstatt ein Timer zu nutzen für das Wechsel wird über den „ich habe einen roten Test“. Wenn ich einen roten Test habe, dann wird gewechselt, aber es ist der gleiche dreh. Treiber geht raus. Navigator wird zu Driver und einer von der Gruppe wird den neuen Navigator und das wiederholt sich bis man die Zeit durch hat. Warum machen wir sowas? Was denkst du?

Matthias: [00:29:37.39] Also bei sowas wie einen Dojo geht es für mich in erster Linie darum, mit anderen Leuten zusammenzuarbeiten und nicht immer nur sich selbst zu sehen und sein eigenen Code und wie man selbst entwickelt, sondern in so einem Dojo lernt man auch wunderbar mit Programmierstilen andere Entwickler umzugehen. Man kann unglaublich viel lernen, vor allem, wenn in diesen Dojos erfahrenere Entwickler als man selbst zum Beispiel mit dabei sind. Wenn unerfahrene Entwickler dabei sind, kann man natürlich genau die andere Rolle einnehmen und Wissen vermitteln. Also ist es für mich ein unglaublich wertvolles Format, das ich gerne öfters erfolgreich erlebt hätte. Tatsächlich. Also ich ich habe leider eine nicht so gute Erfahrungen selbst damit gemacht in meinem, in meinem damaligen Team und sollte mich vielleicht einfach mal wieder mein Dojo kümmern, weil allein nachzudenken macht Spaß.

Alex: [00:30:36.85] Für mich

Alex: [00:30:37.21] eine der wichtigen Gründen sowas zu machen ist, dass es Spaß macht. Zumindest mir. Mir macht es Spaß. Du bist weg von den Alltag. Du hast keinen Druck irgendwas fertig zu machen. Du bist nur da, um mit anderen Menschen zu programmieren, zu codieren. Fehler gibt es nicht. Es gibt nur Wege, die nicht dorthin führten, wo du dachtest, aber mein Gott, da hast du was gelernt, Ja? Und du musst nicht fertig werden. Du lernst eine ganze Menge von anderen Leuten und zwar nicht nur besser zu programmieren, was natürlich eine der Hauptkomponenten ist. Einfach das voneinander lernen. Diese Junior / Senior, die du erwähnt hast, aber auch, wichtig, wie kommuniziere ich meine Gedanken besser? Wenn du zum Beispiel in die Senior Rolle bist, wie kann ich mein Kollege oder mein Pair beibringen oder erklären was ich will? So dass er es auch versteht. Ja. Wichtig auch zuhören, ausreden lassen. Man übt Kritik geben, aber auch Kritik nehmen. Also auch für die Kommunikation innerhalb des Teams oder die Gruppe ist es eine gute Sache, finde ich.

Matthias: [00:31:36.67] Was ich auch immer interessant finde bei sowas ist, wo sich dann so eine Lösung hin entwickelt. Weil wenn so ganz viele Leute an der gleichen Codebasis in so kurzen Abständen durchrotieren, dann nimmt teilweise die Lösung, die der Erste im Kopf hatte und versucht hat in die Richtung zu treiben, die kann ganz schnell eine Wendung nehmen, wenn ein anderer Kopf da zwischendrin dann mal halt mal einen Test in eine ganz andere Richtung schreibt und der nächste bei der Implementierung: „Ach Ja, müssen wir ein bisschen refakturieren“ und schon ist der Gedanke, wo das Ganze vielleicht losgegangen ist, hat sich geändert in eine komplett andere Richtung.

Matthias: [00:32:13.45] Also.

Alex: [00:32:14.62] Ja, aber das ist das Interessante daran. Das, was du dir am Anfang vorstellst, muss nicht das sein, was am Ende rauskommt. Es ist also auch ein sehr interessanter Gedanke und eine sehr interessante Erfahrung in meinen Augen. So, ich denke, wir haben jetzt genug über ein Dojo mal gesprochen.

Matthias: [00:32:34.06] Das glaube ich auch, ja.

Alex: [00:32:35.68] Wir könnten uns die dritte und letzte Variante mal vornehmen. Das sind die Coderetreats. Coderetreats sind eine ganz andere große, sozusagen. Für mich sind Coderetreats die Masterübung sozusagen.

Matthias: [00:32:49.51] Die erfordern auch wirklich ganz schön viel, ja. Da macht man etwas mit, sag ich mal das erste Mal macht.

Alex: [00:32:58.30] Erzähl du was über dein erstes? Wie war das? Was ist das? Wie funktioniert das?

Matthias: [00:33:02.80] Ja, der Coderetreat, ein super Erlebnis. Man kommt an einen Ort, wo ganz viele Gleichgesinnte auftauchen. Lauter Entwickler und Entwicklerinnen, die sich einen ganzen Tag eigentlich die Aufgabe setzen, Code zu produzieren, aber ihn auch wieder wegzuwerfen und zwar sehr häufig. Das ist für viele sehr sehr ungewohnt. Also es ist schon so… So ein Coderetreat ist immer in Sessions unterteilt, die immer so fünfundvierzig Minuten ungefähr lang sind und in diesen fünfundvierzig Minuten entsteht Code, der klassischerweise das Game of Life Problem lösen soll und nach diesen fünfundvierzig Minuten, egal wie weit man gekommen ist, was da war wird weggeworfen und in den nächsten 45 Minuten wird neu angefangen. Noch weitere wichtige Charakteristika sind: Es wird in zweier Pairs gearbeitet und diese Pairs rotieren ebenso. Das heißt, wenn ich in der ersten Session mit Alex zusammen gearbeitet habe, dann werde ich in der zweiten Session nicht mit Alex zusammenarbeiten, sondern mit irgendeinem der anderen Teilnehmer. Und es gibt unglaublich tiefe Einblicke in die Arbeitsweise anderer Leute. In andere Programmiersprachen kann man wunderbar Einblicke bekommen, weil auf so einer Veranstaltung sind natürlich auch nicht nur z.B. Java Entwickler, sondern da kommen dann auch mal ein Cobol Entwickler oder eine JavaScript Entwicklerinnen oder ich habe tatsächlich auch schon mit einem Manager zusammen programmiert. Also da kommen die interessantesten Konstellationen zusammen.

Alex: [00:34:43.19] Was war deine Erfahrung? Hat es dir was gebracht? Bringt dir was irgendwie in so ein Coderetreat teilzunehmen?

Matthias: [00:34:48.26] Absolut. Also ich würde es jederzeit wieder machen. Also mein erster war tatsächlich an einer Web Week. Die ist allerdings schon ein paar Jährchen her. Es war ein relativ kleiner Coderetreat, also nicht zu vergleichen mit dem Global Day, aber das war schon sehr interessant. Da waren wir eine Gruppe von ich würde schätzen so 10 Leuten, die das ein Abend lang gemacht haben. Also ich glaube wir haben um 17 Uhr angefangen und haben bis 20 Uhr oder so gemacht. Damals war ich sehr sehr frisch in dem ganzen Gebiet TDD und sowas und deswegen konnte ich da unglaublich viel rausziehen. Habe z.B. mit jemandem zusammen Ruby entwickelt. Ich hab wohl noch nie Ruby gesehen gehabt, war begeistert, was Ruby da alles so an die Hand gibt. Davon abgesehen, ich hab danach lange Zeit keine Ruby mehr gemacht, aber das spielt ja eigentlich auch keine Rolle. Genau, und der letzte auf dem ich war, das war 2019 hier in Nürnberg, war eine super Erfahrung. Also da hab ich wirklich einen wunderbaren Tag gehabt und ich schätze vielen Leuten auch, wie soll man es sagen, helfen können, selbst auch einiges gelernt und ja, ich würde es jederzeit wieder machen.

Alex: [00:36:09.73] Interessant, interessant. Auf jeden Fall für mich ist ein Coderetreat ist üblicherweise eine Tagesveranstaltung, die oft Samstags stattfindet, weil dann die meisten Leute Zeit haben außerhalb Arbeit. Oft fällt eben private Zeit dafür. Im Gegensatz zu den Katas oder den Dojos, die sich leichter in der Arbeit einbetten lassen. Aber gut ich habe mindestens kein Problem damit, private Zeit dafür aufzubringen, weil ich denke, dass all das mir hilft, besser zu werden in das, was ich mache, in dem Beruf, die ich ausübe und das ist eine Aufgabe, die mich betrifft, nicht nur mein Arbeitgeber. Ich finde es super, wenn mein Arbeitgeber mir Möglichkeiten zur Weiterbildung gibt. Aber auch wenn es nicht so wäre, finde ich, es liegt an jeder, das sich weiterbilden wollen.

Matthias: [00:36:53.68] Sehe ich ganz ähnlich. Also ich bin auch sehr viel auf solche Veranstaltungen in meiner Freizeit, weil dort halt auch irgendwie dann die gleichgesinnten Leute sind. Also wo du dich dann auch wunderbar an der Abendveranstaltung am Grill mit einem Bier unterhalten kannst und also es ist eine Community, ich liebe es, also es super und ich freue mich auch schon wieder drauf, wenn es wieder möglich ist, das Ganze vor Ort irgendwann mal machen zu können.

Alex: [00:37:22.96] Ja, ich auch, ich auch. Aber das Wort Coderetreat besteht auf zwei Worte eigentlich, auf Code und auf Retreat. Code wegen des Code schreiben und das Retreat ist aber wichtig, das ist ein Rückzugsort zu haben, wo man außerhalb des Jobs, das mal tatsächlich machen kann. Das ist tatsächlich wichtig. Das gibt etwa seit 2009, soweit ich mich erinnere, von Corey Haines und andere Softwareentwickler vorbereitet. Und mittlerweile gibt es jedes Jahr ein sogenannte Global Day of Coderetreat, in dem man innerhalb eines Tages überall auf der Welt Coderetreats gehalten werden. Das zieht sich über sechsunddreißig oder vierzig Stunden, weil überall auf der Welt ist neun Uhr in der Früh anders.

Matthias: [00:38:06.85] Wann anders.

Alex: [00:38:09.94] Aber ich habe bei so einen Global Day of Coderetreat, hab mich mit Leute auf Indien schon mal über eine Session hinweg gesprochen, oder mit Leute aus England oder USA. Total interessant. Wie du gesagt hast, es ist üblich bei Pair-Programming oder TDD bzw. bei Pair-Programming und TDD zu machen. Die Four Rules of Simple Design und ganz ganz böses Ding, am Ende der Session Code löschen. Ich bin immer erstaunt, welche… Leute, die das erste Mal in den Coderetreat sind, wenn ich das Coderetreat gerade moderiere oder irgendwas oder facilitiere, am Ende der Session sage: „Und jetzt Leute, jetzt alle bitte den Code löschen“. Die Gesichter musst du dir Ansehen.

Matthias: [00:38:49.61] Ja, es ist auch nicht leicht, weil ich meine, es ist zwar quasi per Definition so, dass das Problem in der Zeit nicht gelöst werden soll, aber irgendwie schreit es im Inneren eines Entwicklers oder eine Entwicklerin immer danach, ein Problem zu lösen.

Alex: [00:39:09.23] Die Softwareentwicklerin-Seele, na?

Alex: [00:39:11.44] Und nicht die Teillösung, die ich jetzt hart in der letzten Dreiviertelstunde mir erarbeitet haben, wegzuwerfen. Aber das ist genau das Interessante eigentlich an dem Format. Weil selbst wenn man versucht, in der Session danach denselben Ansatz zu verfolgen wie in einer Session davor, wird man es ein bisschen anders machen. Allein schon durch den Fakt, dass die Pairs wechseln, kriegt man einen anderen Input von der zweiten Person, weil der wird sich naturgemäß unterscheiden von dem Input dem einem die erste Person, mit der man zusammengearbeitet hat, gegeben hat. Und ja,

Matthias: [00:39:49.07] das ist super.

Alex: [00:39:50.35] Wichtig für mich, hast du auch erwähnt, ist: die Programmiersprachen und Tools, die man verwendet sind frei wählbar. Also das einzige was wichtig ist, ist, dass du ein Test-Framework hast für die Programmiersprache, die du verwendest, weil du Test schreiben muss. Aber ansonsten ist die Sprache an sich völlig egal. Auch die Tools, die du verwendest. Man muss sich am Anfang der Session halt mal auf irgendetwas einigen mit dem Pair, die man gerade hat und es kann passieren, dass am gleichen Tag du mit zwei oder drei unterschiedliche Programmiersprachen oder Programmierumgebungen konfrontiert wirst. Fürs Lernen an sich eine tolle Sache. Und eins was ich sehr oft höre ist, wie ihr macht am Tag fünf oder sechs Sessions und jedes Mal das gleiche Problem. Doch machen wir und zwar, weil üblicherweise man setzt in jede Session einen bestimmten Schwerpunkt. Zum Beispiel bei der erste Session geht es darum, sich ein bisschen vertrauter oder mal reinzukommen in den Tagen geht es nur um TDD üben. Aber dann kann man in jeder Session unterschiedliche sogenannte Constraints verwenden. Constraints, sozusagen Daumenzangen. Die sind halt Begrenzungen, die wir auf die Session setzen, so z.B. du musst jetzt das Problem lösen, aber es muss eine funktionale Lösung sein. Also funktionale Programmierung, keine objektorientierte oder du darfst keine while-Schleife verwenden oder, es gibt ein Konglomerat an Regeln, der heißt Objekts Calistenics, die gibts auch für die funktionale Programmierung: Funktional Calistenics. Es gibt sehr viele, sehr unterschiedliche, sehr lustige Constraints, die man verwenden kann. Falls irgendjemand es noch nie probiert hat. Es gibt ein Constraints, der heißt das Pokemon Constraint.

Matthias: [00:41:33.76] Das kam mir auch gerade in den Kopf, Pika Pika.

Alex: [00:41:37.15] Für das Thema Kommunikation oder die Mute Session, wo du zwar programmieren kannst, du darfst aber nicht reden. Du musst irgendwie … Der Pair, also Driver und Navigator müssen miteinander kommunizieren, aber ohne zu reden. Also es gibt irgendwie Möglichkeiten die Aufgabe schwieriger zu machen, sodass nie langweilig wird. Ich habe Coderetreats als Teilnehmer beigewohnt und auch etliche als als Facilitator moderiert und mir ist nie langweilig geworden und ich habe immer irgendetwas dabei gelernt, auch beim facilitieren. Also das ist die Meisterübung überhaupt. Also das totale Wahnsinn macht Spaß ohne Ende.

Matthias: [00:42:14.83] Ich finde es auch super und also ich muss was sagen, ich habe da so viele wirklich hochinteressante Personen kennengelernt. Macht richtig Spaß. Also ich kanns auch nur jedem empfehlen mal an einem Coderetreat teilzunehmen und es einfach mal mitzumachen, weil es das wirklich was ganz besonderes.

Alex: [00:42:33.01] Das letzte was ich dazu sagen möchte, ist: Es gibt unterschiedliche Arten von Coderetreats, also ich kenne zwei. Der normale Coderetreat ist, das wie wir es bis jetzt erzählt haben. Man verwendet die Aufgabe, üblicherweise Game of Life und löst diese Aufgabe mehrfach, aber es gibt eine andere Art von Coderetreats, die ich auch wo ich auch mal war. Die heißen Legacy Coderetreats. Das ist auch eine total interessante Art der Veranstaltung. Funktionieren tut es genauso, aber es geht nicht darum, Conway’s Game of Life zu machen, sondern man verwendet einfach andere Constraints und andere Aufgaben, die man lösen muss. Und das Ziel das Ganze ist eigentlich den Umgang mit Legacy Code zu üben, um besser zu beherrschen. Wie kann ich besser Legacy Code testen? Wie kann ich mich besser mit Legacy Code umgehen? Welche Möglichkeiten habe ich überhaupt Tests reinzubringen in einem Code, die überhaupt keine Tests hat? und solche Sachen ist es auch total interessant. Weiß nicht, ob du manchmal dabei warst.

Matthias: [00:43:35.47] Nein, war noch nicht.

Alex: [00:43:36.25] Aber die sind auch total cool.

Matthias: [00:43:38.11] Es klingt unglaublich interessant und ich hab wahrscheinlich meinen eigenen kleinen Legacy Coderetreat gemacht, als ich tatsächlich mal in eine legacy Anwendung Tests einziehen musste. Deswegen aber ja, es klingt unglaublich spannend, würde, hätte ich mega Bock mal drauf. Also wenn es da mal Termin gibt, da bin ich dabei.

Alex: [00:43:58.00] Das machen wir schon. Okay. Dann hast du sonst noch irgendetwas, was du hinzufügen möchtest.

Matthias: [00:44:05.37] Nee. Also ich glaube, wir haben jetzt ausführlich über die drei Methoden gesprochen. Glaube da ist wirklich für jeden was dabei und kann nur nochmal sagen, also wer noch auf kein Coderetreat war, sollte das nachholen.

Alex: [00:44:20.41] Wie gesagt, ich würde nun so zusammenfassen Es sind drei von den Methoden, die mir am besten gefallen haben, mir am besten geholfen haben mich qualitativ in meine Entwicklungsfähigkeiten zu verbessern, weil du die Möglichkeit hast entweder alleine mit dem Katas, mit deinem Team in ein Coding Dojo oder mit viele andere Menschen in einen Coderetreat Erfahrungen auszutauschen, sehen wie andere andere Sachen machen, wie man programmieren kann, wie man Probleme lösen kann und das in regelmäßigen Abständen zu machen, hat mir zumindest total viel geholfen.

Matthias: [00:44:56.48] Ja, mir auch

Alex: [00:44:57.94] Vielen Dank fürs Zuhören. Wir wären damit für heute mit der Folge am Ende. Hat uns gefreut, euch das alles mitteilen zu dürfen. Ich hoffe, ihr hattet Spaß dabei.

Matthias: [00:45:08.50] In der nächsten Folge wird es bei uns um Commits und Commit Messages gehen und bis dahin wünschen wir euch eine gute Zeit. Und wenn es euch gefallen hat, würden wir uns über ein Abo freuen.

Alex: [00:45:20.83] Genau. Falls euch gefallen hat, falls ihr keine Folge verpassen möchtet, dann einfach abonniert den Podcast und wir sehen uns in drei Wochen. Vielen Dank!

Matthias: [00:45:30.88] Ciao.

Off: [00:45:32.95] Die Macht der Craft arbeitet für dich.