Aber wer weiß, ob es nicht irgendwann cleancode 2. Die Rückkehr des Cleancodes gibt oder sowas. Die Rückkehr der Cleancoder Cleancode schlägt zurück oder so. Coding Buddies Dein Podcast rund um Softwareentwicklung und aktueller Tech News. Herzlich Willkommen. Herzlich Willkommen zur neuen Folge des Coding Buddies Podcast.
Schön, dass du wieder eingeschaltet hast, deine Gastgeber, wie sollte es auch anders sein, meine Wenigkeit, Tino und natürlich auch der fantastische Fabi, den ich jetzt begrüßen mag. Fabi, Was geht ab? Was geht ab? Tino Es wäre so witzig, wenn du jetzt einfach so einen anderen Namen genannt hättest. So wie soll es auch anders sein und Kalle? Ich begrüße Robert an meiner Seite. Genau. Nein, nein, es ist natürlich
immer noch fabi. Ah Puh, was geht denn ab, erzähl mal alles gut bei dir, hast du. Bock ja, ich hab Bock, ich hab auch was, worauf ich auch Bock hab ist, dass es jetzt wieder kälter wird wird in Hinsicht auf snowboarden hab ich auch wieder Bock. Ja, also es steht ja quasi die Wintersaison vor der Tür. Manche würden, munkeln sie sie ist sogar gestartet. Ja, ist ja regionabhängig, aber vorhin ist sie noch nicht. Gestartet bist du schon mal im
Oktober Snowboard gefahren. Oktober, November so noch nicht ne, bei mir war das früheste Dezember. Dezember okay krass. Ich bin nicht mal im Dezember. Also bei mir ist immer nur Januar bis März oder so. Also ich glaub ich bin noch nie Ende des Jahres Snowboard gefahren, sondern immer nur Anfang des Jahres. Also es kann sein, dass es auch Anfang Januar war.
Also ich glaub meinen ersten Probetag, so weiß ich nicht, war der im Januar. Kann auch sein, dass der im Januar war, ich weiß es gar nicht mehr genau toll, aber so richtige Liveurlaube ja live hier vor allem vor allem nee, aber so richtige Winterurlaube hab ich auch immer nur Januar, Februar, März so in dem Zeitraum gemacht. Ist ja auch einfach ne tolle Sache. Auf jeden Fall freu ich mich da schon drauf. Ich hoffe du freust dich da auch schon drauf.
Ja, lass komm, pack alles ein. In anderthalb Stunden bist du ungefähr hier. Let's Go Leute, Wir fahren jetzt alle Snowboarden so. Alle nach. Alle. Uns nach so. Okay toll, jetzt muss ich mich mal wieder aufs Thema konzentrieren. Es soll ja eigentlich um Code gehen, jetzt hab ich nur Snowboarden im Kopf, wir wollen heute eine Podcast Reihe abschließen. Die wir über die letzten Monate immer so stückweise quasi veröffentlicht haben, und zwar die Clean Code Reihe.
Wir haben ja schon einiges dazu thematisiert und haben uns überlegt, lass uns doch mal abschließend noch mal so ein Wrap abmachen, dass wir sagen okay, wir fassen es noch mal zusammen und betrachten das ganze jetzt ganzheitlich mal aus einer kritischen Sicht und gehen auch mal auf.
Na, sag ich mal andere Meinungen ein zu dem Thema und wollen auch mal so die Frage klären, ist das Ganze denn einfach überholt mittlerweile, weil ich sag mal diese ganze cleancode Bewegung auch das Buch dazu von Ankle Bob ist ja auch schon in die Jahre gekommen, das haben wir ja während den Folgen auch n bisschen thematisiert und gesagt Na ja gut, es sind aber immer gute Basics an die man sich anlehnen kann und lass uns das
heute denn einfach noch mal. Kritischer betrachten, dass wir wirklich mal sagen, jetzt gehen wir mal damit kritisch ins Gericht mit dem. Ganzen auf jeden Fall. Was man sagen kann ist, dass angenommen Liebe Zürin lieber zürer, du hast noch ein. Wertvolles, Cooles. Thema was du noch mal im Bereich Clean Code beleuchtet haben möchtest, dann schreib uns und dann gibt es auf jeden Fall noch einen Clean Code Nachtrag. Sollte es der Fall sein.
Also wir schließen zwar die Reihe ab, aber wir begraben sie nicht komplett. Und wer weiß? Ich schon. Also ich mach da gleich einen Gips mehr dazu. Okay ich mach's dann alleine? Genau nein, aber wer aber wer weiß, ob es nicht irgendwann cleancode 2. Die Rückkehr des Cleancodes gibt oder so weißt du die Rückkehr der Cleancoder Cleancode schlägt zurück oder so klingt. Klingt ja so okay, dann darf man das so ein Jota sein auch mal. Ja, ja, ja, ja. Komisch, komisch ist mir ganz spontan.
Eingefallen gerade, ja, aber finde ich gut, wir können ja einmal kurz gucken, was haben wir denn überhaupt in unserer Clean Code Reihe jetzt besprochen. Ich habe letztens übrigens mal aus Spaß geguckt, die erste Clean Code Folge, die ist letztes Jahr im Dezember gestartet, also schon ein paar Tage her und deswegen will ich noch mal einmal kurz mit dir zusammenfassen, worüber haben wir denn überhaupt in unserer Clean Code Reihe gesprochen und?
Als erstes würde ich da sagen, Wir haben zum Beispiel über Naming gesprochen, da ging es einfach darum, dass es wichtig ist, seine Variablen, seine Funktionsnamen et cetera, diese ganzen Sachen richtig zu benahmen oder beziehungsweise gute Namensgebung zu verwenden, dass es halt einfach wichtig ist und dass man zum Beispiel auch durchaus über Funktionen nachdenken sollte, und zwar wenn. Wieviel Parameter haben Funktionen?
Wie lange ist eine Funktion, was gibt es so für Rückgabewerte, die man, was ist da sinnvoll bei Funktionen und als dritten Punkt hatten wir auch eine Folge über Kommentare gehabt, das heißt Kommentare im Code ja oder Nein ist es gut oder schlecht? Clean Code sagt ja eher okay, der Code sollte selbsterklärend sein und Kommentare sollten halt eben nicht im Code. Wenn möglich vorkommen hast du noch was, fällt dir noch was
ein? Wir hatten auch das Thema Code Formatierung gesprochen und auch dabei gemerkt. Wenn man also auch während des Aufnehmens der Folge, wieviel man denn doch über Code Formatierung sprechen kann. Es war auch eine sehr spannende Folge, muss ich sagen und da ging es ja darum, um Missverständnisse zu vermeiden, allgemeine hohe Lesbarkeit zu schaffen, auch Coding Standards
innerhalb des Teams einzuhalten. Das war auf jeden Fall da so Thema der Folge und ein sehr spannender Punkt war, als wir die Datenstrukturen versus Objekte so n bisschen thematisiert haben, dass man sich einfach mal klare Gedanken macht, wie definiere ich klare Datenstrukturen, wann wähle ich was, dass man das ganze gut durchdenken kann, die ich kann, sollte so. Man kann es durchdenken und
sollte es auch durchdenken. Genau und dann halt auch diese ganze Kapseln und Modularitätsgeschichte dahinter und das letzte war mein ich, die letzte Folge ging um unser geliebtes Thema Testing und haben da das First Prinzip vorgestellt und deswegen Liebe zuhören liebe Zuhörer, wenn du die Folgen nicht gehört hast und aber Bock drauf hast. Und vielleicht dir ein eigenes Bild machen möchtest.
Bevor wir jetzt in diesen kritischen Teil, sage ich mal übergehen, dann pausiere jetzt die Folge, hör dir die anderen ein und komm dann wieder her. Ja. Und weiter geht es. Eine Sache ist mir sogar noch eingefallen. Wir haben sogar auch eine Folge darüber gemacht über Clean Code, die war so ungefähr in der Mitte, da ging es darum zu gucken, okay, wenn ich nach clean Code arbeiten möchte, nach der Theorie, was steht einem denn vielleicht manchmal in der Praxis im Weg.
Ne, also wo werden einem da vielleicht so Steine in den Weg gelegt war fand ich auch. Nicht. Okay genau die. Auch hören dann. Aber genau das, das waren so die Themen, die wir bisher thematisiert haben. Wie gesagt, wenn auch neue Themenvorschläge da sind, auch trotzdem gerne raus, dann gibt es ein Revival oder einen Nachtrag.
Bevor wir jetzt wirklich uns mal angucken, Tino, was denn so vielleicht auch kritische Betrachtungsweisen von Clean Code sind, können wir erstmal vielleicht noch kurz zusammenfassen, was ist denn wie, wieso, wieso gibt, wieso ist clean Code denn überhaupt eine Sache, nachdem man vielleicht auch arbeiten kann oder woran man sich anlehnen könnte? Was sind denn, was ist denn der sozusagen der Wertevorteil, um das kurz zusammenzufassen? Den Clean Code bringt, um dann halt zu gucken was.
Wo haben wir denn vielleicht so ein paar kritische Punkte? Ja, also am Ende zahlen alle Richtlinien und Vorschläge darauf ein, eine hohe Codequalität zu gewährleisten, auch zum Beispiel Best Practices und Standards zu fördern, indem wir zum Beispiel, als wir über die Funktion geredet haben, da sind ja so gewisse Richtlinien drin, die nach Clean Code eine
gute Funktion ausmachen. Und das fördert natürlich, sag ich mal Best practices, dass du sagst, ey ja OK, ich weiß das und das muss ich einhalten und das wird so mein Codingstil dann am Ende gerade für Anfänger und Junior Developer ist das ja ne gute Sache auf jeden Fall zu sagen, OK, mit diesen Prinzipien kann ich auf jeden Fall meine Codequalität schon steigern und das von Anfang an, sobald ich quasi über diese.
Ja, über diese Regeln will ich es nicht nennen, aber diese Richtlinien Bescheid weiß, das ist auf jeden Fall ein großer Punkt. Ne, ich find vor allem auch ich find es auch gut, dass man eben sich von Anfang an, weil du ich find es gut zu sagen wie du meintest für Anfänger ne, weil wenn man. Gerade am Anfang ist kann man halt eben auch lernen oder versuchen, den Fokus auf bestimmte Sachen zu halten, um halt nicht zum Beispiel
abzudriften. Ne, also ich finde zum Beispiel den Punkt, den du das Beispiel was du genannt hast, zum Beispiel Funktionen finde ich gut, weil zum Beispiel ich habe am Anfang auch Funktionen geschrieben, die waren elendig lang und wenn du dich aber von Anfang an so ein bisschen halt wie gesagt an die Richtlinien oder an die Vorschläge vom Clean Code hältst, dann kommst du halt eben halt genau in diesem Punkt,
dass du sagst okay. Du denkst darüber nach, du fängst an, dass dieser Prozess in deinem Kopf entsteht, dieser Gedankenprozess, der sagt, ist es jetzt gerade gut, dass ich so ne lange Funktion hab und wie kann ich diese Funktion vielleicht aufteilen, also wirklich diese?
Diese Aufsplittung dann auch gedanklich sozusagen, die diesen diesen Gedankenanstoß geben, das finde ich auf jeden Fall super gut und das hilft mega, weil am Ende hast du ja auch einfach ne deutlich erhöhte Lesbarkeit und auch deine Wartbarkeit des Codes wird halt besser. Ich sag mal so, die Wartbarkeit des Codes, ich glaube, wenn man das als Anfänger gehört oder als Anfängerin. Dann denkt man sich vielleicht so. Ja, mir ist doch die Wartbarkeit
total egal. Ich schreibe hier ein paar kleine Funktionen, aber zumindest die Lesbarkeit ist ja trotzdem auch wichtig, weil wenn du irgendwann mal wieder drauf zurück guckst auf deinen Code und egal auf welchem Level du arbeitest oder du dich bewegst, sage ich jetzt mal, es ist ja egal, weil wenn du irgendwann mal wieder zurück guckst, ist es
ja schön zu sehen okay. Mensch, ich kann ja, ich versteh noch, was ich da mal gecodet hab Punkt 1 und Punkt 2 was ich zum Beispiel aber auch sehr sehr schön finde ist der Punkt auf Code zurückzugucken den man mal geschrieben hat und sich aber auch so n bisschen so weißt du darüber zu schmunzeln und zu sagen ja guck mal ey, also kann ich mittlerweile besser, ist ja auch n gutes Gefühl so ne. Ja klar, das zeigt ja auch, dass man Fortschritte gemacht hat, find ich.
Ist sogar n sehr wichtiger Aspekt, wenn man zum Beispiel auch so n bisschen ins Druggeln kommt und sagt ha. Ja, ich weiß nicht, bin ich wirklich gut und irgendwie
verstehe ich das nicht. Kann ich überhaupt entwickeln, dann ruhig mal so auf vergangene Tage gucken, wie du gerade meintest und dann sieht man, hey ja, ich werde besser, meine Skills werden besser und ich werde n besserer Entwickler, das motiviert ja auch weiterzumachen, gerade an den an den ersten Tagen so ne oder ersten Wochen. Bisschen gegen das. Apostelsyndrom kämpfen genau. Und ich find Wartbarkeit ist auch n gutes Stichwort.
Was du jetzt schon angerissen hast, was wo Clean Code auf jeden Fall einzahlt, weil man muss ja auch bedenken, dass man irgendwann halt nicht mehr alleine entwickelt, sondern in einem Team an größeren Projekten und dass gewisse Teile der Software auch mal Monate ruhen können, bevor da mal wieder was geändert oder erweitert wird und dann muss das ganze lesbar sein, Wartbar sein, verständlich sein und da zählen halt diese ganzen. Richtlinien von Clean Code auch absolut mit rein und helfen
dabei, das zu gewährleisten. Ja, definitiv. Und weil du zum Beispiel ja auch angesprochen hat, wir hatten ja auch eine Folge übers Testen, Reduktion von Fehlern, kannst du natürlich auch super erzeugen, oder?
Oder haben sozusagen oder wie man es auch immer nennen mag, durch halt eben eine höhere Test, also eine höhere Abtestung des Codes. Das heißt, wenn du je mehr gute Tests du am Ende hast, desto mehr reduzierst du natürlich auch die Fehler, die du dann am Ende im Code praktiz Praktizierst Erzeugst sozusagen, die dann auftreten und das ist natürlich auch einfach ein wichtiger Punkt und das heißt?
Es ist natürlich auch wichtig zu sagen, gut okay schreibe ich gute oder schlechte Tests sozusagen, also die Qualität der Tests selber sind auch maßgeblich dann entscheidend über die Reduktion der Fehler innerhalb des Codes, auf jeden Fall aber, wie wir auch schon in anderen Podcast folgen auch gesagt haben, es ist einfach wichtig, auch diese Erfahrung über Tests zu sammeln und damit hast du halt einfach die Möglichkeit am Ende sozusagen auch vorbeugend.
Fehler im Code überhaupt nicht auftreten zu lassen. Guter Punkt. Und wie gesagt, wenn man als Anfänger sich mit Clean Code beschäftigt, wird man auf das Thema Testings stoßen und wenn man das den ernsten Effekt man auch frühzeitig an zu testen was ne super Sache ist, deswegen ein ganz klarer Pluspunkt in Richtung Clean Code. Ja, das sind doch so eigentlich gute Punkte. Mal zusammengefasst über die Folgen, die wir gedreht haben.
Es sind natürlich noch detailliertere Punkte in den einzelnen Folgen, also wie gesagt, liebe Zuhörer, liebe Zuhörer, hör da gern noch mal rein, wenn dich das interessiert, ansonsten würde ich sagen, lass uns doch mal gucken, aus heutiger Sicht, wie gesagt, das Buch, das das berühmte Buch dazu, wir können es auch gerne noch mal in den Shownotes. Verlinken, weil es lohnt sich auf jeden Fall, es gelesen zu haben als Softwareentwicklerin
oder Softwareentwickler, aber es ist halt auch schon in die Jahre gekommen und es gibt halt auch kritische Stimmen dazu und das würde ich gerne mal betrachten. Was ist so ein Punkt wo du sagst, ja, da ist es, da ist es schon kritisch für mich persönlich oder da. Bin ich nicht ganz einverstanden und da leb ich das nicht so zu 100%, wie das Buch es vorsieht. Ich jetzt ja ne, ich leb das 100% so. Leb das 100% OK, fabi hat denn keine kritische.
Stimme Nein, also das Erste, was mir wirklich einfällt, ist zum Beispiel der Punkt Funktionen. Also es heißt ja. Eine Funktion darf nicht zu lang werden. Eine Funktion sollte eigentlich nur, sagen wir mal, maximal 10 Zeilen lang sein oder so, am besten noch kürzer. Und wenn man jetzt aber wirklich mal, sagen wir mal aus der Entwicklersicht guckt im Alltag und du hast vielleicht eine Klasse, wo du Funktionen hast und jede Funktion ist tatsächlich nur 5 Zeilen lang oder so.
Also gehen wir mal von den logischen Zeilen aus, weil geschweifte Klammern zum Beispiel ist dann irgendwie angenommen bei Java oder so. Du hast geschweifte Klammern und dann ist die letzte Zeile, das gilt nicht. Aber wenn. Du das hast, dann hast du natürlich immer kleine Brocken, die du dir anguckst und die Funktionalität einer Funktion umfasst dann vielleicht eine bestimmte, eine bestimmte Aufgabe, aber Fakt ist es, du springst ja nur noch durch deinen Code.
Also das heißt du. Guckst in die Funktion rein, sagst okay hier gehe ich rein, okay wo ne da passiert das und das was ist denn das? Dann gehst du da rein, dann hast du da vielleicht wieder 2 Funktionen die du aufrufst hintereinander oder was auch immer das heißt du bist ja immer nur von Funktion zu Funktion springst du durch deinen Code bis du irgendwann vielleicht mal dieser Stelle bist, die du dir
angucken willst. Und vielleicht ist das dann auch wieder nur eine bestimmte Teilaufgabe, das heißt du musst dir das dann kurz noch merken, wieder zurückspringen und und und. Und da finde ich ist es schon auch wertvoll zu sagen okay. Du kannst Funktionen auch schon
ein bisschen länger machen. Solange sie aber gut strukturiert sind und solange du sie gut lesen kannst, also zum Beispiel ich bin Fan davon, auch mal zu sagen, du hast eine Funktion und die ist vielleicht 20 Zeilen lang, ja okay, dann ist es so. Aber du kannst ja zum Beispiel auch mal eine Leerzeile einbauen, um zu sagen, okay, hier passiert zum Beispiel Schritt 1 und da passiert zum Beispiel Schritt 2. Aber das dann zum Beispiel
unbedingt auszulagern in eine eigene Funktion, wo du dann aber vielleicht wieder noch 3 Parameter mehr reingeben musst, die du aber eigentlich gar nicht unbedingt übergeben muss, beispielsweise einer neuen Funktion, das kann halt durchaus auch sehr verwirrend irgendwann sein und deswegen bin ich zum Beispiel Fan zu sagen, Versuch die Funktion, also die Funktionen jetzt nicht elendig ausufern zu lassen. Aber es müssen auch nicht unbedingt 5 Zeilen oder so sein.
Also die muss nicht unglaublich klein sein und es ist auch okay, wenn du vielleicht mal 3 Schritte innerhalb einer Funktion machst und dann halt diese diese Funktion vielleicht nicht wirklich eine absolut einzelne Aufgabe erfüllt, aber sage ich jetzt mal fachlich schon irgendwie das macht was sie soll. Dazu kommt natürlich dann noch
ein guter Name, logischerweise. Ja, also ich finde der der Punkt zu sagen, OK ich muss dann diese 1 diesen einzelnen Teilbereich der Funktion nicht noch auslagernden extra Funktion ist halt ein sehr wichtiger Aspekt, weil wenn zum Beispiel das wirklich nur für diese Funktion ist, warum, warum sollte man es denn unbedingt auslagern, nur damit die Funktion kürzer sind und man diese Single Responsibility halt sehr fein granular hält? Weil das ist immer die Frage.
Aus welcher, aus welchem Raster betrachte ich das ganze Single Responsibility? Ne, weil ich kann ja auch das übergeordnete Thema nehmen und sagen, diese Funktion ist dafür verantwortlich. Natürlich sind da Teilfunktionalitäten dann drin, wo ich sagen kann, nee, das ist nicht mehr deren Verantwortung, aber irgendwie bildet es ja nen Rahmen nen semantischen. Ja.
Und das? Ist auch nachher so n Erfahrungswert zu sagen, OK wie setz ich diesen Rahmen an, also dieses Raster wie Glieder ich das aber wenn du zum Beispiel diese Teilfunktion eigentlich gar nicht mehr woanders brauchst, ja dann lass es da drin und ich find so ne Leerzeile kann halt auch Wunder bewirken, dann einfach ne und das ist halt n riesen Punkt, dass du halt nicht in diesen
Modus verfällst. Ich muss das jetzt super streng durchsetzen und Funktion, Funktion oder sagen wir mal ne objektorientierung noch ne klasse was ist das? Ah, das ist ja jetzt irgendwie so ne eigene Aufgabe.
Ah jetzt werd ich mir mal ne Klasse anlegen die das macht, dann hol ich mir n Objekt davon und zieh das durch, so weißt du, dass du halt so in so n klassenwahn verfällst oder in so n funktionswahn wie du so schön meintest, dass andere Entwickler nur noch am hin und Herklicken sind und dann am Ende auch nicht schneller die Gesamtfunktion verstehen, als hätten sie es. In 3040 Zeilen weiß ich, wie viele untereinander weggeschrieben. Im Gegenteil, das wird
wahrscheinlich länger dauern. Das Rumbrowsen scrollen und alles um diese Gesamtfunktion zu verstehen und da ist man auch wenn man sich so aktuelle Projekte anschaut, da geht man halt sag ich mal n bisschen weg von. Wieder hinzu, so einem pragmatischen Ansatz zu sagen, es kann auch mal länger sein, es muss halt ne gute Struktur da drin sein. Aber das. Ist halt nicht sonst wie tief verschachtelt beispielsweise. Das wär viel schlimmer als n paar Zeilen mehr Code sag ich mal. Definitiv.
Aber und also es ist halt am Ende wieder n Trade off, weil zu sehr verschachteln doofe Sache. Aber wenn jetzt zum Beispiel, du sagst ja ne Klasse, hat jetzt aber keine Ahnung 2000 Zeilen oder so, dann ist das auch zu viel.
Also da muss man dann halt und und das ist aber genau find ich wieder der der wertvolle Punkt, der einen sozusagen clean Code gibt, einfach zu sensibilisieren darauf und gleichzeitig aber auch noch zu sagen, OK, ich muss es ja nicht, wieso n Hardliner durchziehen und sagen, OK, jetzt muss hier alles so und so, aber diese Sensibilisierung dafür zu sagen, OK.
Es soll nicht zu groß sein, eine Klasse darf nicht zu groß sein, aber ich darf auf der anderen Seite aber auch nicht zu viele kleine Klassen haben, sozusagen ne.
Genau. Genauso finde ich zum Beispiel auch Abstraktionsebenen, beispielsweise auch n. Interessanter Punkt, wenn wir gerade dabei sind, weil ich finde, solange du ein Interface hast, ne wo du sagst, OK das und das kann davon erben oder beziehungsweise kann dieses Interface implementieren, sorry nicht erben, dann ist das in Ordnung, aber sobald du das aber noch. Noch krasser in die Tiefe ziehst, dann wird es irgendwann auch unverständlich, dass du dann irgendwann nicht mehr so
richtig durchblickst. Und ich finde, man kann sich natürlich hinstellen, sagen ja gut, wenn man das aber nicht versteht, dann ist man vielleicht auch nicht so ein guter Entwickler oder so eine gute Entwicklerin. Ich finde immer die Frage an der Stelle ist ja was ist, wenn du dir das selber noch mal nach einem Gewissen.
Zeitlichen Abstand anguckst. Verstehst du es dann immer noch, weil ich glaube, jeder kennt das, dass man irgendwie mal was implementiert hat und sich dachte, Boah, das war jetzt so n richtiger Geniusstreich von mir so, es war der Hammer ne also wie krass und dann irgendwann guckst du wieder drauf und denkst dir so boah Alter was ich schnall es gerade nicht so und dann ist es eigentlich n Zeichen dafür, dass es halt zu krass ist so ne. Ja, und das ist halt auch direkt
der nächste Punkt, wenn du an. An einer Stelle in der Software wirklich einen sehr komplexen Task löst. Dass du sagst okay ich muss hier was Aufwendiges berechnen, ist irgendeine komplexe Formel und Clean Code sagt Nein. Kommentare sind böse. Also jetzt mal so im allgemeinen Tonus und der Code muss sich selbst erklären, dann denke ich mir so ja bin ich auch ein Verfechter von ich kommentiere meinen Code persönlich auch wenig, weil ich auch der Meinung bin er muss sich selbst erklären.
Aber du darfst jetzt nicht in die Richtung gehen zu sagen, nein, ich muss jetzt kurz schreiben, der muss sich selbst erklären. Kommentare sind böse, weil wenn ich zum Beispiel eine Stelle hab wie eine komplexe Formel und da was berechnet wird, was irgendwie Erklärungsbedarf hat, warum das überhaupt so berechnet werden muss, hey dann mach n Kommentar an, das wird der nach Welt helfen das zu verstehen.
Und nicht zu sagen, ja, das ist aber jetzt kein Cleancode mehr und das find ich, ist in dem Buch einfach n bisschen drastisch beschrieben zu sagen, nee, das braucht man nicht, das muss alles über die ganzen Cleancoderegeln abgedeckt sein, sozusagen. Ist halt dann einfach kontextabhängig. Ja, es ist ja wie zum Beispiel, wenn du irgend ne bestimmte Konstante hast oder so, da weiß ich nicht bestimmte Berechnungen.
Ich meine wahrscheinlich weiß fast jeder, wie man zum Beispiel den Inhalt von einem Kreis berechnet, mal als Beispiel.
Aber wenn du jetzt zum Beispiel wirklich Formeln, die bisschen über das hinausgehen, ne irgendwie auch in deinem Code hast, dann macht es durchaus wahrscheinlich Sinn zu sagen, OK, an dieser Stelle mit dieser Formel wird das und das vielleicht berechnet, einfach so als als Teilberechnung oder so, weil oder oder ne Konstante zu erklären, warum dieser wert halt so ist wie er ist oder was auch immer. Das macht ja durchaus manchmal Sinn, also sehr, sehr
domainspezifisches wissen. Was du im Normalfall vielleicht auch gar nicht so im Kopf hast. Das macht durchaus Sinn. Ich finde zum Beispiel auch, wenn man jetzt im Bereich apis oder so guckt, also zum Beispiel, Du hast eine Web API, eine Rest API oder so und die du anbietest und du möchtest zum Beispiel als Entwickler oder Entwicklerin daran arbeiten und du Implementierst zum Beispiel ein Backend mit dieser API, die du ansprechen kannst, dann ist es ja schon irgendwie.
Interessant, einmal so ein bisschen diese diese Schnittstelle zu beschreiben, ne klar kannst du das jetzt.
Natürlich kannst du auch sagen okay, ich mache das auf Doku Ebene auch eine Möglichkeit, aber ich finde es ist auch in Ordnung an dieser Stelle zum Beispiel diese API Schnittstelle zum Beispiel auch Daten die man entgegennimmt oder ne die dann rausgehen auch durchaus beschreiben zu können, an dieser Stelle ne und dann vielleicht auch wieder wenn es domainspezifisches wissen ist, dass du sagst okay hier ist das so und so und bla bla und so weiter.
Ist manchmal einfach hilfreich und deswegen würde ich halt auch nicht sagen Ey Kommentare ist ein no go, schmeißt sofort alle Kommentare raus, aber es ist ja genau wieder dieser dieser dieser wertvolle Punkt. Wenn wenn du dir sagst okay keine Kommentare sagt Clean Code so mal ganz hart und übertrieben gesagt, dann okay kann man ja zumindest wieder diesen Gedankenanstoß nehmen und sagen. Ich will hier gerade einen Kommentar anschreiben. Muss ich das denn überhaupt?
Kriege ich das vielleicht auch ohne Kommentar hin? Ist es denn verständlich, ist mein Code ohne Kommentar verständlich, kriege ich meinen Code ohne Kommentar verständlich hin, dass man den Kommentar nicht braucht, wenn man aber dann zu dem Beschluss kommt, nee, ich wäre schon besser, wenn man dann einen Kommentar dran schreibt, dann ist das in Ordnung so. Ja, absolut.
Es ist halt auch immer die Frage, welchen Kontext man sich bewegt, welches Projekt, welche Programmiersprachen, welche Frameworks verwendet man, weil man muss auch klar sagen, dass diese ganzen Punkte immer sehr stark in die Objektorientierungsrichtung geht.
In dem Buch ist ja auch, Oh, jetzt muss ich kurz überlegen, Java. Die Beispiele sind in Java und es ist Objektorientiert. Und wenn ich jetzt aber meinetwegen mit Python oder auch zum Beispiel mit javascript gar nicht objektorientiert unterwegs bin, sondern eher so funktionale Ansätze verfolge, dann spielt vieles davon halt auch keine
Rolle, sozusagen. Klar, man kann das alles im Hinterkopf behalten, aber es kann nicht 1 zu 1 denn gemapt werden und sollte dann auch nicht so streng sag ich mal verfolgt werden. Wenn es gar nicht zu der zu der eigentlichen Art der Sprache oder der Programmierung gehört, ja finde ich es halt dabei auch ein ganz wesentlicher. Aspekt definitiv, was zum Beispiel auch. Also wir sind ja auch Verfechter, zum Beispiel vom Testen, ne, da möchte ich auch noch mal kurz drauf eingehen,
weil. Ja, das ist absolut richtig. Testen immer. Genau testen, immer das also soweit würde ich auf jeden Fall mitgehen und sagen, ja, man sollte auf jeden Fall Tests für seinen Code haben.
Die Frage ist aber zum Beispiel, mit was für einer Testabdeckung, weil es gibt ja manche die sagen 100% testabdeckung so wahrscheinlich, weil dann irgendwelche Leute sich denken, ja, 100% testabdeckung muss doch zwangsläufig besser sein als zum Beispiel ne 90 prozentige testabdeckung, so nach dem Motto ne. Aber genau an der Stelle ist es Halt, finde ich wichtiger zu sagen okay wie gut sind deine Tests, wie gut kannst du dich auf diese Tests verlassen
anstatt zu sagen, ich teste jetzt wirklich jede, also irgendwie jeder Test den ich habe testet auch wirklich irgendwo eine Zeile im Code und wenn das nicht der Fall ist, dann gibt es halt, ist es halt irgendwie problematisch, sondern es ist ja viel viel wichtiger zu sagen, wenn ich Tests habe und. Ich zum Beispiel sage okay ich habe ein neues Feature und dieses Feature bringe ich jetzt raus.
Dann kannst du ja vielleicht irgendwie deine Testabdeckung auf 100% bringen und irgendwie sagen, ich habe jetzt irgendein Test, der irgendwie eine bestimmte Zeile ansteuert, so richtig auf Krampf, aber wenn du dann am Ende zum Beispiel trotzdem mit diesen Tests Fehler durchlässt, dann bringen dir diese Tests und diese 100 prozentige Testabdeckung auch
eigentlich nicht so viel und? Da ist es halt einfach viel, viel wichtiger zu sagen, angenommen, ich hau ein neues Feature raus und dieses Feature kann von einem Kunden von einem User verwendet werden. Wie? Weit kann ich mich denn verlassen auf meine Tests, dass ich sage, ich roll das jetzt aus und die Tests liefen grün, also glaube ich auch und vertraue auf meine Tests und sage okay, wenn die Grünen liefen, dann wird die Software auch noch so funktionieren wie ich, wie ich es mir.
Vorstelle. In dem Buch ist ja. Sagen wir mal so, was mir aufgefallen ist, als ich es damals gelesen hab ist, dass auch gerade hinsichtlich testen und allem. Es ist halt schon sehr subjektiv und als eindeutige Wahrheit dargestellt, auch gerade das Testing Kapitel und ich finde halt zum Beispiel, dass.
Gerade jetzt, Jahre später gar nicht thematisiert wird automatisiertes Testen, zum Beispiel, wenn man jetzt so in die DEF Ops Richtung geht mit einer Pipeline Test Driven Development wird glaub ich nur angerissen, aber das wär für mich eher so n Punkt den man kommunizieren sollte ne also das ist halt auch so der Punkt, dass man sagen muss es ist in die Jahre gekommen, ich meine auch mal gelesen zu haben. Dass der Autor selbst sagt, sein Buch ist überholt, das finde ich
halt auch spannend. Ja. Weil es ist an sich immer noch n bedeutendes Werk in der Softwareentwicklung und ich glaube jeder Entwickler und jede Entwicklerin wird irgendwann darüber stolpern und man sollte es auch ruhig mal gelesen haben, bin ich fest der Meinung, weil es sind sehr gute Ansätze drin, aber es ist halt sehr subjektiv am Ende. Ja, also das ist halt genau der Punkt, weil es sind halt keine Regeln, dass du sagst.
Arbeite strikt nach diesen Regeln und dann wird dein Code super, sondern es ist ja eher sind ja eher hattest du vorhin auch eigentlich so schön gesagt, es sind ja eher Richtlinien, nachdem man sich so ein bisschen orientieren kann und sagen kann okay, da wurde mal was niedergeschrieben und Ideen, Konzepte verfasst die an die man sich anlehnen kann und die man auf jeden Fall würde ich sagen, in seine Programmierung.
Mit einbeziehen sollte oder in in den Prozess der Softwareentwicklung, also das gar nicht. Also das komplett zu ignorieren würde ich sagen, das wäre nicht gut, aber ich glaube, dass es einfach unglaublich wertvoll ist zu sagen, wie du meintest, man sollte es mal gelesen haben und man sollte über solche Sachen nachdenken oder es im Kopf haben und dann aber trotzdem auch noch zusätzlich die eigene Erfahrung mit einfließen lassen in diese Entwicklung und auch eigene
Gedanken logischerweise und. Ja, ich finde, das ist auch ein super Abschlusswort. Ich habe da gar nichts hinzuzufügen, nur an der Stelle noch mal bei all der Kritik, die man an dem Buch Halt haben kann oder äußern kann, muss man sagen, dass Robert Martin oder wie ich jetzt Anke Bob genannt hatte, weil er ist ja darunter bekannt, muss man sagen, ist schon ein Vorreiter auch in der Softwareentwicklung.
Gewesen und ist es auch noch und erhält erhält auch coole Vorträge und das Buch hat auf jeden Fall seinen Mehrwert. Das möchte ich einfach nur noch mal so am Ende zusammenfassen, dass man das wirklich anerkennen kann und sollte, das ist schon wirklich, ja man kann es schon sagen, es ist auch n Meilenstein da so in der Softwareentwicklung das Buch. Ja, ich finde man kann Software, also wenn man auf nichts hören
möchte. Dann finde ich, ist zumindest eine eine Leitlinie, die man haben sollte ist, wenn man selber Code schreibt, sollte man immer darauf achten oder daran denken, dass andere Leute den eigenen Code lesen und darauf achten, dass er verständlich ist. Für andere auch, vielleicht nur für fiktive Leute.
Also wenn du Code auch nur für dich selber schreibst, ist es auch, kann man sich auch hinstellen und sagen, was ist denn wenn jetzt jemand anders diesen Code sehen würde, also dass man einfach sozusagen andere Leute. Im Blick hat und sagt, schreibe ich hier gerade Code, der soweit zufriedenstellend ist, dass andere, die den Sehen auch sagen würden okay. Das passt erstmal so.
Und wenn du mit dieser Brille da drauf guckst auf die ganze Geschichte, ich glaube, dann hat man auch noch mal so ein paar Gedankenanstöße, die man dann sozusagen generiert, einfach zwangsläufig. Ja. Sehr guter Punkt, hab ich nichts hinzu. OK ja Tino, dann würd ich sagen, danke für die Schöne für diesen schönen Abschluss der Kincode Reihe. Ja die die. Reihe war echt cool, die hat mir ne Menge Spaß gemacht, weil man auch einfach selbst noch mal.
Sich sich als Coder reflektiert hat und über die einzelnen Punkte nachgedacht hat. Und das ist am Ende ja auch das, was dabei rumkommen soll, gerade wenn man solche Bücher denn auch liest. Definitiv. Ich find es auch lustig, dass auch gerade wenn wir zum Beispiel zusammen programmieren, auch beruflich, dass wir auch einfach durch diese Reihe auch selber einfach noch mal bestimmte Sachen stärker sensibilisiert haben. Das find ich einfach, find ich auch gut, also.
Wir können ja auch unseren Mehrwert rausziehen. Alles klar in dem Sinne hat es mir auf jeden Fall wieder super viel Spaß gemacht. Ich würde sagen, wir beenden die Folge und die Reihe, außer es kommt noch was von euch oder von dir. Liebe zuhören lieber Zuhörer, wenn du noch Anmerkungen hast, Ideen, Vorschläge für ein weiteres Clean Code Thema wie wir am Anfang der Folge schon meinten, dann schreib uns das gerne auf der Podcast Mail, die findest du unten in den Shownotes.
Genauso würden wir uns natürlich super über Feedback freuen, das heißt in Form von Feedback über eine Mail, über diese Folge über unseren Podcast. Bewerte gerne unseren Podcast auf der Plattform, die du gerade hörst und empfiehlt auch gerne ein 2 Freunden oder arbeitskolleginnen Kolleginnen auch gerne diesen Podcast weiter und wenn du sagst Coding Buddy ist die beiden diesen cool. Das Projekt, das finde ich super cool und mir gefällt der Podcast, dann kannst du auch
gerne eine kleine Spende nehmen. Hinterlassen. Das würde uns auch mega freuen. Dann können wir auch weiterhin unseren Content dahingehend verbessern und ansonsten würde ich sagen, hören wir uns in der nächsten Folge wieder und Tino Wir sind raus, macht's gut bis zum nächsten Mal eure Coding Vice. Gemeinsam besser.