Der nachfolgende Text wurden mit KI erstellt und kann Fehler enthalten. Fehler gefunden? Bei GitHub editieren

Folge 225 - Code Aufräumen - Kent Beck’s “Tidy First?” mit Marco Emrich 1/2

Herzlich Willkommen zu einer weiteren Episode von Software-Architektur im Stream.

Heute geht es um das Buch Tidy First von dem guten Ken Beck.

Bevor wir da loslegen, ein paar Hinweise.

Nächste Woche am 31.07. ist das Java Forum Stuttgart.

Ich bin am Stand von Socreatory, dem Unternehmen, für das ich auch Trainings ab und zu mache.

Wir haben dort eine Aktion.

Das heißt, ihr könnt dort eure Meinung abgeben zu der Frage, was ist die wichtigste Skill in der IT und daraus machen wir eine Episode für das Software-Architektur im Stream.

Das ist der eine Hinweis, den ich loswerden möchte.

Der andere Hinweis ist, wir haben heute ganz viel Code.

Also Architekten wie mir läuft da so ein Schauder über den Rücken.

Das bedeutet, es wird vielleicht ein bisschen schwierig, das im Podcast zu verfolgen.

Wir haben aber die Folien auf jeden Fall verlinkt auf der Webseite.

Das heißt, ihr könnt euch die Sachen runtergucken und anschauen.

Eingeladen habe ich Marco.

Marco, willst du zwei Worte über dich sagen?

Sehr gerne.

Ich bin der Marco Emrich.

Ich bin IT-Consultant bei der Codecentric.

Insgesamt mache ich eigentlich alles, was so anfällt.

Bin eher breit aufgestellt, habe aber einen Schwerpunkt in Softwarequalität.

Also alles, was Richtung Testing, TDD, Softwarecraft, Code-Design geht.

Das sind so Dinge, mit denen ich mich gern beschäftige.

Ja, habe auch einen Lehrauftrag an der FH in Salzburg.

Mache dort Software-Quality-Assurance.

Bin in der Community relativ stark involviert.

Also Softwerkskammer bin ich aktiv und viel auf Meetups unterwegs mit dem Thema.

Das sind so Dinge, die mir einfach Spaß machen.

Genau.

Und vor genau einer Woche haben wir uns auf dem We Are Developers World Congress in Berlin getroffen und ich sprach Marco an über eben jenes Buch, was ich eh anschauen wollte.

Und zwar deswegen, weil du an dem Buch mit übersetzt hast und auch dazu eine Präsentation hast.

Was halt super ist, weil im Buch sind keine Code-Beispiele, aber wir wollen heute gerade über Code reden.

Und ich glaube, der Auslöser für mich, mich mit dem Buch zu beschäftigen, ist, dass Ken Beck einer von den großen Namen ist.

Das ist einer der Erfinder von Extreme Programming.

Er hat bei Facebook gearbeitet.

Er hat das Buch Smalltalk Patterns damals geschrieben.

Er ist einer der Unterzeichner des IG Manifest.

Er ist, wie wir festgestellt haben, auch ein Mitautor von diesem wunderschönen Buch hier, dem Refactoring-Buch.

Und du hattest noch gesagt, er ist wieder Entdecker von TDD, also Test Directory Development.

TDD gibt es tatsächlich schon deutlich länger.

Also wenn man zurückgeht, stellt man fest, also selbst die NASA hat damals schon TDD gemacht.

Natürlich mit ganz anderen Technologien.

Es gab noch kein Share-Unit.

Aber er hat dieses Prinzip aufgegriffen und hat es eben auf moderne Programmiersprachen übertragen.

Also er bezeichnet sich selber auch als Wiederentdecker von TDD.

Genau.

Und wenn so jemand irgendwie ein Buch schreibt, ist das erstmal grundsätzlich etwas, was vielleicht so potentiell spannend ist.

Und das war der Grund, weswegen ich den D-Punkt Verlag darum gebeten habe, mir mal ein Exemplar zuzuschicken.

Ich bin ja dort auch Autor.

Die haben mir das also kostenlos zur Verfügung gestellt.

Und genau, D-Punkt gehört zu Heise Group und auf heise.de wird ja auch der Stream promotet.

Von daher wäre das sozusagen der Transparenzhinweis.

Ich habe mir aufgeschrieben, am Ende sagt das Buch eigentlich eher etwas aus über unsere Branche.

Der Inhalt ist vielleicht gar nicht so spannend, aber da greifen wir dem vielleicht ein bisschen vor.

Und das andere, was noch irgendwie spannend ist, ist, das Buch hat halt 120 Seiten.

Das ist halt relativ dünn.

Man kann es wirklich sehr gut am Nachmittag lesen.

Das ist, denke ich, auch einer der großen Vorteile und vielleicht auch eine der Ideen zu sagen, man versucht halt irgendwie handhabbare Häppchen an Informationen hinzubekommen.

Das ist ja auch das erste von drei Büchern, was er schreiben wird in diesem Themenbereich.

Genau.

Ich finde das grundsätzlich auch gut.

Das führt halt zu solchen Sachen.

Hier ist das zum Beispiel gerade, dass hier eine bedruckte Seite ist und dann ist die nächste Seite leer.

Das ist tatsächlich teilweise ein bisschen dünn beschrieben.

Aber ich finde das vielleicht gar nicht so schlecht im Vergleich dazu, dass man nicht diese massiv dicken Bücher wie Refactoring hat.

Es gibt eine Beziehung zu Refactoring, auf die wir nochmal eingehen wollen.

Ich hatte gedacht, wir hätten eine Episode zum Thema Refactoring.

Haben wir auch.

Die heißt nur komisch.

Das ist nämlich eine Episode, wo es wohl im Titel Patterns steht, mit dem Michael Hunger.

Verdenke ich auch nochmal.

Aber da geht es ja auch zumindest abstrakt um das Thema Refactoring.

Darauf kommen wir aber irgendwie auch nochmal zu sprechen, glaube ich.

Und ich glaube, soweit sind wir jetzt mit der Einleitung durch, oder?

Habe ich da noch etwas vergessen?

Wir machen zwei Episoden.

Das heißt, das Buch zerfällt ein bisschen in zwei Teile.

Der eine Teil ist das, was wir heute diskutieren, wo insbesondere Marco uns durch die verschiedenen Code-Beispiele durchführen wird.

Dann werden wir nächste Woche eine Episode machen zum Thema Theorie.

Da geht es um die Frage, wann räume ich denn eigentlich Code auf und was sind die ökonomischen Rahmenbedingungen.

Und da werden wir so ein bisschen die Rollen wechseln.

Das heißt, da werde ich eher was tun.

Da gibt es dann auch keine Präsentation.

Und hier geht es jetzt eben um die ganzen Code-Beispiele.

Du hast mich noch gefragt, ob ich noch etwas zur Entstehung der Code-Beispiele sagen möchte.

Das ist so einer der Probleme, die das Buch so ein bisschen hat, dass viele von diesen Tidyings erklärt werden ohne Code-Beispiele oder nur mit sehr generischen Code-Beispielen.

Und ich habe es ja auch für einen Vortrag gebraucht, dass ich halt einfach mal zeigen kann, wie funktioniert das denn.

Und wollte mir natürlich auch möglichst viel Zeit sparen, Arbeit sparen und habe einfach mal probiert, was macht denn so ein Chat GPT daraus, wenn ich den mit den Daten aus dem Buch füttere.

Und ich habe dann wirklich Kapitel für Kapitel sozusagen den Chat GPT gepackt und habe mir einfach mal Code-Beispiele generieren lassen.

Habe einen kleinen Prompt vorher geschrieben, in dem musste ich auch ein bisschen arbeiten, bis er gepasst hat.

Keines der Code-Beispiele, die rauskamen, konnte ich eins zu eins verwenden.

Ich musste alle ein bisschen nacharbeiten, aber es hat schon auf jeden Fall auch Zeit gespart, überhaupt mal die Idee zu kriegen, was für eine Domäne wählst du, wo passt das Code-Beispiel jetzt gut hin, um genau diese Art von Tidying eben auch zu zeigen.

Also insofern war es schon ganz interessant, dass das funktioniert hat.

Genau, dann würde ich sagen, Marco.

Legen wir los.

Marco, magst du deinen Bildschirm teilen?

Dann teile ich den Bildschirm, okay.

Sekunde.

Das haben wir natürlich vorher ausprobiert, deswegen sind wir uns sicher, dass es funktioniert.

Es funktioniert tatsächlich hervorragend.

Sehr gut.

