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.