Und jetzt kommst du als Teammitglied und guckst dir das
an, denkst dir, was ist x was zur Hölle ist x oder ich komm 4
Wochen später und denk mir was ist XX ist 4 so weißt du.
Bowling, Bodys deinem Podcast rund um Softwareentwicklung und
aktueller Technews. Herzlich Willkommen.
Ja, herzlich Willkommen zur neuen Folge des Covid Podcasts.
Und nicht nur die neue Folge, es ist auch die 1.
Folge und Zwar hatten wir einen Jahreswechsel. 2024 und an
meiner Seite natürlich wieder der fantastische Fabi.
Moin, Moin Fabi. Hey Tino, ein frohes neues Jahr
wünsche ich dir. Das wünsche ich dir auch.
Mein schöner. Wie geht es dir alles gut?
Ja, alles super gut. Reingestartet würde ich jetzt
mal so behaupten, relativ entspannt.
Wie war es bei dir? Ja, auch tatsächlich ziemlich
entspannt. Also jetzt keine wilde Party,
eher so im Kreis der Freunde und Familie.
Aber hat mir sehr gut gefallen. Also ich bin muss auch sagen,
ich bin jetzt auch kein Mega. Fan von Silvesterpartys also,
dass ich jetzt das ganze Jahr darauf hin Fieber.
Aber es war schön, es hat Spaß gemacht, bin gut reingerutscht.
Ja, wie sah es bei dir aus? Ja, ähnlich.
Also Freunde, entspannte Runde war es, wir haben Raclette
gemacht und dann klingt es geil und dann halt um um 9 schlafen
gegangen, also. Am 1.1.
Um 9. Ja, aber ich ich find es auch
immer. Also ich find es cooler, also so
ich weiß nicht, also so viele gibt es, gibt ja viele die so
richtig heftig so Party machen zu silvester, ich hab das auch
ne Zeit lang. Also ich, was heißt gerne, ich
fand es irgendwie, ich finde es für mich hat sich
herauskristallisiert, dass ich es cooler finde, wenn man
einfach so mit Leuten zusammen feiert, die man halt weiß ich,
die man halt kennt, die man gut kennt, weißt du wo man halt.
Auch irgendwie so ein. Weiß ich nicht.
Sich gehen lassen. Nein, du weißt was.
Ich meine ja. Also ich find es halt auch
irgendwie überbewertet, da irgendwie so n mega Partyabend
draus zu machen. Also ich kennte oder ich.
Bekannte Leute, die halt auch extrem darauf aus waren.
Das muss die Nacht des Jahres werden so.
Ja, für beide, für das Alte und fürs neue Jahr.
Es ist einfach, steht alles in. China ist ja auch überall gar
kein Druck, kein Druck. Kein Druck und dann wird es am
Ende immer Scheiße damit. Dann wird es halt immer
irgendwie, dann ist die Erwartung einfach zu groß.
Findet man selbst, wenn man sich keine Erwartung macht, find ich
die Erwartung trotzdem immer. Irgendwie weiß ich nicht, also
weißt du also irgendwie selbst wenn man sich so sagt, so, es
ist ja ganz entspannt und dann denkt man sich trotzdem, ja,
aber heute, so wie Silvester und ich sag mal ganz ruhig, es ist
ja nur so alles, es ist doch nur Silvester.
Nee, also da muss ich sagen, dieses Jahr hatte ich nicht
wirklich viel Erwartung oder hatte jetzt nicht vor, dass es
sonst wie krass wird und es war halt deswegen einfach ziemlich
cool. Es hat mir sehr gut gefallen,
muss ich sagen. Das ist schön.
So ganz entspannt halt ne. Böllerst du.
Na, auf keinen Fall. Also ich meine, wir haben glaube
ich lange nicht mehr Silvester zusammen gefeiert.
Ne. Also wir haben.
Echt schon zusammen gefeiert? So ist es nicht und ich Feier
auch sehr gerne mit dir Silvester, aber es hat sich
nicht ergeben, ja. Weil du immer so hart Party
machen willst und ich halt nicht.
Du hörst mir einfach nicht zu. Nein, also das ist ja ein guter
Punkt, müssen wir auch gerne mal wieder machen.
Und zu deiner Frage mit den Böllern, das finde ich halt
richtig furchtbar und sinnlos. Ich hoffe jetzt schalten dich
die Leute aus. Und alle.
Machen aus, alle machen aus oder alle zünden erstmal irgendwie
einen Balladen. Aus Prinzip.
Also ich. Finde es also ich finde das
finde das super furchtbar ehrlich mag ich gar nicht.
Also ich finde es krass, weil ich Böller auch nicht mehr oder
lasse raketensteigen oder so. Ich habe das aber früher übelst
viel gemacht und also keine Ahnung, mein sechzehnjähriges
ich hat. Irgendwann mal von keine Ahnung,
ich sag mal den irgendwie Freunden von meinen Eltern, die
haben irgendwie gesagt sowas wie ja wir machen das so ganz
entspannt, wir laufen machen so nen kleinen Spaziergang über
00:00 Uhr und dann knallen alle und wir gucken uns das an aber
wir böllern selber nicht und ich dachte mir mit 16.
Was geht eigentlich ab? Also das geht das überhaupt?
Ist das physikalisch möglich, keine Raketen Loszustarten zu
Silvester, das fand ich voll krass, aber heute hat sich das
bei mir halt so ein bisschen gedreht, weil ich das halt
einfach irgendwie auch nicht mehr brauche.
Ja, also früher hab ich das auch gemacht und fand das natürlich
auch irgendwo cool oder so. Keine Ahnung was ich mir dabei
gedacht hab, aber mittlerweile denk ich mir so ist es halt
irgendwie halt echt auch sinnlos und vor allem denk ich da
mittlerweile auch anders drüber, gerade wenn man so Haustiere
hat, was für n Stress das für so ein Tier auslöst und das merkst
du ja extrem und da denk ich mir halt auch so, ist halt echt
unnötig. Ja gut, aber das haben ja auch
nicht alle Haustiere, ne? Nein, aber ich verstehe, ich
verstehe das, also ich finde es halt irgendwie ganz schön sich
das anzugucken, aber ich kann es auch verstehen, dass das
natürlich auch für für Tiere kann, also es ist sehr sehr
stressig auf jeden Fall. Aber im Endeffekt war es, finde
ich, um das ganze jetzt nicht daunergehen zu lassen.
Ich hatte ein ganz gutes Silvester, es war ganz entspannt
und ich sag mal so viel, ich hatte keinen Kater am nächsten
Tag und das war ganz gut. Das ging mir auch so, auch
schön, gerade in unserem Alter katert man ja doch schon mal ein
bisschen mehr. Ja genau gehe ich hier ganz mit.
War bei mir ähnlich. Und natürlich dachte ich mir
00:00 Uhr so ja schön neues Jahr, das heißt, wir können bald
wieder ne Podcast Folge aufnehmen und deswegen lass uns
mal zum heutigen Thema kommen. Ja, was haben wir denn?
Das heutige Thema ist Silvester. Nein, und zwar hatten wir ja im
letzten Jahr ne neue Reihe angefangen, und zwar die
Cleancode Reihe und wollten ja einfach mal, weil es n sehr
umfangreiches Thema ist, das n bisschen splitten auf mehrere
Folgen. Und deswegen würde ich sagen,
lass uns doch heute einfach mal die 2.
Folge zu dieser Reihe. Quasi machen, aufnehmen,
besprechen, wie auch immer und da.
Vorschlagen starten wir mal ganz entspannt mit der Namensgebung
von beispielsweise Variablen und Funktionen.
Das ist eigentlich immer n ganz cooles Einstiegsthema und klingt
vielleicht jetzt für dich, liebe Zuhörerin, liebe Zuhörer,
trivial aber ist es definitiv nicht und ist es auch nicht
meiner Meinung nach selbst für erfahrene Entwickler nicht, da
waren jetzt ganz viele nichts in diesen Sätzen, aber ich wollte
es einfach mal unterschreiben. Und deswegen fabi, was meinst
du, hätte ich Bock auf jeden Fall mal mit dir drüber zu
quatschen. Ja, auf jeden Fall.
Also das ist ein wichtiger Punkt.
Ich glaube, wir können ja erstmal damit anfangen, dass wir
gucken. Warum es überhaupt sinnvoll ist
oder wichtig ist, bei der Programmierung, bei der
Softwareentwicklung auch wirklich, sag ich jetzt mal,
sich Gedanken darüber zu machen, wie Variablennamen, wie man
diese Variablennamen oder funktionsnamen oder eigentlich
jede Art von Benahmung im Code vergibt, belegt.
Ja, das ist, das ist auf jeden Fall ein cooler Einstieg, weil
wenn man so drüber nachdenkt. Also wir haben ja in der
Eröffnungsfolge ja eigentlich so mal eingeleitet, was Cleancode
bedeutet, und da sind wir ja so auf Punkte eingegangen wie.
Wartbarkeit, Skalierbarkeit, Lesbarkeit vor allem.
Ja, und das sind ja alles Punkte, weshalb es klingt, quasi
gibt oder diese Definition und so Best Practices und da zählt
ja die Benahmung auch mit rein. Und genau aus diesen Gründen,
weil gute variablen Namen, gute Funktionen.
Uns nahm und was gut ist, können wir ja gleich mal bisschen
definieren, was so als gut gilt, sag ich mal.
Sorgen ja aber dafür, dass du zum Beispiel den Code schneller
und besser lesen kannst und besser verstehst.
Also die Verständlichkeit wird ja auch besser.
Dadurch wird er natürlich wartbarer, weil ich einfach auch
nach Wochen noch schnell weiß, was da passiert und das verstehe
und kann es halt einfach besser warten und skaliere skalierbarer
wird es auch, weil ich halt schneller beispielsweise wieder
Schnittstellen finde, wo ich denn jetzt meine Funktion
erweitern kann und da das alles gut lesbar wartbar ist, weiß ich
halt, ach ja, genau das passiert hier, das passiert da und an der
Stelle kann ich jetzt meine neue Funktionalität einbauen.
Also allein die Benahmung hilft. Dabei ja schon, das stimmt.
Nahmung, also benahmung klingt halt immer sehr trivial.
Aber. Ist es denn auch so trivial?
Nee, absolut nicht. Also meinen Augen gar nicht und
ich tue mich da auch heute immer noch schwer mit, beziehungsweise
was heißt schwer. Man kann natürlich einfach
irgendwelche Namen nehmen, aber wenn man halt auch, also ich
sage, ich sag mal so mit zunehmender Erfahrung.
Arogen wird einem bewusst, wie wichtig denn diese Benahmung ist
und deswegen versucht man im Vorfeld schon mehr Zeit da
reinzustecken, um einfach später nicht diese Probleme, die man ja
dann schon mal hatte, oder diese Erfahrungswerte, die man
gesammelt hat, später nicht zu bekommen, sondern Monate später
auf den Code guckt und sich denkt, Ach ja, ok, funktion
sowieso, die macht das alles klar okay verstehe ich was da
passiert, das ist ja so. Das wünschenswerte Ziel, sage
ich mal und nicht variable x mit Y.
Geteilt durch ZB. Dann weiß ja keiner mehr, was da
los ist. Also.
Wie soll ich sagen, also. Und wenn du die Software
schreibst oder sagen wir mal diese eine Funktion, dann bist
du voll drin im Thema und dann sagst du dir OK, ja gut, jetzt
muss ich das machen. OK das und das ich brauch mal
schnell ne Variable ja was dir gut die hält irgendein integer
irgend ne Größe beispielsweise erreicht der die nenne ich jetzt
x weil brauche ich ja nur hier und ja okay dann verwende ich x
und fertig und. Kommst du als Teammitglied und
guckst dir das an, denkst dir was ist x was zur Hölle ist x
oder ich komm 4 Wochen später und denk mir was ist XX ist 4 so
weit. Und das ist genau das Problem.
Ich find das beschreibt es halt ganz gut, weswegen so ne
Namensgebung extrem wichtig ist. Wie sind denn da so deine
Erfahrungen? Ja, also ich meine.
Man was, was ich gemerkt habe, ist dass egal.
Wenn man also wir beide haben jetzt mittlerweile schon so sind
jetzt. Relativ längere Zeit schon
erprobte Softwareentwickler in Anführungsstrichen sag ich jetzt
mal. Ich weiß nicht wie ich.
Das ja schon formuliert, wie ich das.
Jetzt ausdrücken soll. Aber wir haben ja schon einiges
programmiert, wir haben schon einiges an einigen Projekten
gearbeitet. Und ich finde, das ist natürlich
besser, wird also dadurch, dass man halt eben ein höheres,
höheren Augenmerk, höheres Augenmerk.
Ich weiß nicht, wie man das sagt, höheres Augenmerk.
Klingt super, sagen wir so das. Spotlight wenn man also, man
legt ja immer mehr, sag ich mal, schon Energie da rein bei
Überlegungen da rein, dass man sagt, Okay wie könnte eine
Funktion. Benahmt werden wie kann eine
variable benatet werden, aber nichtsdestotrotz.
Kommt es immer noch mal wieder vor, dass man sich vielleicht
irgendwie mal auf sein, auch auf seinen eigenen Code, dass man da
drauf guckt und sich denkt? Ah, warte mal.
OK was was genau passiert da noch mal ne und ich merk das
halt immer wenn ich noch mal ne Funktion hab wenn ich da noch
mal ne längere Zeit drauf gucken muss oder ne je länger ich da
drauf gucken muss desto blöder war eigentlich die Vorarbeit ob
es jetzt quasi mein Code war oder der Code von einem
Teamkollegen in dem Fall. Der aber auch andersrum.
Also das ist halt immer genau der Punkt, dass auch wenn man
jetzt eine Menge Erfahrung vielleicht schon mitgebracht
hat, es ist nie so, dass also jedenfalls nicht immer
hundertprozentig der Zeit, dass ich mir denke, okay, ich hab
sofort den perfekten Namen für was auch immer, also man muss
schon darüber nachdenken, merke ich, und das ist wirklich
unglaublich wichtig, auch darüber nachzudenken und es.
Natürlich nicht so, dass du jetzt bei jeder Funktion oder
bei jedem bei jeder variable Ewigkeiten drüber nachdenken
musst und sagen musst, boah ey, keine Ahnung, ich hab jetzt
irgendwie weiß nicht muss 10 Minuten drüber nachdenken.
Das ist nicht immer so ne. Aber.
Es gibt halt einfach schon Momente, wo man schon relativ
schnell merkt, OK, an der Stelle sollte ich vielleicht wirklich
mal darüber nachdenken. Allein wenn du schon, wenn du
diese Funktion schreibst und sagst, die soll jetzt die
Funktion soll jetzt, die soll jetzt was, die soll jetzt das
machen, aber die sagt, Na was passiert da eigentlich so weißt
du also wenn du da wirklich mal so ein bisschen.
Beim Codenummer selbst auch am Anfang.
Irgendwas hinschreibt willst du erstmal loskommen?
Du schreibst erst mal irgendwas hin und weißt aber vielleicht
noch nicht so richtig hundertprozentig okay was ist
denn der perfekte Name dafür? Dann ist es mindestens ein
Anzeichen, sich mal zu sagen okay, dann muss ich gleich noch
mal gucken. Und das ist halt genau der
Punkt. Also ich weiß, dass es besser
wird. Ich persönlich lege mehr Wert
darauf, gute Benahmungen für bestimmte Sachen, Funktion,
Variablen namens Tests, was auch immer zu geben.
Und deswegen wird es besser. Aber man merkt trotzdem immer
nochmal im Nachhinein zumindest ich, dass man da auch noch
Potential nach oben hat und dass es eben keine triviale
Angelegenheit ist, um zu sagen, das ist jetzt auf jeden Fall
das. Das ist ganz spannend, weil
vielleicht ist das unseren Zuhörern auch nicht so klar oder
vielleicht nicht allen. Das ist ja nicht so, dass man
sich hinsetzt, 5 Minuten schweigt und sich überlegt, so
okay ich hab's, wir nennen es so und so, sondern es ist ja
wirklich ein Prozess, wie du schon meintest, man schreibt was
hin, okay ja okay ja, das ist gut, nein, das lasst es lieber
so nennen, okay gut, ja okay das doch das finde ich ganz gut,
jetzt fängst du an, die Funktion zu implementieren.
Aber eigentlich so wirklich beschreibt das nicht, was da
drin passiert. Und dann baust du um, dann wird
die Funktionalität vielleicht noch ein bisschen geändert und
dann ist es ja auch wieder wichtig, diesen Funktionsnamen
anzupassen, weil vielleicht gar nicht mehr das wirklich passiert
da drin, so wie es mal ursprünglich benahmt wurde und
deswegen finde ich es geil, dass du sagst, es ist ein Prozess,
weil wenn ich quasi mal aufnehmen würde, wie das dieser
Prozess bei mir aussieht, dann schreibe ich was hin, lösch es
wieder weg, ich schreibe es wieder hin, okay finde ich gut,
lösch es weg, schreibt das erste wieder hin was ich hatte lösch
es weg, weißt du? Das das ist also, so sieht es ja
eigentlich in Realität aus, das ist ja nicht so, dass es so eine
Theoriearbeit im Kopf ist. OK, schreib ich diktiere weißt
du und der andere schreibt das hin, so läuft es ja nun auch
nicht und. Sich diese Zeit aber zudem finde
ich unfassbar wichtig und das findet man auch in vielen
Lehrbüchern zu dem Thema. Das ist halt wichtig, ist mit
den entsprechenden Argumenten auch, wie wir gesagt haben, dass
es dir einfach im Nachhinein hilft.
Ihre Software zu programmieren oder zu entwickeln, so dass man
sagen kann, dass dieser dieser erste riesenpunkt halt wirklich
ist. Verwende aussagekräftige Namen
für Funktionen, Tests, Variablen, was alles, was halt
benannt werden muss. Aussagekräftig ist auf jeden
Fall gut. Was mir auch noch mal ganz kurz
zu diesem Thema einfällt ist. Oder was?
Ich auch noch mal als Tipp vielleicht mitgeben kann, wovor
man sich nicht scheuen sollte, ist.
Tipps sind immer gut ist. Dass man zum Beispiel, also ich
kenne das selber, ich hatte das auch schon mal, dass ich dann.
Eine Funktionsnamen hatte also ich, ich mir waren.
Ich hatte so ein paar mir überlegt, keine Ahnung, 5 Stück.
Und die ich war mal mit allen noch nicht richtig zufrieden,
weil das war auch ne wertvolle Funktion für die Software, ne
und dann hab ich halt auch wirklich nen Teamkollegen
gefragt in dem alten Projekt und hab gesagt du pass auf ich hab
mir jetzt diese 5 Namen mir überlegt für diese Funktion.
Ich bin mir aber nicht sicher, welche ich nehmen soll
beziehungsweise meine Bedenken sind halt noch die und die und
die, weil ich halt eben auch nicht hundertprozentig
zufrieden, weil ich dachte mir so OK die der Funktionsname
kommt schon irgendwie hin, aber irgendwas stimmt noch nicht so
und es hat mich echt gewurmt, weil es halt wie gesagt ein
wichtiger Teil war und deswegen. Auch durchaus ratsam mal zu
sagen, OK, selbst wenn man jetzt also was ich oft genug auch
erlebt hab, war sowas wie ja dies das das dann hast du so
vielleicht diesen Prozess den du geschildert hast.
Auch der ging dann so vielleicht 3 bis 5 Minuten.
Und dann war irgendwann so, ach komm, wir lassen, wir nehmen das
jetzt erstmal so und das hab ich auch schon oft erlebt und das
sollte man vielleicht nicht unbedingt machen, also das kann
man vielleicht einmal machen, aber wenn du es einmal machst,
machst du es noch mal und dann hinterher hast du irgendwann
genau den Effekt, dass du selber oder jemand anders darauf guckt
und sich denkt, was ist denn das, dann brauchst du Zeit
dafür, um das wieder zu verstehen und.
Wegen sehr guter Punkt. Tipp würde ich sagen, auch wenn
man sich nicht sicher ist, auch noch mal wen anders fragen und
noch mal ein paar mehr Meinungen oder Ideen, zumindest Ideen
reinholen, das kann. Helfen finde ich sehr gut.
Ein sehr wertvoller Tipp, was natürlich bei solchen
Geschichten, also wenn man da hin und her überlegt, kann es ja
auch darauf hinweisen, dass es vielleicht schon eine Art
Designfehler ist, zum Beispiel bei Funktionen bzw Fehler finde
ich jetzt ein bisschen übertrieben, aber das ist
vielleicht. Cleaner geht das Ganze zu
entwickeln, aber da würde ich jetzt nicht zu sehr darauf
eingehen, weil Funktionen wie Funktion am besten aussehen oder
was so best practice es sind finde ich ist eine super
spannende extra Folge, also ein einzelnes Thema, weil da könnten
wir auch echt bestimmt ziemlich lange drüber reden.
Aber was ich da immer spannend finde, und das würde ich halt
kurz nochmal als Tipp mitgeben, wenn es mir zum Beispiel schwer
fällt, Funktionen zu benennen, kann es halt einfach sein, dass
sie auch nicht klar definiert sind, was passiert.
In dieser Funktion, oder es passiert zu viel und ich glaube,
das kennst du auch, das kenne ich, das kennt jeder, dass man
merkt, so da. Eigentlich 2 verschiedene Sachen
und wenn du dann sowas hast wie? Create or open, ja.
So was wie or or end. Das sind alles so Wörter, wenn
ich versuche oder gewillt bin das in so nen Namen einzubauen,
dann ist schon dann ist schon da was im Argen, dass da was nicht
richtig ist. Also das find ich noch so als
Tipp. Das sind so Schlüsselwörter, die
symbolisieren. Oh, das ist geht vielleicht doch
sauberer zu coden, dass man denn zum Beispiel Funktionalitäten,
Auftrennt oder Variablen auch auftritt, weil man vielleicht
versucht zu viel. Wissen oder Inhalt in eine
Variable zu packen, das klingt vielleicht erstmal n bisschen
komisch, aber an solchen Punkten kommt man halt.
Ja, wir hatten in der in der Twitch Session ganz coolen
Kommentar zu diesem Thema, weil das irgendwie glaub ich in
dieser in der einen Session auch gekommen ist.
Da hatten Zuschauer in in den Chat gepostet.
Ist die Variable zu lang, dann willst du zu viel oder irgendwie
sowas ne und ich fand den den ja stimmt, ich fand den Spruch ganz
cool, weil der ist wirklich sehr ausschlaggebend ne also wie
gesagt, ich glaube es ist. Ich nenne es mal so ne, wenn du
ne Variable hast, die viel zu lang ist, ist das blöd.
Wenn du Variablen hast die viel zu kurz sind ist das blöd und
ich glaube man muss diesen süßen Mittelweg dazwischen finden.
Weißt du, dass du sagst? Es gibt diesen Sweet Spot, der
einem sagt, Okay genau das ist, ist gut ne, also nicht zu viel,
nicht zu wenig und ich würde das Zusammenfassen unter
selbsterklärend, aber auch kurz und aussagekräftig.
Ne, also diese 2 Punkte, die sind wichtig und und und.
Das sind glaube ich gute Merkmale um zu sagen diese.
Benahmung ist ganz gut. Ne ja find auf jeden Fall super
zusammengefasst. Da würd ich aber abschließend
noch noch ein letztes Beispiel geben.
Weil du meintest zu kurz ist auch blöd, da gibt es hab ich
auch viele Entwickler schon kennengelernt, die sagen ja nee
wenn man gewöhnt man sich dran oder so Abkürzungen sind ne ganz
feine Sache. Weil Abkürzungen sind ja oft
dafür da, um Sachen zu kürzen, Variablennamen beispielsweise.
Funktionsnamen, so Abkürzung, finde ich, bin ich so ein
bisschen. Vorbelastet, weil ich mal in
einem Projekt gearbeitet hab, wo sehr massiv mit Abkürzung
gearbeitet wurde. In Funktions und Variablennamen.
Und klar kann man sagen ja, wenn man das Wissen darüber hat, dann
versteht man ja was das ist. Aber selbst ich, der täglich
quasi an der Software geschrieben hatte, wusste
irgendwann nicht mehr was beinhaltet die Variable jetzt
eigentlich ist. Das ist das wirklich oder ist
das wirklich die Funktion, die ich eigentlich aufrufen?
Möchte im Kopf also. Steht diese Abkürzung für das,
was ich hier eigentlich gerade haben möchte?
Und dann? Ist es quasi so ein?
Gefühl, so in einem Lexikon nachschlagen und dann, ja, warte
mal, wofür stand das noch mal? Ich weiß es nicht.
Ich frag einen Kollegen, aber gut, ich weiß, Oh wo stand das
und dann weißt du, wenn du mit sowas beschäftigt bist, ist es
ein absolut klares Zeichen dafür, dass das kein Cleaner
Code ist. Ja, also was ich zum.
Beispiel meinen Augen ja definitiv, weil die damals waren
ja der absolute. Verfechter von ja, das ist also.
Es ist halt auch eher also. 2 Sachen, die mir dazu einfallen
ist weil vielleicht kannst du ja in einem Team ne bestimmte
Konvention klären, ne. Also es gibt ja auch bestimmte
Konventionen. Irgendwelche cases?
Ne sowas wie camel Case oder was gibt es noch kebab case was was
was gibt es noch? Es gibt Tausende Snake Case, zum
Beispiel Pascal. Auch Gecoded hatten genau Pascal
Sag ich schon, Pascal haben wir nicht gecoded Python mein ich.
Aber wir können ruhig mal Pascal wieder.
Aufhalten. Schön doof, Pascal.
Nee, Pascal. Nee, aber was, was auf jeden
Fall, also das sind ja Sachen, die kannst du ja festlegen im
Team, dass du sagst, OK, wir haben jetzt bestimmte
Konventionen, wenn man zum Beispiel ne ne Funktion fängt,
dann und dann so und so an, wenn sie in einem bestimmten Kontext
ist oder was auch immer ich einfach mal so ganz allgemein
gesprochen habe. Wie gesagt, davon ab, dass es
für bestimmte Programmiersprachen halt
bestimmte Cases gibt, so wie Camel Case oder was auch immer
ne die sollte. Man natürlich im Team auch
Konventionen haben. Genau.
Aber wenn die Konvention natürlich dahingehen, dass du
irgendwann auf den Code guckst und dir denkst, hä, was passiert
denn da noch mal? Jetzt muss ich also, wenn du dir
überlegst, du guckst auf eine Funktion, die du vielleicht eine
Woche, 2 Wochen, Monat nicht mehr angeguckt hast und brauchst
dann erstmal wieder keine Ahnung, ne 10 Minuten eine halbe
Stunde bis du verstehst was da passiert oder vielleicht sogar
noch eine Deep Session um zu checken, passiert das jetzt da
wirklich so, ahja. Doch ich hätte jetzt, ich dachte
eigentlich, ich hätte nicht gedacht, dass er das auch so
wirklich macht, dass er, also ich dachte, dass er da schon
eigentlich in der Vorschleife abspringt, bei der Bedingung,
aber irgendwie scheint das doch nicht der Fall sein, also wenn
doch was anderes, genau, wenn du so weit kommst, dass du halt
wirklich schon an an an Punkt kommst, wo du wo du wo du die
wagen musst um zu verstehen was da passiert.
Wenn da vielleicht auch kein. Test angehen, aber ich meine.
Nur mal so wirklich um, um um einmal das Ganze wirklich
drastisch mal darzustellen, dann wird es halt dann heftig.
Was heißt drastisch genau an dem Punkt waren wir oder
zumindestens ich in diesem Projekt und ich weiß, es ging
auch anderen so. Das ist halt nicht cool, weil da
war es halt wirklich so. Ja, ich schreibe an meinen
Klassen, ich kenne meine Abkürzung, die so definiert
sind, ja, sage ich mal, ich weiß, was, das ist.
Ja gut, aber wenn du dann irgendwie woanders mal
reinguckst einen Code oder halt selbst vielleicht Monate später,
weißt du sicherlich nicht mehr, was die Abkürzung waren, weil da
war kein vernünftiges Wort mehr drin, was du quasi in Klartext
nenn ich es mal lesen kannst und will ich jetzt auch nicht zu
sehr abdriften, aber das ist auf jeden Fall noch ein Tipp
meinerseits übertreibt es nicht mit.
Abkürzung es ist halt wichtig dann wenn du halt im Team
arbeitest, ist es natürlich wichtig, dass man dann halt auch
einfach. Gut miteinander arbeiten kann
und nicht nur an seinem eigenen Code arbeiten kann.
Aber wenn wir jetzt zum Beispiel mal sagen, Pass auf, Wir haben
jetzt zum Beispiel, wir haben Variablen, wir arbeiten im Team,
wir haben jetzt jeder schreibt lesbare Variante, du kannst den
Code lesen, weil die Variante sind schön zu lesen.
Ist es verständlich? Es ist ne Gute, es gibt gute
Namen für diese variablen, sie sind es gibt einheitlichkeiten
Konvention, was auch immer, wir haben selbsterklärende Namen,
also zum Beispiel nicht nur irgendwie sowas wie Time,
sondern ist das wirklich Timing millisecons oder so, dass du
wirklich direkt siehst okay es ist nicht nur irgendeine Zeit,
du weißt sogar was da für eine Einheit drinsteckt und es ist
nicht so, dass es irgendwie kryptisch da ist.
Und es ist kurz und es ist aussagekräftig die Variablen.
Sind aber auch richtig fantastisch was du sagst.
Das haben wir alles, das ist, wir sagen jetzt, das ist alles
wichtig, so, und jetzt kommt jemand her und sagt.
Eine Zuhörerin oder ein Zuhörer und sagt, Leute, Ich arbeite
gerade ich, ich lerne gerade Softwareentwicklung und mache
das alleine für mich. Ich arbeite weder im Team, ich
muss erstmal zu Rande kommen, so.
Mögliche Situation kann ja vorkommen.
Ja, so was wollen wir auch. Nur was mittlerweile einige
Jahre. Quasi nur zurückblicken auf
unsere Studienzeit. Da hätten wir das wahrscheinlich
auch gesagt oder gedacht. Oder genau genau.
Und deswegen frage ich das jetzt ganz provokant mal.
Was würde man also, wie könnte man jetzt sagen, Hey?
Tino Warum? Namens.
Warum ist das wichtig? Auch.
Für andere theoretisch haben wir das ja auch schon besprochen,
weil das gilt. Für Anfänger, ich habe es ja
auch anfangs der Folge gesagt, das ist ja ein Thema, das
beschäftigt Anfänger, Fortgeschrittene und auch Profis
und ich weiß nicht, ob es irgendwann den Punkt gibt, wo
das trivial wird. Das Thema, wo dir denkst ist
doch klar, wie das Netz so und so klar, irgendwann hat man
Erfahrung und auch Konvention spielen da rein, dass du sagst,
ja ich bin in das so oder in unserem Team wird so eine
Funktionalität immer ähnlich genannt, also in irgendeinem
Schema, dass du da halt schneller drauf kommst.
So was wie Klassiker insert at Fat, was auch immer.
Also dass du so Konventionen auch dafür hast, dass du schon
weißt, was da grob passiert. Aber.
Was jetzt habe ich ein bisschen den Faden verloren.
Entschuldigung, aber genau weil das, das wird halt nie trivial,
weil du trotzdem irgendwann immer dich damit beschäftigen
musst. Und deswegen tangiert das
genauso auch schon n Anfänger, der sich damit auseinandersetzen
muss, weil. Du kannst dir natürlich sagen,
ich bin alleine und das ist jetzt hier nur ne irgend ne
übungsaufgabe im Studium oder in meiner Ausbildung, aber wenn ich
das später wieder rauf gucke und das ist, was wir ja vorhin
besprochen haben. Da weiß ich nicht mehr, was da
passiert und ich hab das ganz witzig.
Also so so so n kleines n bisschen off topic nicht aber
mal so n bisschen nostalgisch. Ich hatte mir mal das auch schon
ne Weile wieder her so alten Code angeguckt aus dem Studium
den ich programmiert hab, krass und.
Grundsätzlich dachte ich mir so, ja, war ganz vernünftig, was ich
da gemacht habe. Also ich hab eigentlich gedacht,
dass es viel, viel chaotischer ist.
Also erstmal props mein Vergangenes ich.
Aber trotzdem waren da so Punkte drin, wo ich mir dachte okay was
macht diese Funktion und hier okay warum habe ich das damit so
benannt? Die Variable und da merkst du es
ja schon, wenn du irgendwann später selbst noch mal drauf
guckst und das muss jetzt nicht 10 Jahre später sein, wie in
meinem Fall, sondern einfach nur vielleicht 23 Wochen später,
weil du nochmal wissen wolltest, was da passiert ist.
Dann hilft dir das da halt auch schon ungemein und außerdem
hilft es dir einen besseren Coding Style zu kriegen, also
dass du halt einfach auch Best Practices lebst.
Wenn du dann halt in dem Team kommst.
Weil irgendwann mussten zwangsweise auch mal in einem
Team arbeiten. Ich glaube, das lässt sich in
seltensten Fällen vermeiden und dann ist das einfach Gang und
gebe, dass das so gelebt wird, oder oder wie siehst du das?
Ja, also wie gesagt es. Ich finde das auch.
Nur wenn ich jetzt, also wenn du das auch gerade meintest, so
wenn. Rückversetzen hätten wir das
auch nicht gemacht beziehungsweise wir haben es
nicht gemacht, uns darüber Gedanken zu machen.
So und jetzt würde ich zum Beispiel sagen, OK, erstens alle
dir zuhören und sich denken, ich fang gerade an, macht es besser,
weil dann seid ihr schon mal. Ein Schritt voraus ihr könnt
Übung, also Übung, darin sammeln, zu überlegen, wie
könnte man denn etwas gut benahmen.
Und meine Erfahrung nach von früher, ich hab n Code
geschrieben für irgend ne übungsaufgabe im Studium.
Anfang der Woche ging's los. Ich hab.
Angefangen diesen kleinen Minialgorithmus zu entwickeln.
Hab da ne Pause gemacht von 2 Tagen.
Hab mich danach nach am dritten Tag sozusagen wieder dran
gesetzt, hab mir angeguckt weil ich da geschrieben ich wusste
nichts, ich hab mir ich hab da drauf geguckt und dachte mir so
was hab ich denn keine Ahnung und dann ging es wieder los da
musste ich erst mal gucken was habe ich da gemacht, wie
funktioniert das weil ich einfach also da kommen natürlich
andere Sachen mit rein die auch noch bei Cleancode wichtig sind
die wir auch noch diskutieren wollen aber allein schon dieser
Punkt, der hat mich schon dieser Punkt hat mich schon aufgehalten
und ich denke mir richtige Benahmung darüber nachzudenken,
wie man etwas nennen könnte, das sind Low hanging fruits, weißt
du die kannst du, das kannst du relativ easy üben, also du musst
jetzt nicht gleich mit, keine Ahnung die Penancy Injection
oder sonst was ankommen, irgendwas wo du dir vielleicht
wirklich am Anfang denkst. Hä was soll das?
Keine Ahnung ich weiß es nicht ganz entspannt immer 1 nach dem
anderen, aber sowas würde ich jetzt zum Beispiel sagen, da
kannst du halt als Anfänger relativ gut einfach mal ein
bisschen drüber nachdenken und es ist definitiv keine
Raketewissenschaft die da dahinter steht.
Ja, das ist halt so. N klassischer Fall von easy to
Learn, Hard to Master oder wie das heißt.
Ja ne, aber es ist ja so. Du hast natürlich recht, man
kann es sehr leicht üben, indem man sich einfach damit
auseinandersetzt, ne und ich würde sagen, dass auch die Code
Qualität enorm steigt, indem man dadurch also indem man anfängt
sich darüber Gedanken zu machen zu machen, egal wie simpel der
Algorithmus ist oder wie klein die Software, aber die
allgemeine Code Qualität von dem Code den ich selbst entwickelt
zu dem Zeitpunkt, der also diese Qualität steigt enorm an dadurch
und das. Andere Entwickler später danken
also, dass sie das besser verstehen, was du machst und du
selbst wirst es dir auch denken, danken, denken, danken.
Weil guck mal, wenn du sagst nach 3 Tagen oder nach 2 Tagen
bei so n bisschen Code mal Prokativ gesagt hast du schon
nicht mehr verstanden was da eigentlich passiert ohne dich
noch mal reinzudenken, dann ist das ja schon n super Beispiel
dafür zu sagen, OK hättest du mal da 5 Minuten Zeit
reingesteckt, mal auch wieder provokativ.
Gesagt, das Ding. Ist bei dir und ich hoffe, dass
das halt auch, dass diese Message angekommen ist bei dir.
Liebe zuhören liebe Zuhörer, falls du genau an diesem Punkt
stehst, dich damit auseinanderzusetzen, dass es
sich auf jeden Fall. Und auch zukünftig lohnt genau,
sich damit zu beschäftigen. Und es ist ja auch nicht so, um
das noch mal abschließend zu sagen, weil das ist mir auch
noch mal wichtig. Es ist nicht, es ist nicht so,
dass du ganz am Anfang dir immer gleich überlegen musst.
OK, wie benenn ich das jetzt, wie funktioniert das jetzt.
Wir hatten ja gesagt, das ist ein Prozess, das kann man auch
hinterher machen, man kann auch erstmal die Funktion schreiben,
sich hinterher noch mal hinsetzen und sagen, okay, es
funktioniert jetzt so, wie ich es mir vorgestellt habe und
jetzt gehe ich noch mal durch und überleg noch mal, finde ich
irgendwo eine Variable, die temp Test x ABC was auch immer heißt
oder eine Funktion die was auch immer heißt testfunktion
Testfunktion, also dass man wirklich sich noch mal überlegt
okay, also auch im Nachhinein nicht, vielleicht nicht
unbedingt im Vorfeld, aber vielleicht auch im Nachhinein,
weil am Anfang ist es vielleicht noch nicht ganz klar, was man
vielleicht wo man hin möchte oder wie es aussehen wird, aber
dann im Nachhinein das nochmal zu refact an das ist glaube ich
wichtig, dass man sich da vielleicht auch noch mal
Gedanken macht, das ist einfach vielleicht auch hilfreich, wenn
man denn nicht immer gleich von vornherein direkt.
Ne Stunde Zeit nehmen will für die nächste Variable.
Ich hab jetzt übertrieben, ja, aber.
Bin ich auf jeden Fall ganz bei dir.
Bevor wir die Folge beenden, hätte ich noch einen Punkt, was
mir auf jeden Fall, glaube ich, geholfen hat, wenn man mal so
drüber nachdenkt, da würde ich auch nochmal kurz gerne deine
Meinung zu hören und zwar glaube ich oder aus heutiger Sicht
würde ich auch den Tipp noch mitgeben, so abschließend, dass
es hilfreich ist, sich auch einfach mal professionell
geschriebene Software anzuschauen, sei es irgendwelche
Packages, libraries. Irgendwelche Repositories auf
github, die halt sehr gut bewertet sind oder viel
verwendet sind und mal schauen wie da so Variablen und
Funktionen quasi benannt wurden und versuchen zu verstehen was
da passiert und einfach mal so ein bisschen best practices.
Zu leiten daraus, und genau diese Konvention, die wir auch
genannt haben, dass man so zum Beispiel ne Einheitlichkeit
schafft, indem man so Schlagwörter wiederverwendet,
sei es sowas wie es heißt, length.
At insert weißt du also die Sonne, Sonne, Schlagwörter, dass
du Funktionen damit schreibst, werden ja immer wieder kommen
und dass man das auch einheitlich hält.
Es gibt ja so Team at. Es gibt Team Insert und weißt du
also. Das ist ja auch zum Beispiel von
Library Sol Library wieder unterschiedlich, aber trotzdem
weiß man ja was das also du, du hast ne Klasse und liest diese
Funktion und weißt einfach was da passiert.
Also man kommt halt relativ schnell dann auf den Inhalt und
da kann man sich glaub ich ziemlich coole Best Practices
auch ableiten und dass es sich bestimmt lohnt auch als Anfänger
da schon mal reinzuschauen, man muss ja nicht im Detail
verstehen was da passiert, aber dass man einfach mal die
Benahmung. Liest und sieht, wie gut der
Code aussieht. Ja, und vielleicht auch einfach
guckt, was da so für Benahmung gibt.
Wenn man jetzt nicht gerade, also weil du ja auch meine
Meinung wissen wolltest. Ist ein wertvoller Tipp, würde
ich auch sagen, sollte man auch. Vor allem also würde ich auch
sagen, als fortgeschrittener Programmierer oder
Programmiererin auch sehr gerne machen, sogar noch wichtiger
meiner Meinung nach, weil zumindest kann ich nur aus
meinem eigenen Nähkästchen plaudern, wenn ich mir manchmal
ein Paar, sagen wir mal, du kannst ja auch bei Java oder so,
wenn du dann in eine Funktion reinsteppst aus einer Library,
da war ich dann relativ am Anfang auch relativ schnell
überfordert, weil ich mir dachte, okay, was ist das denn,
da ist jetzt ein. Sogenanntes Generic mit drin und
ich wusste nicht was das ist am Anfang.
Also es gibt Momente, wo man quasi natürlich lernen kann aus
solchen Libraries oder auch Repositories, die öffentlich
einsehbar sind gerade. Wie wenn wir jetzt über
Benahmung sprechen, ist es vielleicht durchaus wertvoll.
Es kann aber auch abschreckend sein für mich zumindest.
Damals wäre es, es war es manchmal n bisschen
abschreckend, weil ich mir dachte, wow, ich hab keine
Ahnung, was da passiert und ich bin ja wahrscheinlich sehr, sehr
schlecht. Ja, also das ist.
So, ja gut, also das soll natürlich nicht abschreckend
wirken, ne, also man soll sich davon noch nicht abschrecken
lassen. Das wär natürlich negativ oder
so genau die falsche Auswirkung, denn daraus sondern eher man
muss ja wie gesagt nicht im Detail verstehen was da
passiert, aber man kann also das kann sich halt visuell
einbrennen, wie guter Code aussieht, wenn ich zum Beispiel
dazu neige, 100 Zeilen eine Funktion lang zu machen und guck
dann aber mal so rein, wie sag ich mal Profis das schreiben und
sehe halt alle ziemlich kurz die Funktion warum, warum weißt du,
dass man halt so merkt, also Style kann kann man ja auch so
verinnerlichen durchlesen. Weil ich finde das ganz
spannend. Ich hab mal nen Artikel gelesen,
der war sehr provokativ geschrieben, auch Richtung
verbessert dich als Coder selbst sozusagen und da war der Punkt
drin. Ja, wer von euch Codern liest
denn überhaupt Code? Und damit war wirklich gemeint,
wirklich mal in andere Projekte rein zu gucken, die sehr
erfolgreich sind und auch als allgemein sehr gut gelten, zu
gucken wie da drin gecoacht wurde oder implementiert wurde.
Und das ist n Punkt, den mach ich selbst auch sehr wenig, was
eigentlich ja schade ist. Definitiv, vor allem gerade,
wenn man sich überlegt, dass als Beginner man sich natürlich auch
schon Code viel angucken muss. Ob es jetzt, sei es jetzt in
irgendwelchen Folien. Von Uni oder Ausbildung, was
auch immer. Lehrbüchern ne, man guckt sich
ja wahrscheinlich zwangsläufig Code an um zu sehen wie
funktioniert, überhaupt, wie funktionieren die Basics.
Aber sich auch mal hinzusetzen und zu sagen, vielleicht auch
mal ehrlich zu sich zu sein, wie oft gucke ich mir Code von
anderen Leuten an, von also hochwertigen Code auch der.
Sehr wahrscheinlich hochwertig ist sag ich jetzt mal.
Das kann man sich mal Fragen, hinterfragen und das vielleicht
auch. Genauso weitermachen oder besser
machen und sich vielleicht auch als, na ja, wie sagt man
Neujahresvorsatz vornehmen und sagen.
Wir haben ein neues Jahr. Nehmt es euch als
Neujahrsvorsatz genau, ich lese Code.
Noch mal zu machen und in diesem Sinne Tino, würde ich sagen.
Schließen wir mal die Folge ab, ja.
Haben wir jetzt echt sehr ausführlich besprochen.
Hat mir auf jeden Fall Spaß gemacht.
Danke für Deine Insights und für deine Gedanken zu diesem Thema.
Ja, bitte, bitte. Und dann würde ich sagen.
Falls dir die Folge. Gefallen hat, liebe Zuhörer,
lieber Zuhörer, dann nehmt euch auch als neueres Vorsatz
vielleicht diesen Podcast 2 Leuten weiterzuempfehlen,
Arbeitskollegen, Studienkollegen, Kommilitonen,
sagt man dazu, glaube ich. Freunde und verwandte, Freunde,
Verwandten. Alle, die es interessiert in
Sachen Softwareentwicklung oder halt auch darüber hinaus, das
würde uns sehr freuen und. Wie gesagt, gebt uns auch gerne
Feedback zu dem Podcast über Instagram, die wir haben auch
eine Podcast Mail in den Shownotes alles unten verlinkt
und ich hoffe wir hören uns beim nächsten Mal wieder.
Schaltet wieder ein in der nächsten Folge und bis dahin.
Eure Coding Buddies gemeinsam besser.