Das Kernthema, um was es ja im Groben und Ganzen geht, ist natürlich nach wie vor Refacturing.

Ist in der deutschen Ausgabe auch als Untertitel.

Also Mini-Refacturings für besseres Software-Design haben wir als Untertitel für das deutsche Buch gewählt.

Und wenn man sich einmal die Original-Definition hier anschaut von Martin Fohler, dann stellt man fest, er hat eine Definition für Refacturing als Verb und für das Nomen.

Und der wichtige Teil, ich lese mal ganz kurz vor, also Umstrukturierung von Software durch Anwendung einer Reihe von Refacturings, ohne das beobachtete Verhalten der Software zu ändern.

Und gerade dieser letzte Teil ist eigentlich super essentiell, zu sagen, wir wollen an der Software was ändern, aber wir wollen das Verhalten auf jeden Fall beibehalten.

Damit eben beispielsweise keine neuen Bugs entstehen können, etc.

Das ist so einer der Kernelemente der Definition.

Jetzt spulen wir mal irgendwie 20 Jahre vor und schauen mal, was in der Industrie daraus geworden ist, wie Leute heutzutage Refacturing verwenden.

Und dann stellt man halt fest, ich meine, viele Leute haben diese Erfahrung auch einfach gemacht oder wahrscheinlich kennen das viele der Zuhörer auch im eigenen Projekt.

Naja, das Entwicklerteam sagt irgendwie, okay, der Code ist halt völlig kaputt, wir müssen uns mal für die nächsten drei Monate irgendwie eingraben und alles refacturen, damit wir hinterher überhaupt wieder in der Lage sind, neue Features zu bauen.

Und das ist halt ein Problem.

Und da hat Ken Beckoff was dazu geschrieben, also auch ein Zitat aus dem Buch.

Refacturing hat ernsthaften Schaden genommen, als die Leute begannen, damit lange Pausen bei der Feature-Entwicklung zu erklären.

Dabei verschwand sogar der Teil mit dem Verhalten beibehalten.

So das Refacturing das Display ein Problem aus dem Dritt bringen kann, also sprich, man macht Refacturings, verändert aber das Verhalten, führt möglicherweise sogar Bugs ein.

Keine neuen Features, möglicher Schaden und nichts, was sich am Ende vorzeigen kann.

Danke, ich verzichte.

Das ist so ein bisschen die Manager-Sicht natürlich auf das Ganze.

Die Entwickler geraten sich ein.

Was passiert denn?

Ich habe keine Möglichkeit zu sehen, was da eigentlich an Mehrwert entsteht.

Ich würde das gerne noch mal kurz unterstreichen, weil ich bin mir nicht sicher, ob das da draußen so klar ist.

Die Idee von Refacturing sind feingranulare Dinge, die man irgendwie ändert.

Also Refacturings sind sowas wie, hier steht zum Beispiel Extract Class, Encapsulate Field oder irgendwie solche Geschichten.

Da gibt es einen großen Überblick in dem Buch.

Das sind Dinge, die ich innerhalb von Minuten allerhöchsten Zeit auf die Reihe bekomme und die als konstanter Prozess im Hintergrund laufen, um das Design der Anwendung zu verbessern.

Das, was ihr jetzt kennt und der Martin kennt, sagt, ist, der Begriff ist pervertiert worden hin zu, wir setzen uns jetzt mal 14 Tage hin und machen irgendwas mit der Anwendung, von dem wir glauben, dass das Ding anschließend für irgendeine Definition von besser besser ist.

Und das ist schwierig und deswegen ist der Begriff halt kaputt und deswegen kommt er jetzt mit Highdings um die Ecke.

Das essentielle Element der Refacturings war eigentlich von Anfang an, dass ich das in sehr begrenztem Zeitraum auch machen kann.

Der Code ist hinterher besser und ich kann dann weiterarbeiten.

Und die Idee ist ja normalerweise, dass man Refacturings vielleicht auch gleich im Anschluss macht, die gar nicht zu lange aufschiebt, sodass der Code gar nie zu sehr in einen zu schlechten Zustand kommt.

Und wenn halt irgendwie die Feature-Entwicklung für zwei Monate lahmgelegt hat, das funktioniert halt nicht.

Da entsteht ja auch wirtschaftlicher Schaden.

In so einer Situation sollte man eigentlich normalerweise gar nicht kommen müssen.

Aber das Problem, was natürlich passiert ist, der Begriff ist eigentlich verbrannt.

Also in vielen Unternehmen hat Refactoring auch einfach einen schlechten Ruf bekommen tatsächlich.

Genau, der Holger GP bei Twitch hat gerade geschrieben, der klassische Refactoring Sprint.

Und vielleicht noch ein kurzer Hinweis, damit greife ich vielleicht ein bisschen vor.

TheInnocentKitten bei Twitch hat geschrieben, räume gerade die Datenbankzugriffsschicht an der Applikation auf und mache ein Upgrade auf eine neue Major-ORM-Version.

Passt thematisch mal wieder.

Kurzer Vorblick, weil das habe ich im Chat irgendwie auch geschrieben.

Tidings bedeuten im Wesentlichen nur in Anführungsstrichen die Lesbarkeit des Codes zu verbessern.

Also das ist halt das Ziel.

Sorry, das sagst du wahrscheinlich gleich auch nochmal.

Ja, alles gut.

Grüße an Holger.

Den kenne ich.

Refactoring, das ist das eine Problem.

Der Begriff selbst ist in manchen Unternehmen so ein bisschen verbrannt.

Und das andere Problem ist natürlich, was versteht man darunter?

Wie groß darf so ein Refactoring sein?

Also es war von Anfang an gedacht, dass es eben nicht zu groß wird.

Und Ken Beck unterstreicht das halt mit seinem neuen Buch nochmal, prägt den anderen Begriff und sagt, Aufräumereien sind eine Untermenge der Refactorings.

Also Aufräumereien ist der deutsche Begriff.

Also so ein Tidying ist nichts anderes als ein Refactoring.

Aber man hat das nochmal stärker runtergebrochen und hat gesagt, das sind halt wirklich Refactorings, die auch nicht sozusagen ausarten können, sondern die wirklich klein bleiben.

Wo ich wirklich mal zehn Minuten investieren kann und der Code ist hinterher besser und ich kann einfach an der Stelle weitermachen.

Ich mache damit nichts kaputt.

Das ist so der essentielle Teil.

Und er bringt das natürlich ein bisschen sehr blumig aus und sagt, das sind niedliche, kleine, knuddelige, kleine Refactorings, die niemand wirklich hassen kann.

Und das ist eben die Idee hintendran, dass man einfach auch nochmal sich dieses Bewusstsein schärft, dass ein Refactoring eben nicht Dinge blockieren soll, sondern dass man den Code kontinuierlich mit ganz kleinen Schritten verbessern kann.

Und das Subset sozusagen, das er hier herausgesucht hat, das sind genau die Refactorings, die eben weniger Risiko bergen.

Und wir hatten schon darüber diskutiert.

Du sagst jetzt, das sind vor allen Dingen Refactorings, die keine Strukturänderungen machen.

Das würde ich nicht hundertprozentig unterschreiben.

Es sind ein paar dabei, die schon auch ein bisschen in Richtung Strukturänderung gehen, aber eben nicht diese krassen Geschichten wie Methoden zwischen Klassen zu verschieben, Klassen zu extrahieren.

Das ist da alles raus, sondern es ist ein kleines Subset.

Es sind auch ein paar Aufräumereien, ein paar Tidings drin, die es im Originalrefactoringbuch nicht gegeben hat, sondern die jetzt so einfach aus der Praxis hinzugekommen sind.

Genau, getriggert hatte mich da nur dieses Upgrade auf ein ORM-Mapper auf neun.

Das ist halt sicher kein Tiding mehr.

Und ein Hinweis, den ich halt auch nochmal kurz loswerden wollte, ist von den Hamburg auf YouTube in der Zeit, als die Idee von Refactoring aufkam.

Wir reden über kurz vor der Jahrtausendwende.

Waren die Ideen noch nicht so weit mit der modernen Idee IntelliJ für Java, kann man das wirklich nebenbei machen.

Könnte man noch erläutern, dass Eclipse bereits wenige Jahre später, also kurz nach der Jahrtausendwende, bereits eingebaute Refactorings hatte, aber das tut dem sozusagen keinen Abbruch.

Tool-Unterstützung ist auf jeden Fall wertvoll.

Dann würde ich einfach schon mal in die Beispiele gehen und wir schauen uns einfach die Tidings auch mal im Detail an.

