Latest / Coding Buddies | Tech & Dev-Mindset / Clean Code #9 - Überholt und Unbrauchbar?

Transcript

Clean Code #9 - Überholt und Unbrauchbar? · Coding Buddies | Tech & Dev-Mindset

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