Latest / Coding Buddies | Tech & Dev-Mindset / Cleverer Code? Klingt gut, ist es aber nicht!

Transcript

Cleverer Code? Klingt gut, ist es aber nicht! · Coding Buddies | Tech & Dev-Mindset

0:00
Und ich weiß nicht, ob du dich auch schon mal auf so ein
0:02
Experiment eingelassen hast, wo man dann sagt, Ja, komm, wir
0:04
probieren noch mal a. Eigentlich hast du recht,
0:06
wirklich gute überzeugende Argumente, man probiert A ist
0:09
irgendwann an einem Punkt wo man sagt und deswegen haben wir
0:12
nicht a genommen. Coding Buddies Dein Podcast rund
0:17
um Softwareentwicklung und aktueller Tech News herzlich
0:20
Willkommen. Moin Moin und herzlich
0:33
Willkommen zur neuen Folge des Coding Bodys Podcast.
0:36
Schön, dass du wieder eingeschaltet hast, deine
0:38
Gastgeber, du weißt es schon, aber wie soll es auch anders
0:40
sein, meine Wenigkeit, der Tino und auch der fantastische Fabi,
0:43
den ich begrüßen möchte, er guckt mich schon an, er grinst
0:46
mich an, er freut sich, er hat einfach Bock auf diese Folge
0:49
heute fabi was geht ab Hallo Tino.
0:55
Das wäre so geil so, er lacht schon, er freut sich.
0:58
Moin er. Ist eigentlich gar nicht.
1:02
Da, nee, ja, hi grüß dich Tino, Lass uns mal grüße dich hier
1:06
jetzt mal heute schön ne neue Podcast Folge aufnehmen.
1:09
Ich freue mich auch auf jeden Fall schon aufs Thema, aber
1:12
bevor wir richtig losstarten geht's dir denn gut?
1:15
Ja mir geht's gut soweit, ich hatte ein sehr entspanntes
1:18
Osterfest. Ich konnte mich echt mal so
1:20
richtig entspannen über die Feiertage, das war richtig gut.
1:23
Aber jetzt steht ja wieder was Aufregendes vor der Tür, und
1:25
zwar unser Flappy Buddy Turnier. Da heißt es natürlich wieder
1:31
Action und was wie werden die Bots abschneiden?
1:34
Also ich bin auf jeden Fall schon wieder richtig gespannt
1:36
fabi. Ja, ich bin auch gespannt.
1:37
Ich bin wahrscheinlich wieder wie beim letzten Turnier auch
1:39
schon gespannter als eigentlich die teilnehmenden Mal gucken.
1:44
Ich find das auf jeden Fall mal cooles Event, das findet ja auch
1:46
am 29.4. Statt, so ist es auf jeden Fall
1:49
stand jetzt geplant, ich denke mal das ziehen wir auch so
1:51
durch. Und ja, liebe Zurin, lieber
1:53
zurer, schalt auf jeden Fall mal bei Twitch ein. 20:00 Uhr geht's
1:56
los und also generell ne genau. Ja, und bis dahin können wir ja
2:03
noch n Thema bequatschen. Fabi, ich hab n ganz cooles
2:06
Thema mitgebracht und zwar ist es jetzt heute mal wieder so ne
2:10
typenfrage beziehungsweise philosophisch fast schon, aber
2:16
wir versuchen das natürlich auch unsere Sicht der Dinge dahinter
2:19
fachlich zu begründen. Also auch wirklich Pros und Cons
2:23
wieder anzubieten. Und zwar soll es heute um das
2:26
Stichwort cleverer Code gehen, da gibt es auch so n paar
2:31
Artikel dazu, das ist eigentlich n ganz spannendes Thema und zwar
2:35
einfach mal sich zu überlegen, was ist jetzt eigentlich besser
2:38
so n richtig schön cleverer Code wo sich der Entwickler denkt so
2:42
ach das hab ich so richtig schön als Einzeiler gemacht.
2:44
Das ist so richtig smart gelöst. Oder ist es vielleicht doch
2:48
besser zu sagen, nee, ich schreib lieber n paar mehr
2:51
Zeilen? Das Ganze ist verständlich und
2:53
lesbar und genau das Thema möchte ich mit dir heute mal
2:57
beleuchten. Ja, auf jeden Fall.
2:59
Also mir fällt da immer direkt erstmal ein, da kann man, das
3:03
kann man sich finde ich, so schön vorstellen, dass man und
3:06
ich glaube, das kennen vielleicht viele, dass man sagt,
3:08
so ey, ich mache jetzt mal wieder eine Aufgabe auf, zum
3:11
Beispiel so, so Code Wars oder Lead Code, also weißt du, wo du
3:13
so so kleine Aufgaben hast, mit denen du dich challengen kannst.
3:17
Ne, und dann liest du dir so die Aufgabe durch und denkst dir so,
3:21
ja, jetzt geht's los, weißt du, dein Kopf fängt an zu rattern,
3:23
wie löse ich das Ganze? Und dann kommt man ja mal.
3:27
Zumindest das ist ne Sache, da geht es mir so, da kommt man
3:30
immer relativ schnell dann auf den Punkt, dass man sagt, ja,
3:34
ja, ich will jetzt, ich lös das irgendwie.
3:36
Na ja, ich hab n Algorithmus im Kopf, aber warte, warte warte
3:39
ich, ich krieg das noch besser hin, ich ich das das das könnte
3:42
n Onliner werden, ah wie braucht wie ist die Syntax dafür, dass
3:45
ich den Onliner hinkriege, was muss ich da, welche Funktion
3:47
gibt es? Ah dann ratter zweiter, Ratter
3:49
zweiter und dann kommt also. Das ist ja dann so n so n
3:54
Gefühl, dass man sich so denkt. Ich will mir nicht die Blöße
3:57
geben, weil ich kann das besser, ich kann das in dem One Liner,
4:00
weißt du und ja, ich find das, manchmal hat man dann auch
4:04
direkt erstmal so, da überschlagen sich die Gedanken
4:09
und man kommt eigentlich erstmal zu gar nichts, weil man sich
4:12
erstens denkt, OK ich hab n Algorithmus im Kopf, du
4:14
versuchst ihn direkt zu optimieren.
4:16
Und hast noch nicht mal irgendwas hingeschrieben.
4:18
Weißt du so dieses typische, wenn du jetzt wirklich nach Tdd
4:21
zum Beispiel Codes sagst? Du schreibst einen Test.
4:23
Du machst eine Implementierung und dann kannst du hinterher
4:25
immer noch refact an alles cool, aber man versucht halt immer
4:29
erstmal gleich, zumindest kenne ich das so je weniger Code desto
4:33
besser One Liner, super clever und ob man es aber jetzt
4:37
sozusagen dann schafft oder nicht, diese One Liner Lösung
4:41
nenn ich es jetzt mal hinzukriegen sei mal
4:43
dahingestellt, aber. Die Frage ist ja, wie du schon
4:48
so schön eingeleitet hast. Ist es jetzt wirklich immer gut
4:51
auch so ein One Liner zu haben? Weil klar es gilt als clever ne,
4:55
aber es ist jetzt also da steckt ja zwangsläufig ne Menge
5:01
Überlegung hinter, dass du das so komprimiert bekommst, ne?
5:05
Ja. Ich find es halt auch spannend,
5:08
wenn wenn wir jetzt noch mal das Thema Code Wars aufgreifen, weil
5:11
in unseren Live Streams auf Twitch machen wir ja auch öfter
5:14
mal Code Wars Aufgaben und lösen die so zusammen mit der
5:17
Community, überlegen uns dann wie könnte man das lösen, was
5:20
könnte man verbessern und da ist man ja auch immer so getrieben
5:25
zu optimieren ne also wir versuchen ja auch wirklich gute
5:28
Lösungen einzureichen, sie zu minimieren in Sachen Codezeilen
5:33
auch mal ruhig n kleinen Kniff einzubauen.
5:37
Aber sind trotzdem am Ende immer Verfechter davon, dass man sich
5:42
diese Funktion anguckt und sie noch versteht, was da passiert?
5:45
Und da ist nämlich genau auch wieder der Punkt, wenn ich zum
5:47
Beispiel bei Codewars dann meine Lösung einreiche, sehe ich ja,
5:51
und das finde ich auch sehr cool, an der Plattform die
5:54
Einreichung der anderen ne und dann kann man die bewerten, dann
5:57
gibt es ja clever glaube ich wirklich auch als Feld ne so
6:02
kann kannst du Punkte vergeben. Und dann sind da manchmal
6:04
Lösungen bei, die wirklich sehr kurz und knapp sind, aber die
6:09
man dann einfach auch nicht mehr sofort versteht.
6:11
Und genau da ist nämlich der Knackpunkt ne, so dass wir
6:14
sagen, nein, wir wollen, dass man diese Funktionen, die wir
6:17
geschrieben haben, noch verstehen kann, und das ist
6:21
nämlich auch der große Unterschied, wenn ich ne Code
6:23
Ross Aufgabe mache, dann guck ich mir eine Funktion an und
6:26
versuch da denn halt mich so n bisschen auszutoben die
6:29
hocheffizient zu machen oder oder super smart zu lösen.
6:33
Aber es ist halt nur eine Funktion, ne und da müssen jetzt
6:35
nicht andere Entwickler noch mit arbeiten oder es muss nicht
6:38
eingebettet werden in ein großes Projekt und deswegen da ist halt
6:41
wirklich die Frage. Da.
6:43
Kannst du flexen, was genau? Da kannst du ruhig mal flexen,
6:47
aber was für n Eindruck macht das auch gerade auf Junior
6:51
Developer zum Beispiel. Und da möchte ich mal was mit
6:55
dir bequatschen, weil das fand ich sehr witzig.
6:57
Und vielleicht erkennt sich da der eine oder andere oder die
7:01
andere wieder es. Gibt so gefühlt.
7:04
Phasen im Entwicklerleben, die man so durchschreitet, und die
7:08
habe ich auch an mir selbst zum Beispiel wahrgenommen.
7:12
Auch jetzt, so rückblickend. Das heißt, wenn du so
7:14
beispielsweise Junior dev bist und noch am Anfang deiner
7:17
Karriere stehst. Dann codest du ja oft.
7:20
Also dann ist dein Algorithmisches denken noch
7:22
nicht so ausgeprägt beziehungsweise du hast halt
7:25
einfach noch nicht so viel Erfahrung gesammelt und man
7:28
codet meistens oder oft auch unabsichtlich kompliziert.
7:34
Ne, gehst halt so Wege die du vielleicht kennst, die aber
7:37
nicht so optimal sind, dafür vielleicht umständlich sind, ja
7:41
zum Beispiel also sehr verschachtelter Code oder wie
7:45
auch immer. Dann kommst du irgendwann in
7:47
dieses Midlevel, dann bist du kein Junior Developer mehr, bist
7:50
aber auch noch nicht so Senior Death, sondern du bist halt so
7:53
normaler Developer. Aber normal jetzt nicht
7:55
abwertend. Ne, du hast halt schon so n
7:57
bisschen Erfahrung gesammelt und da war das bei mir zum Beispiel
8:00
und das war auch gerade so meine Embedded Zeit in C, dass ich mir
8:04
dachte, Na jetzt musst du ja zeigen, dass du es kannst, ne
8:08
und dann fängst du halt an so. In Anführungsstrichen clever zu
8:12
coden und dann hab ich da halt auch so Lip Funktionalitäten
8:15
implementiert und das waren halt auch teilweise ein Zeiler so ne
8:19
also oder hocheffizient einfach, aber so richtig verstehen konnt
8:24
die keiner. Also dann kamen halt auch
8:25
Kollegen an und meinten Ey ich wollt da irgendwie die Library
8:28
erweitern aber irgendwie check ich die Funktion nicht.
8:31
Und du denkst dir so in deinem Midlevel ja, weil sie halt super
8:35
clever ist. Ne guckst selbst drauf nach
8:38
Wochen und denkst dir oh warte mal.
8:39
Jetzt muss ich aber selbst erst mal überlegen und das ist halt
8:42
schon n richtig schlechtes Anzeichen zu sagen, ich muss
8:45
jetzt selbst noch mal überlegen, was ich da gemacht hab, selbst
8:47
rausgeritzt war. Ja richtig, so ne, es
8:50
funktioniert zwar, aber ich check es halt nicht mehr und
8:53
dann bist du irgendwann senior def und denkst dir so, oh mein
8:55
Gott, das darf auf keinen Fall passieren, ich muss meinen Code
8:58
mit Absicht so simpel wie möglich schreiben, nicht
9:01
schlecht simpel bedeutet nicht schlecht ja sondern so nach dem
9:04
Motto wenn er irgendwie langweilig aussieht als wenn da
9:07
nichts Cooles passiert, dann ist das schon n gutes Indiz dafür,
9:10
dass er auch gut ist. Ne, weil dann ist er klar
9:12
strukturiert, einfach verständlich und.
9:16
Wie soll ich sagen, er ist halt für alle zugänglich und das
9:19
finde ich ist halt spannend, wenn man so diese 3 Level dann
9:22
sich. Durchschaut sozusagen.
9:23
Oder mal selbst überlegt, wie das bei einem war.
9:25
Ich hab da mal so n Spruch gehört, den finde ich eigentlich
9:28
ganz zutreffend und zwar wenn du sagst, du hast also du hast zum
9:33
Beispiel n komplexes Problem und guter Code.
9:36
Wenn du gut Code hast und dieses Problem dir anguckst, dann sieht
9:40
es einfach aus. Also dass du dir denkst, Oh, der
9:43
Code, das ist ja, da ist ja nichts Komplexes dran, das ist
9:45
ja super easy und das finde ich, ist irgendwie spannend so, weil
9:49
guter Code macht etwas komplexes einfach, weißt du.
9:56
Ja, also. Er sieht einfach aus, aber
9:58
covert ein komplexes Problem und sage ich mal cleverer Code, der
10:03
sieht. Zwar sehr, also der, der ist
10:07
halt schwer zu verstehen, sieht aber auch super esoterisch aus.
10:09
Weißt du, so ganz schick und toll und so weißt du, das ist
10:13
halt so so Code der Flex, so weißt du so nach dem Motto so ja
10:16
toll, aber es bringt ja auch nix wenn du dann zum Beispiel
10:18
wirklich mit deinem Kollegen irgendwie hingehst und der kommt
10:21
zu dir und sagt ja. Ich verstehe das irgendwie nicht
10:24
mehr ne und du sagst ja, das ist ja auch, lass mal gucken, wer
10:27
hat das denn da hin geballert ne und dann weißt du so dieses
10:30
typische gitblame ach ja, das war ich, das verstehe ich selber
10:34
nicht mehr, weil ich ja ja genau, also ich fand das ganz
10:38
schön, weil halt guter Code einfach ein komplexes Problem
10:41
einfach aussehen lässt und ich finde das ist irgendwie eine
10:43
ganz nette Beschreibung dafür. Ich hatte auch mal ein ganz
10:47
cooles Motto gehört, so nach dem Motto.
10:53
Am Anfang willst du viel Code schreiben, ne, du willst halt so
10:55
den Code reinhacken und schön am Coden sein und später gerade so
11:00
als Senior Death bist du froh, wenn du Code löschen kannst.
11:02
Ne, weil da genau darum geht es, dass du es geht nicht darum viel
11:05
zu schreiben, sondern den Halt effizient zu schreiben und
11:09
trotzdem verständlich ne und wenn du dann den Moment hast,
11:12
dass du sagst ha die Funktion brauch ich nicht mehr, das ist
11:15
halt denn so später so n so n Erfolg weißt du das?
11:17
Das fand ich halt auch ganz passend ja voll also definitiv.
11:22
Und ich find da kann man halt auch n bisschen das so abgrenzen
11:26
und sagen, OK, du hast es gibt cleveren Code ne so für die
11:30
Folge jetzt und es gibt guten Code ne und manchmal also es es
11:34
gibt sicherlich auch eine Schnittmenge zwischen cleverem
11:37
Code und guten Code, das will man ja gar nicht hinstellen,
11:39
dass man sagt das eine ist so und das andere ist so und es
11:41
geht nur entweder das oder das ne, aber man muss halt eben
11:45
gucken weil wie gesagt, es ist ja auch nicht, es ist ja auch
11:49
nicht schlimm wenn du bei so einem bei so einer Plattform wie
11:52
zum Beispiel Code Wars oder so, dann versuchst es möglich clever
11:56
zu machen, ne, also das ist ja auch völlig valide, nur man muss
12:00
halt immer gucken, das ist n abgekapselter Bereich, das hast
12:04
du ja auch so schon so schön gesagt ne und ich fand übrigens
12:06
den Begriff ganz lustig dazu, das heißt den hab ich vorher
12:09
noch nie gehört jetzt so. Beim bei der Vorbereitung auf
12:12
die Folge habe ich den Begriff Code Golfing gefunden und den
12:17
kannte ich nicht. Aber es ist halt so witzig, weil
12:19
du erst mal wie beim Golfen versuchst, du halt mit möglichst
12:22
wenig Schlägen ins Loch zu treffen, ne den Ball und hier
12:25
versuchst du halt mit möglichst wenig Lines auf Code deines
12:27
Problem zu lösen. Die Tests mit Code Wars zu
12:29
bestehen und dir das Licht zu kriegen, aber das fand ich
12:31
irgendwie ganz lustig, weil ich weiß nicht liebe zorin lieber
12:34
zoro, sag uns gerne ob du das schon vorher kanntest.
12:37
Also mir war es erst mal ein neuer Begriff mir auch, aber ich
12:39
finde den auch sehr witzig den Begriff.
12:41
Aber wie gesagt, was ich noch sagen wollte ist also du hast
12:44
ja, du hast ja auch gesagt, OK man muss gucken in welchem Scope
12:48
man sich befindet, ne und ja Code wars ist n scope, da kannst
12:52
du das ja machen weil dieser Code wird nirgendswo in dem
12:55
Sinne verwendet, aber wenn du jetzt wirklich sagst OK man
12:59
verwendet sowas in der Praxis oder zum Beispiel im sag ich mal
13:02
wirtschaftlichen Kontext, dann kann es natürlich echt n
13:06
bisschen schwierig werden ne wie zum Beispiel bei dem Beispiel
13:09
was du eben gebracht hast mit deinem.
13:11
Embedded Code? Ja, da können wir auch später
13:15
noch mal drauf eingehen, weil es gibt natürlich Situationen, wo
13:20
es nicht anders geht oder wo, wo es ja nicht mit Absicht so
13:24
clever dargestellt wurde, sondern wirklich ein
13:26
hochkomplexes Problem ist, was nicht mehr so einfach
13:28
dargestellt werden kann. Und erinnere mich da noch mal
13:32
dran, weil da ist Stichwort Library dann halt auch ein guter
13:35
Ansatz. Aber ich möchte mal vorher noch
13:37
mal kurz zu diesen One Line ankommen, also zu dem
13:40
vermeintlich cleveren Code. Welche Probleme siehst du denn
13:44
da drin? Also was für mich so ein
13:46
Riesenproblem ist und das habe ich ja gerade schon angesprochen
13:49
ist, wenn du später noch mal drauf guckst oder ein Kollege
13:51
dich da was zu fragt, dann ist es einfach schwer zu debuggen,
13:55
also wirklich ihn noch mal zu verstehen und Fehler da drin zu
14:00
finden, am besten noch unter Zeitdruck weißt du die Software?
14:03
Läuft nicht mehr, Tests sind rot und du sollst jetzt irgendwie
14:05
schnell n fix finden und guckst dann genau auf so n Code.
14:08
Denkst du so ey nee, bitte nicht, ja, da sind wir ja erst
14:10
theoretisch im wirtschaftlichen Kontext, oder nicht?
14:12
Ja, das ist ja, aber ich meine das, aber das ist so der das
14:15
Problem, weswegen so n Code da quasi produktiv sag ich mal
14:20
problematisch sein kann einfach was siehst n du dann noch was
14:24
für mich so n bisschen problematisch sein könnte an der
14:26
Stelle ist angenommen du bist jetzt zum Beispiel n Junior def
14:29
ne und hast jetzt. Arbeitest halt so für für die,
14:34
ich sag mal damit du ne bisschen Gehirnjogging betreibst, machst
14:38
du sowas wie Code was und siehst halt immer so hochoptimierte
14:40
Lösungen und denkst dann eventuell noch bevor du ins
14:44
Arbeitsleben einsteigst. Also in diesen wirtschaftlichen
14:47
Kontext ne hast du das Gefühl so wird programmiert, das ist diese
14:52
Art von Programmierung die angestrebt wird, das ist
14:54
unbedingt wichtig, dass ich das kann, ne und das ist vielleicht
14:59
schon n bisschen problematisch, weil angenommen.
15:01
Du drückst dir das so drauf, dass du alles immer komplett
15:04
ausoptimierst, ne? Dann, dann hast du irgendwann
15:07
tatsächlich n Problem in im wirtschaftlichen Kontext, weil
15:12
dann kommt es nämlich genau zu diesem Problem, die du
15:14
eigentlich gerade beschrieben hast.
15:15
Du musstest die backen, du vielleicht schnalzt es nicht,
15:18
was da genau passiert, also andere Schnallst nicht du
15:21
vielleicht selber irgendwann auch nicht mehr nach einer
15:23
gewissen Zeit und das ist halt einfach am Ende verbrennst du da
15:27
ne Menge an Geld. Ne, wenn du diesen diesen
15:30
zeitlichen Overhead hast, weil du erstmal angefangen hast.
15:33
Clevere, also clevere Lösungen zu schaffen, ne, so wie gesagt
15:36
ist ja nicht immer Schlimmes, hilft ja auch in diesen
15:39
Plattformen das zu machen, einfach um sag ich mal zu
15:44
trainieren um um überhaupt das Verständnis dafür zu kriegen,
15:47
was ist denn möglich, was geht denn so heißt aber noch lange
15:50
nicht, dass man dann auch wirklich unbedingt so coden muss
15:53
um halt eben nen guten Code zu haben, der halt eben auch
15:55
wartbar und verständlich ist. Ne?
15:58
Weil oft ist das ganze ja auch so n bisschen ego getrieben ne
16:01
und das finde ich halt auch schwierig.
16:03
Angenommen du zeigst ne Lösung oder so und dann siehst du halt
16:08
danach die Lösung zu One Liner oder so, dann denkst du so also
16:12
erstmal kannst dich selbst so n bisschen runterziehen,
16:14
vielleicht sogar n bisschen so das imposter Syndrom ankicken
16:17
ja, aber andererseits denke ich mir so warum kommen Leute um die
16:21
Ecke und sagen ja ich hab es aber in One Liner gemacht.
16:24
Das ist ja irgendwie auch so n Ego getriebenes Ding, so nach
16:26
dem Motto Ich kann das, ich kann damit beeindrucken ne also ich
16:29
hab das geschrieben um Leute zu beeindrucken oder vermeintlich
16:33
oder hoffentlich zu beeindrucken so das muss ja die Intention
16:35
dahinter sein und kauf mir aber dadurch dieses Unverständnis,
16:40
also im Team ein oder beziehungsweise auch das oftmals
16:44
der Test sag ich schon, darauf will ich hinaus der Code.
16:48
Schwer testbar wird ne, also so One Liner Abzutesten, die
16:52
oftmals dann auch nicht mehr modular sind, dann weißt du gar
16:54
nicht wie du die Testfälle dafür richtig erzeugen kannst.
16:57
Wie du überhaupt es schaffst das vernünftig abzutesten.
16:59
Ja, und das finde ich halt super problematisch dabei.
17:04
Ich hatte also ich hatte auch n Fall, ich glaub das hatte ich
17:06
auch mal in einer in einer Folge erwähnt.
17:08
Da hat ein alter Kollege von mir auch ein Modul geschrieben im
17:13
Frontend, da ging es um so Tabellen und in diese Tabellen
17:16
konnten verschiedene Daten rein, also zum Beispiel ein String,
17:20
also ein String. Jetzt aber zum Beispiel ein
17:22
Datum oder so, also wirklich ein String oder ein Daten, die einen
17:27
gewissen Kontext beinhalten, und da konntest du eine Menge
17:32
Reinschmeißen und du konntest aber jede.
17:36
Tabelle egal was für n Datentyp du für diese Spalte Reingegeben
17:40
hast, konntest du sortieren nach Größe so und damit man das jetzt
17:45
nicht tausendmal wieder machen muss und sagen muss, ja komm
17:48
ich, wenn dieser Datentyp da ist, müssen wir es so sortieren,
17:51
wenn dieser Datentyp da ist, müssen wir es so sortieren,
17:53
wurde halt ne sehr sehr allgemeine Komponente
17:55
geschrieben die egal was reinkam es irgendwie geschafft hat das
17:59
zu sortieren, so wie es gewünscht war.
18:03
Und an sich ist das ja auch erstmal gut.
18:05
Also es ist ja, klingt ja auch erstmal sinnvoll, das zu machen,
18:08
weil es ja auch dann, du kannst halt alles reinschmeißen, du
18:12
kannst es super entspannt verwenden, diese Komponente nur
18:14
wie ich meinte, es wird irgendwie sortiert, das war halt
18:18
tatsächlich so, es wurde irgendwie keine Ahnung, ich
18:20
wusste nicht wie, also wir mussten das dann erweitern und
18:23
da kam es dann zum Problem, habe ich mit einem anderen Kollegen
18:26
haben wir zu zweit versucht das zu erweitern oder anzupassen,
18:30
diese Komponente und das war. Echt richtig, richtig schwierig
18:34
also da haben wir glaub ich erstmal ne schon ne große Zeit
18:38
rein investiert um zu verstehen was da passiert um es dann
18:41
hinterher anzupassen und das ist genau der Punkt so.
18:44
Das ist ja bei manchen auch n Grund solchen Kurs zu schreiben.
18:48
Ne, das hab ich auch schon öfter gehört, dass es ne Art
18:50
jobsicherung ist und das find ich ist halt völlig der falsche
18:53
Ansatz zu sagen ich schreib mit absichtlich so komplizierte
18:57
Komponenten oder Module, damit nur ich als Autor dahinter.
19:02
Das noch verstehe ja also, dass ich quasi nicht ersetzbar bin am
19:08
Ende. Aber was ist, wenn du jetzt
19:10
wochenlang daran nicht arbeitest und drauf guckst und einer von
19:12
dem bist, der es nicht versteht, dann hast du ja dir zweimal ins
19:16
Knie geschossen, aber wie sagt man also das ist ja einmalig
19:21
gut, zweimal ins Knie schießen, auf gar keine, nicht gut, nicht
19:24
gut. Weil also Fakt ist ja einfach,
19:27
dass du halt, sag ich mal, in der Industrie, also wenn du
19:30
wirklich produktive Software entwickelst oder professionelle,
19:34
dann ist der Fokus immer auf Wartbarkeit, auf
19:37
Verständlichkeit, ne und Skalierbarkeit.
19:40
Das ist das sind so die Punkte die Gold wert sind am Ende und
19:44
nicht ja die Software ist an sich nicht so geil, aber Modul
19:47
XY der Teil da drin ist schon richtig clever geschrieben, das
19:51
sieht doch am Ende der Kunde eh nicht meistens ja richtig.
19:55
Ja, ich mein, bringt dir denn so n kryptischer Code gar nichts am
19:58
Ende? Nee, dem musst du dann 1000
20:00
Jahre lang eventuell noch debuggen, damit du verstehst ne,
20:03
was wir gerade gesagt haben, dazu hatte ich auch mal n ganz
20:05
lustiges Zitat gelesen und zwar von Brian Kerninghan und da geht
20:10
es im Kern darum, dass den Code zu debuggen eigentlich doppelt
20:14
so schwer ist oder doppelt so anstrengend, sag ich jetzt mal,
20:17
als wenn man den Code schreibt. Wenn du jetzt n super cleveren
20:20
Code schreibst, also wo du wirklich.
20:23
Alles Rausgepresst hast aus deinem Hirn.
20:26
Wie willst du diesen Code dann noch debuggen können, wenn es
20:28
halt noch doppelt so schwer ist? Ne, also ist dann irgendwie
20:31
nicht möglich, deswegen immer schön entspannten Code
20:34
schreiben, den man zur Not auch noch mal debuggen kann, ne?
20:37
Lassen somit die Backen. Nee, aber ich find das Zitat
20:39
auch extrem passend, weil es ist einfach so, wenn du Wochen
20:43
später denn drauf schaust, musst du halt gefühlt noch mehr
20:46
Aufwand reinstecken um ihn die backen zu können, um ihn
20:49
überhaupt wieder verstehen zu können und Fehler da drin zu
20:51
finden als in dem Moment wo du ihn geschrieben hast.
20:53
Also ich find das super zutreffend, ich mag das sehr,
20:55
das Zitat vor. Allem find ich auch wenn man
20:58
jetzt das Ganze noch mal n bisschen, wenn man jetzt da noch
21:00
mal n bisschen weiter geht. Merkt man eigentlich auch, wie
21:03
wichtig Code Reviews eigentlich sind, also was dahinter steckt
21:07
weißt du, weil wenn du jetzt zum Beispiel also debacken ist für
21:11
mich so n bisschen sowas wie ne du bist n kleiner Sheriff und du
21:15
guckst was für Probleme da ne wo wo die wo die Crimes versteckt
21:21
sind sozusagen. Und wenn du jetzt aber n Code
21:24
Review machst machst du im Endeffekt so n bisschen sowas
21:27
wie OK du hast so diese Prämisse, dass du sagst.
21:30
Es ist jetzt vielleicht kein Bug an sich erstmal mehr drin, davon
21:34
kann man vielleicht ausgehen. Ja, du checkst ja trotzdem, ob
21:37
du irgendwas findest, was vielleicht nicht ganz hinhaut
21:40
oder wo man vielleicht noch was optimieren kann und so, aber das
21:43
halt ohne die Bagger und ohne dass du im Normalfall den Code
21:46
ausführst. Ne.
21:46
Also wenn du jetzt einfach nur sagst, ey lass mal über die Divs
21:49
gucken, ne und deswegen ist es halt.
21:53
Wirklich wichtig und auch ne wirklich ne spannende Aufgabe.
21:57
Auch n richtiges Code Review zu machen und nicht einfach nur mal
22:00
drüber zu fliegen und sagen ja passt schon passt schon, passt
22:01
schon ne. Also das noch mal am Rande ja
22:03
aber zu Code Reviews haben wir auch schon mal ne Folge gemacht
22:07
also wer hat Interesse? N super wichtiges Thema, gerade
22:12
weil du halt dadurch n Feedback kriegst, ob dein Code den du
22:16
geschrieben hast, verständlich ist.
22:17
Ne, weil wie heißt das so schön? Klarer Code muss kein
22:20
Zufallsprodukt sein, du kannst gibt halt Methoden, Mittel und
22:23
Wege einfach zu einem klaren Code und zu einer guten Software
22:28
zu kommen und da 10 Reviews halt absolut mit rein, ne genauso wie
22:32
ne gute Planung wie du am Anfang meintest.
22:35
Ja wenn du jetzt natürlich. Sofort in die Richtung cleverer
22:38
Code denkst und dir überlegst, wie du im im kleinsten Detail im
22:42
wenigsten wenig Zeilen wie möglich irgendwie diesen Code
22:45
schreiben möchtest, um so ein kleines Problem zu lösen, dann
22:48
hat das Halt nicht viel mit Planung zu tun.
22:50
Das ist halt einfach Perfektionismus am Ende im
22:53
negativen Sinne meiner Meinung nach, sondern Planung, wie
22:56
integriert sich das in die Gesamtsoftware ja, also wie
22:59
sieht meine Struktur aus, ist die nachhaltig, muss ich was
23:02
refactern das sind ja alles. Punkte, die dann als Ergebnis
23:07
haben sauber zu coden. Ja, dass du halt sagst, ich
23:10
Teile zum Beispiel in kleine, logisch getrennte Codeabschnitte
23:13
oder Module auf ja Klassen von mir aus ja, wo auch immer wir
23:17
uns gerade bewegen oder oder ich definiere wirklich ne saubere
23:20
Schnittstelle zwischen Modulen, das sind alles so Punkte, die
23:24
reichlich überlegt werden müssen und da sitzt nachher.
23:28
Die eigentliche Cleverness sage ich mal zu sagen.
23:31
Wenn du das gut meisterst, dass wie gesagt der Code am Ende
23:34
langweilig aussieht, wie wir es ja eingangs erwähnt hatten, was
23:37
quasi n Ziel ist, was man erreichen möchte, wenn der Code
23:40
wirklich so auf den ersten Blick so, ja ist nichts Besonderes
23:44
drin, dann ist es wahrscheinlich gut gecoded ja genau, und das
23:47
ist das eigentliche Ziel dahinter, ne was man nie
23:50
vergessen sollte, sind natürlich auch die Tests dahinter, die
23:54
auch immer dafür sorgen, um auch zum Beispiel auch.
23:58
Gutem Code mögliche Bugs vorzuenthalten, weil wie gesagt
24:02
die Backen nervt, aber an der Stelle sei noch mal gesagt, dass
24:06
es natürlich auch wichtig ist und dass es hier auch ne Sache,
24:10
strukturplanung, vielleicht auch refactoring.
24:13
Auch in puncto Tests, weil es ist natürlich auch wichtig, dass
24:16
jetzt nicht zu viele Tests da sind, sondern halt wirklich
24:19
fokussierte Tests, also die wichtigen Tests.
24:21
Also du kannst so viele Tests schreiben, die am Ende belanglos
24:24
sind oder nicht wirklich das Abtesten worum es geht, hat man
24:28
auch selber schon erlebt, habe ich auch schon erlebt, habe auch
24:31
schon mal ein Test geschrieben, wo ich mir irgendwann dachte, so
24:33
eigentlich brauche ich den gar nicht, sondern dass man halt
24:36
wirklich die Basisszenarien halt eben ab testet, testet und
24:40
vielleicht dann noch die Edge Cases.
24:43
Ja, genau, das ist ein sehr guter Punkt.
24:46
Also es geht ja nicht nur darum, die die eigentliche Software,
24:49
den eigentlichen Code sauber zu halten und auch zu refactern,
24:52
sondern natürlich genauso dein Test Framework dahinter, was
24:55
mindestens genauso viel Aufmerksamkeit braucht um
24:59
einfach auch eine wirklich gute Testabdeckung am Ende bieten zu
25:02
können, ganz klar, aber dann lass uns, wir haben es ja jetzt
25:06
schon mal so ein bisschen gesagt, dass so.
25:09
Klarer, verständlicher Code, kein Zufallsprodukt sein muss.
25:12
Aber warum ist es denn am Ende aus deiner Sicht schwieriger,
25:17
das zu erreichen und eigentlich erstrebenswert oder die
25:19
Eigentliche, das eigentliche, was Applaus geben sollte, wenn
25:23
jemand schafft wirklich seine Software klar strukturiert zu
25:26
entwickeln und auch gut verständlich.
25:30
Na ja, also du hattest ja auch schon mal gesagt, Planung
25:32
beispielsweise, du musst das Ganze auch im Team normalerweise
25:36
abstimmen, weil du ja auch oft halt eben im Team arbeitest.
25:39
Und es kommt unter Umständen auch noch mal zu zusätzlicher
25:42
Dokumentation. Das ist jetzt auch wieder so ein
25:45
Punkt, ne, weil gerade jetzt, wenn es jetzt zum Beispiel um
25:47
Doku geht, ist es halt immer eine Frage, auf welcher Ebene
25:50
wird dokumentiert, was ich oder wo ich die Erfahrung gemacht
25:53
habe, ist, dass es durchaus hilfreich ist.
25:56
Manchmal also angenommen, du bist an einem bestimmten Punkt,
25:59
wo du Code schreibst und du dir denkst, mache ich es jetzt auf
26:02
die eine Weise oder mache ich es auf die andere Weise?
26:05
Ich weiß es nicht genau, dann fängst du an mit vielleicht noch
26:08
einem Kollegen oder einer Kollegin darüber zu diskutieren,
26:11
wie wollen wir es denn jetzt genau machen, A oder b.
26:14
Und dann entscheidet man sich im Normalfall irgendwann vielleicht
26:18
noch nach einem Handel mit dem gesamten Team für sagen wir mal
26:21
B. Und ich hab aber schon so oft
26:23
gehabt, dass du irgendwann an den Punkt kommst.
26:25
N halbes Jahr später, n Jahr später, wann auch immer, dass du
26:28
dir denkst, warum haben wir b genommen, warum haben wir nicht
26:31
a genommen, ich weiß, kennst du das, dass du dann sagst, so,
26:35
also vielleicht ist es sogar alles wieder gechallend genau,
26:37
vielleicht kommt n neuer Kollege rein oder was auch immer und
26:39
dann klar, neuer Kollege, neue Kollegin, neuer Wind, absolut
26:45
ne, man soll ja auch neue Ideen mit reinbringen, das ist ne
26:47
klare Sache was ich meine ist, dass man auch durchaus in diesem
26:51
Beispiel was ich gerade. Erwähnt habe auch oftmals an den
26:54
Punkt kommt, dass irgendjemand das Challengen sagt.
26:56
Wieso, wieso haben wir nicht a genommen, was war?
26:58
NA jetzt das Problem, wir können doch mal A ausprobieren und ich
27:02
weiß nicht ob du dich auch schon mal auf so n Experiment
27:04
eingelassen hast, wo man dann sagt ja komm wir probieren noch
27:06
mal a. Eigentlich hast du recht
27:07
wirklich gute überzeugende Argumente, man probiert A ist
27:11
irgendwann an dem Punkt wo man sagt und deswegen haben wir
27:14
nicht a genommen so was ja. Und.
27:19
Manchmal muss man durch den Paint noch mal durch und das ist
27:22
halt so bescheuert und deswegen das mein ich mit Dokumentation,
27:25
dass man sich an solchen Scheidewegen halt wirklich mal
27:27
überlegt, welche also warum haben wir uns für B entschieden
27:31
und das zu dokumentieren um hinterher wirklich noch mal
27:33
schneller abrufen zu können, ohne diesen Exkurs noch mal zu a
27:37
zu machen zu sagen, ja gut, das waren die Gründe und die
27:40
Situation hat sich nicht mehr geändert, b bleibt so wie es
27:43
ist. Ja, das ist n guter Punkt und
27:46
auch genau der Richtige, oder? Der richtige Scope, um zu
27:50
dokumentieren weil nehmen wir jetzt noch mal die Kehrseite,
27:54
wenn ich quasi jede Zeile Code anfange zu dokumentieren, und
27:59
das hatte ich auch schon in Projekten, wo es so von höherer
28:02
Ebene quasi gewollt war zu sagen, Nein, ihr müsst euren
28:05
Code dokumentieren, wo ich mir so denke, na warte mal.
28:08
Aber wenn ich jede Zeile Code irgendwann dokumentiere, dann
28:11
ist mein Code einfach nicht gut, das würde, da würde ich mir ja
28:13
selbst eingestehen, dass ich es nicht gut programmiert habe,
28:16
weil es ja anscheinend nicht verständlich ist.
28:18
Und das ist halt auch n Thema. Warum klarer Code auch
28:22
schwieriger ist, weil dein Ziel muss ja sein, dass jede Zeile
28:26
Code so klar und nachvollziehbar ist.
28:29
Ja, und so quasi wie hattest du mal gesagt, seine eigene
28:32
Geschichte erzählt, dass du genau weißt.
28:34
Diese Zeile macht das so. Ja, und das finde ich ist ja so
28:39
n Punkt Lesbarkeit einfach. Der super entscheidend ist.
28:42
Und wenn ich jetzt anfange meinen cleveren Code auszupacken
28:45
und schreib da drüber hier in dieser Zeile passiert jetzt und
28:48
dann hab ich so 10 Zeilen Kommentar, weil das halt so n
28:50
One Liner ist, wo einfach 1000 Sachen passiert da, da wird sich
28:54
nie jemand mit beschäftigen mit dem Code weißt du, dann ist das
28:56
so blöd gesagt gottgegeben so ja also das ist ne Blackbox jetzt,
29:01
diese eine Zeile ist schon ne Blackbox und die werd ich
29:03
niemals anrühren ich werd jetzt einfach hinnehmen was da
29:06
passiert und hoffen dass es funktioniert so.
29:09
Ja, und das ist halt einfach nie n guter Weg um zu sagen, im Team
29:13
wollen wir jetzt klar klaren Code schreiben, gute Software
29:16
entwickeln, dann ist das auf jeden Fall nicht das Wahl der
29:20
Mitte. Nee, das Mittel der Wahl so rum
29:21
ne. Aber man weiß.
29:24
Was ich meine, ich weiß es aber. Manchmal hast also manchmal hat
29:27
man ja, also man kommt ja nicht immer drumherum, ne, also gerade
29:30
wenn es jetzt um Dokumentationen über Kommentare geht, im Code
29:34
beispielsweise, das war ja jetzt so n bisschen dein Beispiel,
29:37
denn. Kommt man ja nicht.
29:38
Vielleicht nicht immer drum rum, also komplett auf Kommentare zu
29:42
verzichten und wie gesagt, manchmal ist es ja auch völlig
29:45
in Ordnung, ne also wenn du jetzt irgendwas hast wo du sagst
29:48
so Boah ey keine Ahnung, das ist halt einfach so, nimm es hin, es
29:54
ist jetzt leider Anforderung was irgendwie sowas, dann kommt man
29:59
ja auch nicht immer drumherum, dann ist es auch in Ordnung,
30:01
ansonsten ist es natürlich immer schön wenn Code irgendwie
30:04
selbsterklärend ist, vielleicht auch sogar noch mit.
30:09
Ich sag mal der Unterstützung der Tests zum Beispiel.
30:12
Das ist meine Erfahrung, dass das eine gute Sache sein kann.
30:15
Das ist auch eine gute Überleitung, weil ich meinte, am
30:17
Anfang erinnere mich noch mal dran.
30:18
Jetzt habe ich mich so ein bisschen selbst gedanklich daran
30:20
erinnert. Und zwar gibt es natürlich auch
30:22
Fälle, wie Du meinst, wo man kommentieren muss und es gibt
30:24
Fälle, wo auch einfach mal cleverer Code ich muss, man
30:29
sieht die Anführungszeichen nicht mehr, aber so dieser
30:32
clevere Code in Anführungszeichen auch mal
30:33
notwendig ist. Ja, wo ich halt wirklich mal
30:35
sage, ich muss jetzt richtig viel Hirn und.
30:37
Schmalz in so n Algorithmus reinpacken und der ist einfach
30:40
komplex. Das ist jetzt vielleicht auch
30:41
irgendwas mathematisches, dass irgendwas kompliziertes
30:44
berechnet wird, was einfach nicht jeder checkt, der da nicht
30:47
drin steckt in diesem Thema. Ne und das ist ja auch völlig OK
30:50
und manchmal passiert das einfach und dann gibt es halt so
30:54
n paar Best practices würde ich sagen.
30:58
Um einfach das gut in einer Gesamtsoftware oder in einem
31:01
Projekt einzugliedern, sag ich mal, dass du quasi dir dessen
31:05
bewusst bist, dass das jetzt so ne Art Code ist, sag ich mal und
31:10
einfach kommentieren musst du nicht.
31:12
Halt gucken, guck weg, ja genau, guck weg ja, aber Dokument also
31:16
dokumentierung ist halt im Prinzip schon genau das
31:18
Stichwort, ne wenn das notwendig ist, dann dokumentiere es gut,
31:23
Versuch zu erklären was. Schnittstellen sind ja also,
31:27
weil ich ja vorhin meinte, das war für ne Library, das ist auch
31:30
im Prinzip so geblieben. Es war aufwendig, denn das zu
31:33
debuggen oder oder zu erweitern, ja, aber diese Library wurde ja
31:37
quasi auch dementsprechend verwendet und die Schnittstellen
31:40
waren halt klar dokumentiert, was ist Input und Output?
31:43
Ja, und das hilft ja den Entwicklern beim Verwenden, die
31:46
Sagen ist mir egal wie der Algorithmus oder die Berechnung
31:49
da drunter aussieht, ich brauch aber einfach diese Berechnung,
31:52
ich brauch den Wert dahinter bei den und den Eingang und.
31:55
Das ist halt genau der Punkt, dass du sagst, OK, wenn ich
31:58
sowas mache, kann ich es Kapseln zum Beispiel mit einer klaren
32:02
Schnittstelle, die gut dokumentiert ist, dann ist das
32:05
legitim. Und was du meintest, da hab ich
32:07
auch noch was Witziges gefunden, das kannte ich auch nicht.
32:10
Es gibt so diesen Mythos, kann man es nicht sagen, aber so so n
32:13
fast schon so n meme, dass man einen Kommentar hier be Dragons
32:18
ranpackt und da hab ich mich fast totgelacht, weil ich das
32:20
witzig finde, dass das so etabliert ist, dass man so
32:23
sinngemäß. Ja, also so sinngemäß OK, pass
32:28
auf das, was du dir hier anguckst ist gefährliches
32:31
Gebiet. Ja, also hier können Drachen
32:32
sein, so ne stell dir keine Fragen, nimm es am besten genau,
32:37
stell keine Fragen, nimm es einfach so hin, wenn du den Weg
32:40
gehst es verstehen zu wollen und ändern zu wollen, dann wird es
32:43
hier richtig gefährlich so oder das ist so das Meme dahinter ja
32:48
der hier be Dragons Kommentar fand ich auf jeden Fall super
32:51
witzig, muss ich auch irgendwann mal einbauen, ich muss jetzt
32:53
irgendwo so ne so ne. Codezeilen schreiben, nur damit
32:55
ich diesen Kommentar setzen kann.
32:57
Welches Level brauche ich um diese Drachen zu besiegen?
33:01
Ja genau, ah das ist das ist echt witzig, also das kannte ich
33:04
auch noch nicht, dann auf jeden Fall danke fürs Teilen, also
33:07
Liebe zur lieber zurer sag uns mal ob du das kennst.
33:09
Also das würde mich jetzt mal interessieren, weil wir immer
33:12
Hass einen Kommentar schon mal verwenden genau also
33:16
zusammengefasst wenn ich sowas mache.
33:18
Versuchen das zu Kapseln, zum Beispiel in einer Bibliothek mit
33:21
einem klaren Interface, was dokumentiert ist.
33:23
Und dann halt der hier be Dragons Kommentar ran damit also
33:26
im Code ne sobald einer da reinschaut sich denkt ah OK
33:29
falsche Richtung hier ab umdrehen und zurück das ist
33:33
natürlich das ganze gut abtesten ne wie du vorhin meintest man
33:36
muss natürlich auch gewährleisten, dass es
33:38
funktioniert, immer wichtig ja aber wenn wir jetzt mal also ne
33:42
das sind ja jetzt so die ganzen Sachen die wir jetzt besprochen
33:45
haben, da kann man natürlich sich jetzt hinstellen und sagen
33:47
Boah. OK, angenommen ich bin jetzt
33:50
irgendwie noch nicht so weit oder was auch immer.
33:53
Wie was ist denn jetzt sozusagen der Weg um zu sagen, OK, was
33:56
soll ich denn jetzt machen, soll ich jetzt mich hinstellen und
33:59
bei Code wars beispielsweise einfach sagen, ja gut, dann
34:01
programmier ich halt immer nur irgendwelche stumpfen
34:04
Algorithmen, die sag ich jetzt mal einem sofort einfallen, ich
34:09
brauch eigentlich gar nichts mehr zu optimieren, weil ist ja
34:13
wahrscheinlich eh dann nur in Anführungsstrichen der clevere
34:15
Code den ich mir hier aus den Fingern drücke.
34:18
Sagt man so aus den Fingern, drückt also, wie geht man denn
34:22
jetzt am schönsten damit um? Was weißt du, das ist doch jetzt
34:26
eigentlich mal ne ganz gute Frage, um so langsam zum Ende zu
34:30
kommen vielleicht. Also so noch n Take away oder
34:33
was? Ja.
34:34
Zum Beispiel. Also ich hatte jetzt so n
34:37
bisschen daran gedacht, dass, wie wir auch schon gesagt haben,
34:40
ne bei Code wars, es ist ja hilfreich auch mal sag ich jetzt
34:45
mal diese. Challenge auf sich zu nehmen und
34:47
zu sagen, ganz bewusst, jetzt versuche ich das ganze mal
34:50
wirklich richtig hochoptimiert zu machen oder mit einem One
34:54
Liner, so dass es halt möglichst wenig Code ist.
34:56
Du kannst dir ja selber eigene Challenges setzen und zu sagen,
34:59
ich versuche diese Aufgabe jetzt mal so oder so oder so zu
35:02
machen, performant möglichst wenig Code heißt ja nicht immer,
35:05
dass es gleich performant ist oder halt vielleicht auch
35:08
einfach. Über eine ganz ausgefallene
35:10
Variante, so was auch immer so Versuch mal einen anderen
35:13
wegzunehmen als der, der dir sofort eingefallen ist.
35:15
Irgendwie sowas, und das sind ja auch Sachen wo du was dazu
35:18
lernst, wo du sagst, ey, das ist ja vielleicht noch mal, da habe
35:21
ich noch mal eine neue Gehirnbindung dazu bekommen, so
35:24
nach dem Motto und sowas hilft ja auch und gleichzeitig würde
35:28
ich sagen zu gucken wo, wie schreibe ich denn zum Beispiel
35:35
Code, sodass ich mir irgendwann mal.
35:38
Also mit dem Gedanken, wenn ich mir das jetzt zum Beispiel in 3
35:41
Wochen angucke, wenn ich mir das in einem Monat angucke oder wenn
35:44
ich es mir in einem halben Jahr angucke, verstehe ich das immer
35:47
noch so, vielleicht diesen Hintergedanken zu haben, dass du
35:51
verschiedene Möglichkeiten hast, Code zu schreiben.
35:53
Und gerade wenn du in einem produktiven Umfeld bist,
35:55
wirklich zu sagen, okay, es muss nicht mega clever sein, es
35:59
sollte guter Code sein, aber es sollte kein hochoptimierter Code
36:04
sein, den man selber irgendwann nicht mehr versteht so.
36:07
Das sind ja zum Beispiel so Mögliche.
36:09
Also so könnte ich es mir vorstellen, dass man diese
36:13
Herangehensweise nutzt, egal an welchem Level man ist.
36:16
Zum Beispiel ne. Es ist ja auch n guter Punkt so
36:19
ne Challenge zu machen und zu sagen, ich schreib jetzt so
36:22
hochkomplexen Code oder komplex nicht mal unbedingt komplex,
36:25
sondern so. Ja clever ist immer schon das
36:28
richtige Wort ne und ich zwing mich das zu machen um einfach
36:32
auch später wirklich erkennen zu können.
36:34
Was ist jetzt einfach nur cleverer Code und so n bisschen
36:36
ego gepusht oder was ist halt wirklich guter Code am Ende und
36:40
das ist halt auch essentiell zu sagen ich muss auch die
36:43
Erfahrung sammeln und versuchen sowas zu schreiben um später
36:45
einfach erkennen zu können ob ich wieder in diese Richtung
36:48
gerutscht bin oder vielleicht doch.
36:49
Noch auf dem richtigen Weg bin und wie gesagt das Zitat was du
36:53
vorhin meintest, das immer im Hinterkopf zu haben, ich muss
36:57
eigentlich per Definition irgendwann diesen Code debuggen,
36:59
irgendwann kommt der Tag wo ich mir das wieder angucken muss und
37:02
dann wird es doppelt so schwer sein wie in dem Moment wo ich
37:05
gerade locker flockig die Knöpfe drücke und den Code schreibe und
37:09
deswegen ist Klarheit. Quasi nicht nice to have so.
37:14
Naja, wäre schon cool, wenn man es so schnell verstehen könnte,
37:16
sondern es ist halt Pflicht, einfach weil du wirst auch
37:18
wieder in der Situation sein es verstehen zu müssen.
37:22
Ja wie war das mal? Code wird von Maschinen
37:25
ausgeführt, aber wird von Menschen gelesen so und deswegen
37:29
muss der Code auch lesbar sein, so bitte da haben wir es doch so
37:33
hätten wir doch die ganze Folge zusammenfassen können, direkt
37:36
eingangs nee, aber was wäre ein Einzeiler?
37:41
Genau. Aber was ich halt zum Beispiel
37:44
auch noch ganz interessant find ist, dass man auch gerade um
37:48
vielleicht auch guten Code zu schreiben, sich auch vielleicht
37:52
mal sagen kann, ich nehm mir jetzt so ne Art, so ne Art
37:55
guideline. Woran ich mich wirklich mal n
37:58
lang hangel, die kann sich ja auch entwickeln, ne, aber dass
38:00
man immer mal so n gewissen Abschnitt hat wo man sagt ich
38:02
ich folge jetzt einem Guide den ich mir vielleicht selber
38:05
auferlegt hab, nur mal als Beispiel also es geht jetzt um
38:07
Übung ne um dann zum Beispiel zu sagen OK ich zieh das jetzt mal
38:10
wirklich so durch und dann kann man ja auch mal evaluieren.
38:13
Ist es n ne gute n guter Guide den ich mir da überlegt habe.
38:17
Kannst dich auch austauschen mit anderen weißt du aber, dass du
38:19
und das hab ich auch ehrlich gesagt noch nie so krass
38:21
gemacht, dass ich wirklich mal gesagt hab, es gibt so ne
38:24
richtigen so n richtigen Guideline, zum Beispiel sowas
38:26
wie auch ey ich mach jetzt n Pfeil da, da kommen jetzt zum
38:29
Beispiel nicht 500 Zeilen Code rein, sondern es ist auf jeden
38:32
Fall, wenn es über die diese Anzahl von Lines of Code
38:36
hinausgeht, dann muss irgendwie die Business Logik da getrennt
38:39
werden oder so ne Sache weißt du.
38:41
Dann so mit statischen Analysen. Nee, aber weißt du, dass man
38:45
vielleicht auch so ein bisschen Erfahrung halt eben sammelt und
38:48
genauso zum Beispiel auch, was immer hilft, ist, dass wirklich
38:51
auch erfahrene Entwickler und Entwicklerinnen auch mal Reviews
38:55
vom eigenen Code machen, also dass man irgendwie auch mal sich
38:57
so was einholt und ich weiß nicht, da kann man sich auch mal
39:02
überlegen, ob zum Beispiel lieber zurer, wenn du mal Code
39:05
hast, wo man mal ein Feedback haben möchte, dann lass uns das
39:09
gerne mal auch auf der Podcast Mail zukommen.
39:12
Und wir können uns das zum Beispiel auch mal mit allen, die
39:14
auch oft bei Twitch zum Beispiel dabei sind, auch insgesamt mal
39:17
angucken. Dann können wir vielleicht ja
39:19
auch mal ein gewisses Feedback darüber geben, um einfach mal
39:22
auch ein Learning für dich zu generieren.
39:24
Genau. Ansonsten haben wir ja das
39:25
Rescue The Code Format noch, wo wir so freie Reviews in
39:29
regelmäßigen Abständen verlosen und dann halt auch Reviewen und
39:33
Feedback dazu geben, dass wir dann auch eine sehr gute
39:35
Anlaufstelle dafür ja. Cooles Thema gewesen, liebe
39:41
Zuhörer, liebe Zuhörer, du kannst ja auch dir mal ne
39:43
Challenge stellen. Hast du denn schon mal versucht,
39:46
deinen eigenen Code, wenn wir schon beim Thema sind oder den
39:49
du uns vielleicht zukommen lassen möchtest, nach langer
39:51
Zeit noch mal versucht zu lesen? Und wie waren da so deine
39:54
Erfahrungen, hast du ihn noch verstanden, wenn nicht, dann
39:58
willkommen im Club, das kennen wir, das Gefühl aber das ist auf
40:02
jeden Fall immer n sehr cooles Experiment zu sagen, ey ich
40:05
schau jetzt einfach mal so in alte.
40:07
Programmierung von mir rein und guck mal was ich daraus ziehen
40:10
kann. Ja und dann kommt man
40:12
wahrscheinlich relativ schnell zu dem Code, zu dem Code genau,
40:15
man kommt schnell zum Code, nein man kommt schnell zu richtig zu
40:17
dem Schluss, dass es durchaus sinnvoll ist lesbaren Code ne
40:23
höhere Priorität einzuräumen, als dass der Code jetzt
40:26
unbedingt clever sein muss ne also selbst wenn du schon
40:29
vielleicht auch schon fortgeschrittener bist in der
40:32
Entwicklung und nicht gerade am Anfang stehst oder dir Code vom
40:34
ganz am Anfang holst, sondern vielleicht auch Code von.
40:37
Sag ich mal schon erfahren deinem erfahreneren ich so.
40:41
Also ich kann mir vorstellen, dass ich mir auch mal Code
40:44
nehme, wo ich mir denke, so aha, ich hab aber ganz toll dachte
40:46
ich mir super Sache Fabian, da hast du aber richtig clever
40:49
versucht einen drauf zu machen, so und dann versteht man ihn
40:53
erstmal nicht mehr. Ja in dem Sinne würde ich sagen.
40:58
War auf jeden Fall n guter Punkt.
41:00
Hast du noch? Möchtest du noch was sagen zu
41:02
diesem Thema, Tino dann mal raus, wir haben es glaube ich
41:04
ausführlich besprochen, wir sind fertig und in dem Sinne würde
41:09
ich sagen, wenn dir die Folge oder der Podcast gefällt, dann
41:12
lass auf jeden Fall mal n like da beziehungsweise ne Bewertung
41:15
das würde uns mega helfen auch und ansonsten wie gesagt.
41:22
Schreib uns auf. Entweder der Podcast Mail oder
41:25
auf unseren Social Media Kanälen kommen auch gerne in unseren
41:28
Discord. Immer herzlich Willkommen auch
41:30
für neue Gespräche und neue Anregungen und sonst würde ich
41:35
sagen, wenn du sagst bevor wir uns jetzt hier verabschieden,
41:39
den beiden möchte ich noch eine Kleine sagen wir mal etwas Gutes
41:42
tun, dann kannst du auch eine kleine Spende auf den auf den
41:45
Spenden Link uns schicken findest du alles alle Links die
41:48
ich gerade genannt habe unten in den Shownotes.
41:50
Und ansonsten hören wir uns in der nächsten Folge wieder deine
41:52
Colling bollies. Gemeinsam besser.