Oder hast du noch irgendwas vorher?

Nee, leg los.

Du hast 15 oder so mitgebracht.

Wir müssen mal schauen, wie weit wir kommen.

Aber einen Eindruck gewinnen wir auf jeden Fall.

Das hier ist direkt aus dem Inhaltsverzeichnis vom Buch, so eine kleine Übersicht, was es da an Tidings gibt.

Und da schauen wir einfach mal rein.

Und wenn euch die meisten davon jetzt draußen irgendwie bekannt vorkommen, das ist kein Zufall, sondern das sind natürlich Dinge, die einfach schon jahrelang in der Praxis erprobt sind.

Er hat denen oft jetzt nochmal einen neuen Namen gegeben, um halt auch ein bisschen ein Vokabular vielleicht dafür zu finden, dass man sich leichter über diese Dinge unterhalten, austauschen kann.

Aber wenig davon hat tatsächlich einen Neuheitswert.

Also das ist auch einfach Ken Beck selber bewusst.

Das ist gar nicht die Idee, um die es da an der Stelle geht.

Ja, vielleicht fangen wir mal hiermit an.

Was meinst du, Ebert?

Was könnte denn hier so vielleicht ein Problem sein an diesem Kurzstückchen hier?

Genau, soweit habe ich die ja vorher tatsächlich gesehen.

Ich muss halt gestehen, ich verstehe eigentlich nicht so genau, was passiert.

Also das sind irgendwie zwei verschrachtete Anweisungen.

Und ich habe irgendwie so ein bisschen, um ehrlich zu sein, ein schlechtes Gewissen, weil ich habe schon den Anspruch, an mich genau zu verstehen, was los ist.

Aber das ist eigentlich schon so, dass es nicht mal auf den ersten Blick, glaube ich, noch zu verstehen ist.

Ich meine, natürlich müssen wir jetzt auch so ein bisschen Softwarearchäologie hier betreiben und versuchen, die Domäne aus dem Code zu extrahieren.

Und offensichtlich geht es irgendwie darum, Discounts zu berechnen für irgendwelche Produkte, Preise, wie auch immer.

Und die sind wohl abhängig davon, ob es irgendwie ein VIP-Angebot ist, ob wir uns gerade in der Ferienzeit befinden mit diesem Angebot.

Das sind Dinge, die halt hier eingehen.

Aber ohne, dass ich die Domäne kenne, würde ich so auf den ersten Blick sagen, eines der ganz klassischen Probleme sind halt hier schon verschachtelte Ifs.

Also in dem Moment, wo ich anfange, Dinge stärker zu verschachteln, erhöhe ich die zyklomatische Komplexität.

Der Code wird schwerer lesbar.

Und wie du sagst, man will ja eigentlich den Anspruch haben, dass man es auf einen Blick eigentlich versteht, was da passiert.

So muss ich schon irgendwie mich durch die Branches durchdrängen.

Das ist ja wirklich ein einfaches Beispiel.

In der Praxis sieht es ja meistens viel komplexer und viel schwieriger noch aus.

Und trotzdem kann man in dem einfachen Beispiel schon sehen, wie leicht man jetzt hier einfach Abhilfe schaffen kann.

Und das könnte man machen mit Guard Clauses.

Also was ich hier machen kann, ich kann diese Bedingungen einfach vorziehen.

Ich kann sagen, es sind eigentlich so eine Art Ausschlussbedingungen.

Also den Discount, den kriege ich halt nur, wenn gerade Ferien sind und wenn es eben kein VIP-Produkt ist.

Und diese Bedingungen, die kann ich einfach vorher abfragen.

Und wenn ich halt in dieser problematischen Situation bin, gebe ich halt keinen Discountpunkt.

Jetzt kann ich das einfach linear runterlesen und das macht die Sache viel leichter verständlich.

Das ist so die Kernidee bei dieser Geschichte.

Ja, nochmal als Übersicht, damit man beobachten kann, wie sich das Ganze verändert.

Und Guard Clause ist ja nichts Neues.

Wie gesagt, gibt es schon lange.

Ist eine einfache Geschichte.

Kann man relativ risikolos anwenden und hat hinterher einfach lineareren, lesbaren Code mit einer geringeren zyklomatischen Komplexität.

Kennt man vielleicht auch, falls jemand die Object Calisthenics kennt, von Jeff Bay.

Sortworks irgendwann mal vor 20 Jahren mal beschrieben.

Es sind so Übungsregeln sozusagen, wie ich guten objektorientierten Code schreibe.

Und da ist eine Regel, dass man sagt, es soll immer nur One Intentation geben.

Also man sollte Code halt nicht ineinander verschachteln.

Also extra hier das If, pack die Vorschleifung aus, was auch immer.

Genau, der Thomas Einwaller bei YouTube hat gerade gefragt, dass das mir auch irgendwie so ein bisschen durch den Kopf angegangen ist.

Und zwar, er widerspricht es nicht, die Multiple Returns are bad.

Ja, das ist das Single Entry, Single Exit Prinzip, SESE.

Das gibt es auch.

Und tatsächlich sind die beiden so ein bisschen im Konflikt miteinander.

Also wie immer sind es Trade-Offs.

Meine persönliche Meinung dazu ist, dass das Single Entry, Single Exit Prinzip aus einer Zeit kommt, wo man oft sehr, sehr lange Funktionen hatte.

Also wo eine Funktion vielleicht auch zwei Bildschirmseiten lang war.

Und wenn ich dazwischendrin irgendwelche Exits habe, vielleicht auch in der Mitte von meinem Code, von meiner Business Logik, macht das natürlich das Ganze unglaublich unübersichtlich und ich verstehe vielleicht gar nicht mehr, was passiert.

Was da hilft, sind einfach andere Regeln, wie man sie auch in den Object Calisthenics findet.

Dass die Funktion natürlich insgesamt auch nicht zu lang wird.

Also wie lang ist zu lang, kann man sich auch wieder darüber streiten, gibt es verschiedene Metriken.

Aber solange die irgendwie auf den Bildschirm passt, solange die klein genug ist, dass ich sie auf einen Blick erfassen kann, ist schon mal geholfen.

Und die andere Geschichte ist, diese Guard Clauses, die stehen am Anfang der Funktion.

Das heißt, ich prüfe erst mal am Anfang, ob quasi die Vorbedingungen erfüllt sind.

Es geht eher so ein bisschen, es ist vielleicht eine schwache Form von dem, was Eifel macht, so Pre-Conditions zu formulieren. bevor die eigentliche Business-Logik überhaupt arbeiten kann.

Ja, genau.

Wobei ich halt sagen würde, die Pre-Conditions sind auch etwas anderes, weil da würde man jetzt sagen, es ist sozusagen falsch, wenn dieser Parameter übergeben wird und halt nicht im Wertbereich ist.

Aber hier ist es ja tatsächlich so, dass es eine Fallunterscheidung ist, die halt von der Logik sozusagen abhängig.

Also, in dem Fall ja, aber es gibt auch Guard-Clauses, die man stärker noch als Pre-Conditions einsetzen könnte.

Also, die müssen auch keinen Return machen, die könnten auch einen Straw machen beispielsweise, wenn du halt sagst, okay, da wird halt irgendwas nicht erfüllt und es ist sogar eine Ausnahme, die eher stärker fehlerbehaftet noch ist.

Genau, super.

Gut.

Ja, gehen wir zur nächsten.

Genau.

Was könnte hier das Problem sein?

Das ist ein bisschen viel Code, ich weiß nicht, ob man es gut lesen kann.

Lass mich mal schauen.

Das ist also ein Bank-Account, da gibt es halt eine Balance.

Dann gibt es Calculate Average Transactions, Get Balance, Print Statement, Print Statement Form.

Und ich glaube, das ist das, wo du sagen wolltest, dass das da unten rechts der einzige Code ist, der andere Sachen aufruft, nicht?

Das war, glaube ich, die Information, die fehlt.

Genau.

Also, das ist natürlich ein kleines Beispiel, um das Ganze irgendwo zu zeigen.

Und man wüsste natürlich, wenn man den Code jetzt irgendwie in der freien Wildbahn findet, gibt es vielleicht noch andere Aufrufer.

Aber hier, um das einfach mal klarzumachen, so ein bisschen die Situation oder die Story wäre jetzt, es gab vielleicht mal früher irgendwie einen Aufrufer für Print Statement Form A.

Aber das ist aus historischen Gründen irgendwann wahrscheinlich rausgeflogen.

Jetzt gibt es eben nur noch dieses Print Statement Form B.

Und das hat man aber vergessen zu entfernen.

Und das zieht natürlich Abhängigkeiten mit sich, die vielleicht auch nicht mehr gebraucht werden, wie hier diese…

Was hat B, was hat A nicht?

Ne, andersrum.

Was hat A, was hat B nicht?

Genau, A hat dieses Calculate Average Transaction und das wird dann halt gar nicht mehr gebraucht.

Und das ist so ein ganz klassischer Fall.

Einfach Dead Code, den kann man schlicht und einfach löschen.

Aber man muss es auch tun.

Es muss einem einfach bewusst sein und man muss einfach drüber gucken und den dann auch löschen.

Genau.

Und wir hatten noch beim Vorgespräch, da sind wir ja noch durchgekommen, hatten wir, glaube ich, darüber…

Hattest du nicht gesagt, dass IntelliJ das halt auch anzeigt bei Java Code?

Ich habe das gesagt, echt.

Das kann nicht sein, weil ich benutze kein IntelliJ.

Weiß ich nicht, vielleicht habe ich es auch gesagt.

Aber das Thema ist natürlich, das hier ist ja jetzt noch TypeScript Code.

Und wir waren uns nicht ganz sicher, aber es kann einfach sein, dass es bei dynamischen Sprachen auch ein bisschen schwieriger ist, das einfach zu ermitteln.

Und man entsprechend halt dann das selber finden muss oder irgendwie vielleicht ein externes Tool verwendet, um den Dead Code zu finden.

Also was ich jetzt gerade mir sozusagen spontan überlegt habe, ist, man könnte ja die Public-Methoden private machen und schauen, ob das Ding noch kompiliert.

Das ist wahrscheinlich auch eine gute Idee, ja.

Und dann kann man halt irgendwie als nächstes sagen, also feststellen, ob in der Klasse es benutzt wird.

Und wenn es in der Klasse auch nicht benutzt wird, kann man es wegwerfen.

Und das kann man, glaube ich, iterativ machen.

Genau, Mark M. sagt, wirkt so, als wenn der Code am Ende einfach überschaubarer sein soll.

Genau, das war ja das, was ich vorhin sagte.

Es ist meiner Ansicht nach eine wesentliche Leastbarkeit, worüber wir reden.

Und in diesem Fall ist es eben Leastbarkeit durch Code weg.

Genau, also eigentlich ganz banal, aber man muss es sich halt bewusst machen und auch dann auch wirklich durchführen.

Genau.

Okay, ich glaube, das Beispiel hast du, glaube ich, noch nicht gesehen.

Wir haben eine Person, die hat getFullName.

Das ist firstName plus lastName.

Dann gibt es getLocation.

Da kommt irgendwas raus mit City und Country, wird formatiert.

Und dann gibt es getDetailedInformation.

Da baut es irgendwas zusammen aus dem firstName, lastName.

Und dann baut es halt noch das mit der location zusammen.

Das heißt also, das getDetailedInfo, würde ich jetzt mal behaupten, sollte eigentlich getLocation und getFullName vielleicht aufrufen.

Unter der Bedingung, dass das halt dasselbe sein sollte.

Ah, guter Punkt.

Ist vielleicht auch ein guter Aspekt, aber darum geht es gerade nicht, genau.

Also jetzt ist es, glaube ich, klar.

Die Frage ist, ach so, genau.

Holger weist mich auch hin auf die Kommentare.

Und da steht halt einmal using StringCoreCatenation.

Also da wird Plus benutzt, um Strings zusammenzusetzen.

Dann gibt es String.Format, um die Strings zusammenzubasteln.

Und dann gibt es halt den StringBuilder, der irgendwie Strings zusammenbastelt.

Und das sind irgendwie drei unterschiedliche Möglichkeiten, dasselbe Problem zu lösen.

Und das ist suboptimal.

Also verwirrend.

Absolut.

Also das ist genau das Thema.

Und ich meine, die Kommentare geben vielleicht schon ein bisschen starken Hinweis drauf.

Die hat man natürlich ansonsten nicht.

Aber genau.

Also wenn halt dasselbe in inkonsistenter verschiedenen Arten und Weisen gemacht wird, macht es ja auch den Code später schwerer änderbar.

Weil ich vielleicht auch mal Teile der einen Funktion in der anderen verwenden möchte.

Und das macht das natürlich viel schwerer.

Und hier ist die Idee zu sagen, es nennt sich Normalize Symmetries.

Also man versucht eine Symmetrie herzustellen aus der unterschiedlichen Arbeitsweise, die hier passiert.

Und es kommt im Endeffekt auch gar nicht darauf an, für was ich mich jetzt entscheide.

Ob ich jetzt den StringBuilder nehme oder ob ich einfach nur Concatenation mache, ist eigentlich nicht der springende Punkt, sondern ich sollte es halt gleich machen in allem.

In allen drei Situationen.

Und ja, ich habe es einfach für String Concatenation entschieden.

Aber könnte auch eine der anderen sein.

Entscheidend ist eben, dass es auf die gleiche Art und Weise passiert.

Genau.

Also ich würde jetzt behaupten, mit dem Plus ist es halt am einfachsten zu verstehen.

Von daher.

Genau.

Manchmal gibt es auch Argumente wie Performance.

Keine Ahnung, man will den StringBuilder haben.

Aber warum auch immer.

Das ist erstmal sekundär.

Wichtig ist eben die Konsistenz.

Genau.

Und Holger ergänzt noch, ich dachte es geht um die überflüssigen Kommentare.

Das ist auch nicht ein guter Punkt.

Also wenn tatsächlich ein Produktionscode drinsteht. Übrigens benutzt er gerade String Concatenation.

Und dann ist da eine Zeile, wo ein Plus drinsteht.

Das ist ein bisschen komisch.

Das ist tatsächlich auch eines der Tidyings.

Aber soweit kommen wir wahrscheinlich nicht.

Das ist Tidying Nummer 14, glaube ich.

Genau.

Aber es ist absolut richtig, dass man auch guckt, dass man keine überflüssigen Kommentare hat.

Hier nochmal einfach nochmal übersichtlich.

Aber ich glaube, es ist auch schon ganz gut klar geworden, was hier passiert.

Genau.

Also mit dem Pluszeichen komme ich zumindest schneller dahin zu verstehen, was hier so gut tut.

Ja, das Pluszeichen ist wahrscheinlich auch das lesbare von diesen drei Varianten.

Ja, ich auch.

Ich auch.

Okay.

Ja, das Nächste.

Das ist vielleicht nicht ganz so offensichtlich, weil da ist mir es ein bisschen schwer gefallen, wirklich ein gutes Beispiel dafür zu finden.

Geht jetzt hier gar nicht so sehr um das, was wirklich passiert, sondern die Situation ist einfach die, ich habe ein Interface und ich habe gemerkt im Projekt, dass ein anderes Interface besser funktionieren würde.

Und wenn ich über ein Interface rede, rede ich jetzt nicht von einem Sprachmittelinterface, sondern Interface im abstrakten Sinne.

Also die Menge der Signaturen einer Klasse ist das Interface dieser Klasse.

Und das können auch mehrere Klassen sein.

Keine Ahnung.

Eine interne API könnte man auch sagen.

Also ich habe irgendwas, was mir einen Zugriff erlaubt.

Und ich habe festgestellt, dass die Calls, die Aufrufe, in der Art und Weise, wie sie aktuell passieren, super optimal sind.

Hier im Beispiel wäre das eine Datenbank, die das irgendwie in drei Schritten macht.

Ich habe Connect, Execute Query und Disconnect.

Das kann in vielen Situationen sinnvoll sein.

Ich connecte einmal.

Ich habe vielleicht ganz viele Queries und dann disconnecte ich einmal.

Aber vielleicht habe ich eine Situation, wo ich nur ganz sporadisch mal eine SQL Query absetzen muss.

Und dann mache ich die Datenbank normalerweise hinterher gleich wieder zu.

Und dann wäre es günstiger, ein Interface zu haben, was eben nicht aus diesen drei Teilen besteht, sondern hier zum Beispiel so einen einfachen Aufruf, wo ich einfach nur Execute Query mache.

Und dieses Execute Query kümmert sich darum, eben das Connect und das Disconnect eben schon mit zu erledigen.

Die eigentliche Idee hinter diesem Tidying ist jetzt nicht zu sagen, ich baue jetzt irgendwie das komplett um und ändere die Implementierung, sondern ich baue mir ein neues Interface, das meinen neuen Use Case besser erfüllt.

Aber ich nutze die Implementierung des alten Interfaces, indem ich beispielsweise sage, ich baue mir so eine Execute Query Funktion und die bezieht sich auf diese alten Execute Queries.

Das ist das Beispiel so ein bisschen abstrakt, muss man natürlich gucken, wegen der Namensgleichheit, ist das vielleicht in einer anderen Klasse untergebracht oder muss ich die Funktion vielleicht anders nennen.

Aber die Kernidee ist einfach, ich rufe die alten Funktionen auf und baue keine neue Implementierung, schreibe das nicht komplett um.

Ich stelle das nebendran, das alte Interface existiert weiter und damit mache ich nichts kaputt.

Damit bin ich sicher, dass das Refactoring funktionstüchtig bleibt.

Das würde ich schon sagen, es geht übrigens in diese Strukturänderung.

Es ist so ein bisschen Fassade einführen, nicht?

Golfpattern, Fassade, Fassade.

Wobei eine Fassade eigentlich dazu da ist, mehrere Objekte zu verstecken.

Es geht ein bisschen in die Richtung.

Könnten aber auch mehrere Objekte sein, würde auch passen.

Es ist ja nur ein Condensed Example.

Kurz noch, dass im Chat noch aufgelaufen ist, so ein paar Hitterhinweise.

Martin hatte noch geschrieben, I keep telling my coworkers, most else cases can be replaced with guard clauses.

Also nicht der Hinweis, dass die meisten else Sachen durch Guard Clauses ersetzt werden können.

Das haben wir, glaube ich, in einem Code Beispiel ganz gut gesehen.

Und in Hamburg hatte noch gesagt, noch eine Anmerkung zu First Name, Last Name.

Kulturunabhängiger ist man mit Person Name, Family Name.

Okay, genau.

Zudem gab es jetzt irgendwie nichts, oder doch?

Ach so, es gab noch diese Frage, soll man es halt in einer anderen Sprache schreiben?

Was hat der Mark M. hatte geschrieben?

Gibt es irgendwelche Vorteile, den Code einfach in einer anderen Programmiersprache zu schreiben, zum Beispiel und vor allem in Kotlin?

Ja, die Sprachen wie Kotlin haben sicher neue Features.

Aber ich glaube, das ist nicht das Thema, worüber wir jetzt gerade sprechen.

Das gehört nicht zu den Three Things.

Man geht jetzt natürlich davon aus, dass das Projekt in dieser Sprache bleibt.

Sprachumstellung ist auf jeden Fall mehr als Refactoring, würde ich behaupten.

Weil das zieht ja oft ganz viele Dinge hinter sich her.

Zumindest steht in dem Buch nicht drin, ändere mal die Programmiersprache, und das ist dann Refactoring.

Im Gegenteil, das sind ja eher diese feinen, granularen, kleineren Dinge.

Nur falls jemand drüber stolpert, ich habe einfach Grundbeispiele in verschiedenen Sprachen gemacht, um so ein bisschen Unterschiede mal zu sehen.

Das ist keine besondere Hintergründe.

Nächstes Beispiel, das ist vielleicht nicht ganz so offensichtlich hier, aber vielleicht kannst du ja mal schauen, ob dir irgendwas auffällt.

Wir haben eine Klasse AK, und die hat StartEngine.

Da guckt sie nach der Batterie nach, und wenn die Batterie nicht da ist, dann sagt sie, das ging halt nicht.

Dann gibt es einen Konstruktor, der das CheckBattery sagt, wie alt die Batterie ist.

Ich glaube, du bist schon genau darüber gestolpert.

Du hast gesagt, dieses CheckBattery, ob die Batterie da ist.

Sorry, ob die jünger als fünf Jahre ist.

Aber genau das weißt du halt zu dem Zeitpunkt nicht.

In dem Moment, wo du gelesen hast, er prüft die Batterie, ob er die Engine starten kann, was bedeutet denn jetzt dieses CheckBattery?

Das ist völlig unklar.

Dann findest du später diesen Kommentar, als Einfachheitsgründen gehen wir davon aus, wenn die Batterie älter als fünf Jahre ist, dann wollen wir sie lieber nicht mehr betreiben.

Wenn sie neuer ist, ist okay.

Und diese Information fehlt dir, um diesen Code, diesen StartEngine zu verstehen.

Jetzt kann man natürlich argumentieren, CheckBatteries ist einfach kein guter Methodenarm.

Das hätte man einfach deutlicher benennen können, was es hier eigentlich geht.

Aber eine andere einfache Möglichkeit, um den Code hier noch mal besser zu machen, ist, wir ändern einfach die Reihenfolge.

Ein Konstruktor macht sowieso Sinn, dass der irgendwie oben steht.

Und wenn ich vorher schon mal verstanden habe, was das CheckBattery macht, dann kann ich dieses StartEngine natürlich auch besser verstehen.

Holger hat es irgendwie, ich glaube, zwei Sekunden, bevor du es gesagt hast, hat der Holger es gesagt und der Alexander Herold hat auch gerade gesagt, die Reihenfolge der Methoden ist auch schräg.

Absolut.

Und ich meine, es ist sicherlich immer noch nicht optimal.

Also jetzt könnte man vielleicht eine Folgerefactoring über ein Renaming nachdenken oder vielleicht noch was anderes tun.

Vielleicht ist die Methode auch falsch platziert.

Aber alleine die Reihenfolge zu ändern, macht den Code einfach lesbarer.

Und das ist eigentlich, glaube ich, das interessante Learning an der Stelle.

Genau.

Das heißt, ich habe jetzt den Konstruktor, dann habe ich CheckBattery und dann habe ich StartEngine.

Das ist deutlich logischer, weil ich jetzt die Sachen in der Reihenfolge durchlese, in der sie typischerweise ausgeführt werden.

Das ist ja auch so eine alte Thematik.

Ich weiß gar nicht, von wem das ursprünglich kam, der gesagt hat, so ein Stück Code ist ja eine Geschichte.

Du schreibst ja den Code nicht für die Maschine.

Du schreibst den Code, um anderen Menschen zu erzählen, was da passiert.

Ich fühle mich gerade erinnert an diese Episode, ich muss ja noch mal verdenken, von der Feline über Code lesen.

Also nicht, dass man sich diesem Problem aus der anderen Seite nähern kann, dass man tatsächlich lernt, wie man Code liest, um es besser zu lesen.

Und das ist vielleicht tatsächlich eine gute Ergänzung, weil hier ist es eben so, dass wir darüber diskutieren, wie wir Code leichter lesbar machen, aber wir können eben auch besser lesen.

Beide Seiten.

Das war eine englische Folge.

Ich glaube, das war ein Martin Vorlau ursprünglich.

Man schreibt den Code eben für Menschen und nicht für Maschinen.

Da kann man sich so ein bisschen als Autor einfach verstehen.

Ja, das verarbeitet ja die ganze Zeit durch unsere Branche, glaube ich nicht.

Du schreibst es halt einmal und du liest es halt N-mal, weil du es N-mal ändern musst.

Und deswegen ist Lesbarkeit so wahnsinnig wichtig.

Einfach noch mal zur Übersicht.

Ich glaube, das ist auch ganz gut klar geworden.

Schauen wir uns das nächste Beispiel an.

Das, by the way, ist auch, ich glaube nicht, dass es das als Refactoring gibt.

Also die Reihenfolge von Methoden ändern, glaube ich jetzt nicht.

Vermutlich, weil es als Refactoring zu banal fast wäre, um das in der Form zu formulieren.

Und deswegen ist es ja auch ein gewisser Wert, diese einfachen Dinge auch mal aufzuschreiben und zu sagen, lass uns mal schauen, ob das eine Sache ist, die uns schon weiterhilft.

Ich muss gestehen, ich schluss mich ein bisschen an dem Banal, weil in gewisser Weise ist es nachvollziehbar.

Auf der anderen Seite ist es eben tatsächlich so, ich habe es ja gemerkt, als ich gerade eben den Code versucht habe zu lesen, also man stolpert da halt schon.

Und offensichtlich ist es auch etwas, wo eben die Zuschauer eben auch sehr schnell gemerkt haben, dass so etwas schief ist.

Von daher.

Schon wert, auf jeden Fall.

Ja, genau.

Gut, was haben wir jetzt?

Wir haben einen Shopping Card, der hat einen Apply Discount.

Hier gibt es ein Calculate Item Total, Add Item, Calculate Total.

IsValidDiscountCode hat er noch.

Also ein bisschen bedeutet das halt, und Apply Discount checkt halt, ob der Discount Code valid ist.

Könnte also wieder eine Lesereihenfolge sein, weil Apply Discount und IsValidDiscountCode sind eben sehr stark voneinander getrennt.

Also es ist tatsächlich sehr ähnlich.

Also auch hier geht es wieder um die Reihenfolge.

Der Grund ist ein bisschen ein anderer.

Es geht hier um die Cohesion Order, dass man halt die Sachen zusammengruppiert, die miteinander zu tun haben.

Also wie du schon gesagt hast gerade eben, also genau, das Apply Discount, und dafür muss ich das Valid Discount Code wieder irgendwie, wieder sehen, wie das zusammenhängt.

Und man will halt einfach diese Bereiche irgendwie zusammenhängend haben.

Das könnte man natürlich wieder argumentieren.

Man kann später Refactorings machen, wo diese Sachen vielleicht noch mal in getrennten Klassen sogar sind, möglicherweise.

Discount ist vielleicht ein ganz eigenes Thematik, ein ganz eigenes Stück Logik.

Aber hier geht es ja eben darum, mit möglichst wenig Veränderungen überhaupt mal schon mal ein bisschen die Lesbarkeit zu verbessern.

Und deswegen, wenn ich die einfach schon mal innerhalb dieser Klasse einfach zusammengruppiere, dann hat das schon Wert, hilft das auch wieder eben bei der Lesbarkeit.

Ich beschäftige mich irgendwie mit dem Discount.

Dann habe ich Apply Discount und IsValidDiscount zusammen.

Ich beschäftige mich irgendwie mit dem Berechnen von irgendwelchen Totals.

Dann habe ich einmal das Gesamt-Total und einmal habe ich das Pro-Item.

Auch die beiden Dinge muss ich in Kombination verstehen.

Deswegen sollte man die eben zusammenziehen.

Genau.

Also ich muss gestehen, du hast es gerade eben schon gesagt, das ist halt die Stelle, wo ich eben auch sagen würde, sowas wie ein Extract Class oder so wäre vielleicht gar nicht so dumm.

Also weil da kann man sich halt sehr schnell überlegen, dass halt unter bestimmten Bedingungen vielleicht eine Strategy ist mit unterschiedlichen Discounts.

Und das ist tatsächlich dann eben die Stelle, wo das Tidying dann am Ende ist.

Also was dadurch einfach nicht abgedeckt wird.

Der Martin hat geschrieben, statt zu fragen, ob der Code gültig ist, also der Discount-Code, könnte man auch ein Tell-Don’t-Ask-Ansatz werden und einfach Apply Discount verwenden.

Ja, ich glaube aber das bedingt dann fast schon wieder, dass du eine eigene Discount-Klasse hast, die du dann fragen kannst, kann ich dich anwenden auf die aktuelle Situation?

Und dann würde der Discount quasi dann auch das Discounten durchführen.

Tell-Don’t-Ask-Ansatz verstehe ich so, dass du quasi die Modifikation, also du fragst nicht, sondern du hast die Modifikation dann an einer anderen Stelle, die sich auch darum kümmert, diese Prüfung durchzuführen.

Okay.

Das ist ja eher so ein Command-Pattern, ist es nicht, aber eine Klasse ruft die andere auf und fragt die nicht.

Du hast keinen Return-Value, den du nutzt, sondern du sagst ja, du gibst dir einen Command im Sinne von, wende jetzt diesen Dispatch an und die entscheidet dann intern, ob sie das machen möchte oder nicht.

Martin hat gerade gestimmt, der Discount weiß selber, wann er gültig ist.

Also es stimmt, das ist tatsächlich ein Problem.

Dieser Discount-Code, der Shopping-Card weiß, ob der Discount-Code gültig ist und das ist Quatsch.

Eigentlich ist das tatsächlich Quatsch.

Also eigentlich müsste der Discount-Code das wissen und das ist auch ein Beispiel, befürchte ich ja für, habe einen magischen String, also könnte man ein Value-Object draus machen.

Da kommen wir auch noch hin.

Aber ja, also klar, ich denke, das andere Thema hier ist einfach so Feature-Envy.

Also du hast da irgendwie im Shopping-Card Dinge, für die sollte der Shopping-Card nicht zuständig sein.

Ja, es ist ein bisschen die Frage, ob das sozusagen ein Sonderfall ist, weil Cohesion Order sagt ja schon, dass man Sachen hat, die durch Cohesion getrennt sind.

Also das Problem, was du hast, ist, du kannst es halt nicht immer so leicht separieren.

Also das siehst du hier vielleicht auch schon so ein bisschen, weil der Apply-Discount beispielsweise ja auch das Total kalkulieren muss.

Und das geht noch, weil es ja schon immerhin eine getrennte Methode ist, die du dann auch auf einer anderen Klasse aufrufen könntest.

Aber manchmal hast du ja auch so Geschichten, wo du dann Instanzvariablen hast, die halt kreuz und quer verwendet werden und dann ist es gar nicht so leicht zu entzerren.

Man kann das halt ein erster Schritt sein, diese Cohesion Order schon mal zu haben.

Ja, also das ist vielleicht ein anderer Hinweis.

Also das, was ich meine, ist prinzipiell ist es komisch, weil ich ja sage, ich habe eine Cohesion Order, was also bedeutet, ich habe Teile, die zusammenhängen und die sind aber gemeinsam in einer Klasse.

Die kann ich irgendwie trennen.

Also das ist ja genau das Beispiel, was wir haben.

Wir haben mal Discount Code, das ist der eine Paragraf sozusagen oder der eine Teil.

Der andere Teil ist halt, er kümmert sich um die Items und um das Gesamte zu kalkulieren.

Und dazwischen habe ich so mental sozusagen einen Strich und ich sage, ich teile das jetzt irgendwie auf.

Und wenn das so ist, könnte man eben argumentieren, dass die Klasse eben nicht High Cohesion hat, sondern sie hat zwei Dinge mit High Cohesion und dann wird es halt nachher eine Klasse raus zu extrahieren.

Das ist aber eben genau da und das ist möglicherweise ein prinzipielles Problem, weil eben durch Cohesion Order ich ja die These vertrete, dass es unterschiedliche Teile gibt, die zusammenhängen, die ich aber irgendwie optisch sozusagen trennen will.

Man verletzt ja auch dieses Single Responsibility Prinzip, dass die Klasse eigentlich nur sich um eine Verantwortung kümmern sollte.

Aber es ist nicht immer einfach in existierendem Code, das so ohne weiteres rauszutrennen.

Deswegen kann das ein Zwischenschritt sein, dass ich es schon mal sichtbar mache, indem ich es halt kopiere.

Genau, aber das bedeutet zweierlei.

Also einmal würde ich halt sagen, wenn ich das nicht kann, bedeutet das, die Klasse hat eine hohe Cohesion, weil alles mit allem zusammenhängt.

Also das ist in gewisser Weise ein Feature.

Und wenn ich Cohesion Order habe, müsste ich eigentlich als nächstes, das ist ja genau das, was wir gerade diskutieren, jetzt darüber diskutieren, ob irgendwie dieser Discount Code nicht eine eigene Klasse werden sollte.

Und spätestens da verlasse ich dann eben diese Tidying Ebene.

Ja, genau.

Dann kaufst du dir ein größeres Risiko bei der Umstellung ein.

Ja, da bin ich mir halt irgendwie nicht so sicher.

Wir hatten ja vorhin diesen Hinweis mit den IDEs.

Also wenn ich halt in meiner IDE mit einem automatisierten Refactoring sage, ich mache das jetzt mal kurz, ist ja hoffentlich das Risiko relativ gering.

Ich glaube, in dem Fall könntest du es tatsächlich noch machen.

Aber ich kann mir gut Beispiele vorstellen, wo du es mit automatisierten Refactorings nicht mehr hinbekommst.

Genau.

Weiter?

Ja, lass uns mal.

Da war es einfach nochmal übersichtlich.

Und genau, jetzt schauen wir uns mal das Nächste an.

Was haben wir denn?

LED Total.

Achso, ich habe eine Instanz vorher.

Habt ihr wahrscheinlich Total, die hat ein Number.

Dann habe ich halt irgendwelchen Code, der nicht Total benutzt.

Da steht halt Kommentar.

Dann sage ich Total ist 0.

Und dann habe ich irgendwie noch mehr Code, der vielleicht Total benutzt.

Und dann gebe ich am Ende das Total zurück.

Und vermutlich ist halt die Idee dafür zu sorgen, dass diese ganzen Total-Geschichten irgendwo an einer Stelle zusammenhängen.

Genau, da geht es um eine ganz spezielle Thematik dabei.

Nämlich, dass halt hier die Deklaration und die Initialisierung der Variable getrennt ist.

Das ist jetzt auch ein bisschen sprachabhängig natürlich.

Aber das ist halt oft ein Problem, dass du an der Stelle, wo die Variable quasi zum ersten Mal initialisiert wird, du siehst vielleicht den tatsächlichen Typ nicht mehr.

Oder du fragst dich halt irgendwo weiter oben, was passiert denn jetzt mit der Variable.

Und je nachdem, wie groß diese Funktion natürlich ist, kann das halt schon für sehr viel Verwirrung sorgen.

Und da kann erst mal ein einfacher Schritt sein zu sagen, lass uns halt einfach Initialisierung und Deklaration zusammenziehen.

Ich meine, im Idealfall hättest du vielleicht dieses LabTotal gleich 0 auch nicht über diesem anderen Code, wenn der das gar nicht verwendet, sondern würdest es auch weiter nach unten packen.

Da muss man dann experimentieren und gucken, wie es in der jeweiligen Situation am besten passt.

Aber allein das Zusammenziehen hat schon einen gewissen Wert, weil du halt eben da auch die Cohesion wieder irgendwo stärkst in dem Sinne.

Also Dinge, die zusammengehören, hast du dann eben auch an derselben Stelle.

Das finde ich übrigens, das ist ein super Hinweis.

Also eigentlich reden wir wieder über Cohesion, nur eben Cohesion innerhalb einer Methode und nicht innerhalb von einer Klasse.

Das ist eine andere Ebene.

Ja, genau.

Ich finde es halt deswegen wichtig, weil ich mir nicht sicher bin, ob allen klar ist, dass eben Cohesion auf verschiedenen Ebenen existiert.

Also auf Ebene der Methode, auf Ebene der Klasse und eben auch auf der Ebene von Packages oder irgendwelchen Systemen.

APIs, was auch immer.

Genau, also deswegen ist es ein sehr spezieller Fall natürlich jetzt hier, aber kann halt schon helfen und dann kann man sich natürlich dann überlegen, wie man weiterfährt.

Willst du dann auch wieder ein Extract Method machen oder irgendwas, das nochmal aufteilen und gucken, wo findet man die Teile, die irgendwie zusammengehören.

Genau.

Zum Ende.

Ja, genau.

Da ist nochmal der gesamte Code.

Genau und wir sind glaube ich, ich weiß gar nicht, wie weit wir gekommen sind, waren das fünf oder sechs?

Ich erinnere mich nicht genau.

Ich habe es auch nicht mitgezählt.

Aber es sind noch ein paar da.

Ich habe noch ein oder zwei und die letzten fünf habe ich jetzt auch nicht umgesetzt.

Genau.

Weiteres entweder auf den Folien oder dann eben sozusagen im Buch auf dieser Ebene.

Für uns war es glaube ich ganz wichtig, nochmal die Perspektive zu wechseln.

Also ich habe mir hier aufgeschrieben, was bedeutet denn das nun alles?

Und es gab heute Vormittag noch ein Kommentar von einer Person namens Powerstadt.

Ich glaube zumindest, dass das sein Name ist.

Das war zumindest das, was diese Person als letztes eingegeben hat bei dem Kommentar auf der Webseite.

Das ist ja sonst anonym.

Diese Person hat geschrieben, hallo, wo ich gerade sehe, dass ihr das Buch von Ken Beck vorstellen wollt.

Meiner persönlichen Meinung nach ist das Buch wirklich sehr schlecht gemacht.

Es enthält nichts Falsches, nur vieles seit langem Bekanntes.

Ich persönlich würde da eher das Buch Code is for Humans von Zoa Jackson empfehlen.

Ich verlinke das Buch irgendwie nochmal.

Uns ist das Buch halt beiden nicht bekannt.

Aber das ist ja jetzt eine sehr provokante Aussage.

Also es sagt halt immerhin, da ist halt nichts Falsches drin, aber das sollte ja bekannt sein.

Was meinst du dazu, Marco?

Das hat ja mehrere Aspekte.

Zum einen, etwas kennen und etwas kennen kann sehr unterschiedlich sein.

Ich denke, viele von diesen Dingen sind vielleicht vielen Entwicklern auch einfach bewusst, aber man wendet sie halt vielleicht auch nicht so bewusst an.

Und die Tatsache, die einfach mal aufzuschreiben, einen Katalog zu haben, über den ich nachdenken kann, ein Vokabular zu haben, mit dem ich über diese Sachen auch reden kann, das hat für sich schon einen hohen Wert.

Das ist der eine Punkt.

Also die Sachen explizit zu machen, finde ich sehr, sehr gut.

Und die andere Sache ist, ich meine, die Kenntnisstände sind natürlich sehr, sehr unterschiedlich.

Es kommen ja immer neue Leute nach.

Also ich weiß nicht, es gibt ja so Zahlen, wie sich die Entwicklerbevölkerung, wie lang haben sich die verdoppelt?

Also sowas wie Moore’s Law quasi für Entwicklerbevölkerung.

Und die wird ja immer kürzer.

Und ich glaube, es ist wichtig, dass man auch einfach diese Dinge kennenlernt und eine Chance hat, damit einzusteigen.

Und eben nicht an diesem Problem leidet von Begriffen, die verbrannt sind oder die einfach unter Umständen einen schlechten Ruf hat.

Und das hat mehrere Aspekte, wo ich sagen würde, es bringt auf jeden Fall einen Mehrwert auch in die Community.

Ja, also ich würde gerne meine Meinung dazu auch noch kurz kundtun.

Bitte.

Ich muss gestehen, als ich das Buch halt gelesen habe, beziehungsweise ich habe es eigentlich überflogen, ist bei mir halt einmal die Frage aufgekommen, okay, das ist also diese Person, die hat halt irgendwie vor 25 Jahren dieses Buch mitgeschrieben über Refactorings und die kommt jetzt irgendwie um die Ecke und sagt, ich mache das jetzt alles nochmal neu.

Das stimmt nicht ganz, weil wir haben es ja vorhin diskutiert.

Also sowas wie Extract Class oder so ist da einfach nicht drin, sondern es geht halt eigentlich um in Anführungsstrichen weniger.

Also wenn ich Refactoring mache, kann ich halt durch Refactorings getrieben das Design schrittweise verbessern.

Hier ist der Anspruch, die Lesbarkeit des Codes schrittweise zu verbessern.

Und ich würde behaupten, das ist weniger kompliziert.

Und das heißt, wir haben es jetzt innerhalb der letzten 25 Jahre nicht geschafft, dieses Konzept, was fundamental ist, irgendwie den Leuten halt ins Gehirn zu bekommen.

Wir als Branche.

Und Kent hat es jetzt im Prinzip abgerüstet und hat gesagt, ich will Lesbarkeit erzeugen.

Und ich finde, das ist echt schwierig, weil es kann ja nicht sein.

Leute werden halt irgendwie ausgebildet, Leute sind halt irgendwie auf der Uni, Leute werden halt als ProgrammiererInnen auch irgendwie ausgebildet und es kann eigentlich nicht sein, dass wir da ein Problem haben.

Es gibt Unterschiede, das haben wir ja auch gerade gesehen.

Also diese Reihenfolge, diese Cohesion-Geschichten und so, das sind halt alles keine Refactorings.

Und was ich da auch noch problematisch finde, ist, dass wir in unserer Branche ein hohes Maß an Begriffsverbrennen betreiben.

Also Refactoring bedeutet nicht, dass man sich 14 Tage hinsetzt und sagt, ich ändere mal mein System.

Refactoring bedeutet, dass ich kleine Refactorings mache als Hintergrundprozess.

So ist das gemeint, das ist sehr eindeutig.

Das Problem haben wir an anderen Stellen auch.

Also zum Beispiel bei der Agilität.

Ich habe gerade so einen Blogpost, der ist heute rausgekommen zum Thema Agilität führt halt zu 268% mehr Fehlschlägen, geschrieben.

Und das hängt letztendlich damit zusammen, dass halt der Begriff Agilität missverstanden wird, in diesem Fall absichtlich missverstanden wird und eben verbrannt ist.

Weil halt Leute irgendwie rumziehen und sagen, ich habe keinen Bock auf diesen agilen Mist, da sind halt ganz viele Meetings und das ist nicht der Punkt.

Und deswegen finde ich, also wie soll ich sagen, ich finde das Buch im Gegensatz zu dem PowerStart nicht schlecht, weil ich glaube, dass der Ken das geschrieben hat, weil er irgendwo ein Problem gesehen hat, was halt gefixt werden muss.

Ich kann mir nicht vorstellen, warum man sonst ein Buch schreibt.

Also das ist halt irgendwie dann doch aufwendig.

Und man verdient jetzt auch nicht wahnsinnig viel Geld damit.

Und das bedeutet, dass wir halt glaube ich in der Branche ein Problem haben und das finde ich halt echt schwierig.

Und ja, das ist für mich so ein bisschen die Konsequenz an der Stelle.

Genau, ich weiß nicht, ob du dazu noch was sagen wolltest, Marco?

Nee, ich überlege gerade, aber ich bin da deiner Meinung.

Den Hamburg schreibt die jungen Leute, haben mehr Spaß, neuen Code zu schreiben.

Die Beschäftigung mit altem Code eigener oder anderer Leute ist nicht sexy und wird zum Beispiel in der Ausbildung nicht so hoch aufgehängt.

Das führt mich so ein bisschen, also erstmal würde ich behaupten, Refactoring muss man eigentlich ständig machen.

Und ich habe mich halt gefragt und also ich zumindest bin ja irgendwie prinzipiell erreichbar.

Es gibt diese Code-Retreats.

Bei Code-Retreats setzt man sich im Prinzip zu zweit von Rechner und praktiziert halt per Programming testgetriebene Entwicklung.

Also erst Testschreiben, dann Implementierung schreiben.

Refactoring, schrittweises Vorgehen.

Also das typische Beispiel ist da so ein Tic-Tac-Toe-Spiel und man fängt halt tatsächlich an mit einer leeren Idee und fängt jetzt irgendwie an und hackt irgendwelchen Code runter und macht das eben zu zweit testgetrieben, schreibt also erstmal einen Test und er lässt dann das Design treiben durch die Rechner.

Und du, Marco, hast ja auch ganz viel schon gemacht in dem Bereich und das führt irgendwie so ein bisschen zu der Frage, ob wir eine Episode dazu machen sollten, hier bei Software Architektur im Stream.

Ich bin mir da ein bisschen unsicher, weil das ist halt, also ich habe damit kein Problem.

Es ist prinzipiell ein Thema, was da halt irgendwie reingehört, aber es ist halt dann doch weiter weg von Architektur und ich habe ja auch irgendwie immer noch die Hoffnung, dass das eigentlich klar sein soll.

Aber nach diesem Buch bin ich mir da irgendwie nicht mehr so sicher und deswegen ist irgendwie die Frage, ob das halt irgendwie sinnvoll ist.

Und da sind wir, glaube ich, alle auf Feedback gespannt, ob man es dann hinbekommt.

Das ist eine andere Frage.

Holger sagt, machen.

Das ist dann schon mal eine Positivstimme.

Muss man halt mal schauen.

Also da kann ich vielleicht noch ergänzen, dass es bei einem Code Retreat ja auch vor allen Dingen um Software Design geht.

Also du hast jetzt nicht nur den reinen Code Level, sag ich mal, wo es jetzt hier nur um die Lesbarkeit geht, sondern da fließen ja noch mehr Aspekte rein.

Also vielleicht jetzt nicht Architektur im Großen, aber halt schon um Strukturelemente, wie ich die plane, wie ich die designe, wie sich das verändert über die Zeit.

Das sind halt auch Themen, die da eine Rolle spielen.

Ja, und ich finde es halt immer so krass, weil man fängt ja tatsächlich mit einem leeren Blatt Papier an oder eben mit einer leeren IDE und es entsteht tatsächlich irgendwie da mal ein Design.

Und ich glaube, wenn man das…

Ach so, genau, das ist auch der andere Punkt bei der Kritik an dem Buch.

Also um es mal brutal zu sagen, wenn man weiß, wie es geht, versteht man das Buch und kann es irgendwie nachvollziehen.

Wenn man nicht weiß, wie es geht, hat man keine Code Beispiele und es wird schwierig.

Also das, was Marco gerade präsentiert hat, ist ja ein Teil des Code Retreats.

Das ist ja ein Teil der Präsentation und durch Chat-GPT entstanden.

Das steht halt nicht im Buch.

Und ich würde sogar noch sagen, in sowas wie einem Code Retreat kann man sowas eher hinbekommen, weil da sitzt man irgendwie zu zweit.

Und wenn eine Person es sozusagen versteht, kann sie es der anderen sozusagen erklären.

Und das ist, glaube ich, viel effektiver, als ein Buch zu lesen.

Und insbesondere die, ohne Beispiel, das ist halt echt schwierig.

Und die Beispiele, also die Beispiele, die du ja jetzt gewählt hast, Marco, sind ja welche, wo so ein bisschen so eine Domäne durchschimmert.

Also wir haben Shopping-Card gesehen und ein Bankkonto.

Die Beispiele im Buch sind halt fuh.

Und das ist halt auch, finde ich, schwierig.

Und das führt irgendwie zu der Frage, wenn ich also das Buch lese, ist es etwas, was irgendeiner Audienz etwas bringt.

Also Leute, die es halt wirklich nicht kapiert haben.

Newbies in Entwicklung, bin ich nicht sicher, ob sie es halt verstehen, weil dem fehlt halt das Code Beispiel.

Leute, die es halt verstehen, so wie Marco oder ich vielleicht auch, die brauchen es vielleicht nicht, weil es ihnen, also, stimmt gar nicht, weil da sind tatsächlich ja viele neue Ideen drin.

Wir haben ja drüber diskutiert.

Also sowas wie diese Cohesion Order beispielsweise, ist halt, glaube ich, echt eine neue und interessante Idee, aber es ist irgendwie schwierig.

Was hat denn der Marco geschrieben?

Marco Wessemann schreibt, durch KI-Tuts etc., größere Industrie etc. entsteht auch mehr Code.

Menschen, die noch nicht lange dabei sind, erkennen den Wert von zum Beispiel Lesbarkeit und handwerklichen Dingen eventuell nicht sofort.

Das ist aber das, was ich meine.

Also eigentlich, wie soll ich sagen, um es umzusprechen, um es platt zu sagen, ich verstehe nicht, warum wir EntwicklerInnen haben, die nicht durch eine Ausbildung gelaufen sind, die halt ungefähr so aussehen wie in Code Retreat.

Also eigentlich sollte das so sein und ich verstehe schon, warum das so ist, weil das eben nicht Teil eines Bildungskanons ist und ja, das ist halt irgendwie ein Problem, aber das ist ja genau der Punkt.

Ich finde das halt schade.

Also ich würde es mir anders wünschen.

Wann ist der Global Day of Code Retreat?

Im November.

Ich kann es nachschauen.

Genau, wir verlinken das.

Also da ist es halt so, dass es irgendwie weltweit so Code Retreats gibt, wo man sich einfach sozusagen anmelden kann und hingehen kann.

Das sind ja auch immer kostenlose Sachen und genau.

Ich verlinke das nochmal.

Also es gibt coderetreat.org und da gibt es halt auch Code Retreats zu finden.

Also wäre halt sozusagen mein Tipp.

9.11. ist 9.11. ist Global Day of Code Retreat.

Das ist auch meistens samstags, weil da die Idee auch so ein bisschen ist, auch die, über die intrinsische Motivation zu filtern, sage ich mal.

Die Leute, die da hingehen, die wollen das auch wirklich machen und man wird da nicht vom Arbeitgeber hingeschickt und hat da einfach Interesse daran, neue Dinge zu lernen.

Wobei das vielleicht auch etwas wäre, also das selber im eigenen Unternehmen halt zu streuen.

Ich habe das auch tatsächlich mal gemacht beim Unternehmen, wo ich gearbeitet habe.

Ich glaube, das ist auch eine gute Idee.

Auf jeden Fall.

Keine Frage.

Gut, ich schaue nochmal, ob ich irgendwo was übersehen habe.

Nee, das scheinen sozusagen so weit alle Kommentare gewesen zu sein.

Dann würde ich sagen, genau.

Vielen Dank, Marco, dass du da warst und dass es so kurzfristig geklappt hat.

Vielen Dank für die Einladung.

Ja, sehr gerne.

Wir sehen uns nächste Woche wieder.

Da geht es halt auch wieder um Tidy First, aber da geht es irgendwie um die zwei Folgekapitel und in den Folgekapiteln geht es halt so ein bisschen um, sagen wir mal, Theorie.

Genau.

Dann schönes Wochenende und bis dahin.

Bis dann.

Ciao.