Also du meinst der würde erstmal die ersten 2 Wochen richtig
beatmet und danach traut er sich gar nicht mehr anders zu holen.
Coding bodies Dein Podcast rund um Softwareentwicklung und
aktueller Tech News. Herzlich Willkommen.
Einen wunderschönen guten Tag hier wieder beim Coding Bodies
Podcast. Ich bin wieder dabei, der Fabi
und natürlich auch mein werter Kollege der Tino Hi.
Tino Hi Moin Moin. Bist du ausgeschlafen?
Nee, ehrlich gesagt nicht. Ich muss ja auch wieder früh
aufstehen, aber es geht, es geht.
Bis nicht so der früh. Auch selten ausgeschlafen muss
ich sagen. Ich ich liebe, schlafen,
schlafen ist. Cool, aber früh ist nicht so
dein Ding, oder wie? Was früh.
Aufstehen? Nicht so dein Ding.
Ja, na, weil das meistens gegensätzlich zu lange schlafen
ist. Ja gut, man könnte ja auch viel
früher ins Bett gehen, ne, aber? Zum Beispiel?
Gut, ich bin ich bin nachtaktiv, also ich finds auch geil, zum
Beispiel einfach abends zu arbeiten oder noch was zu
machen, Eule deswegen, genau deswegen ist es manchmal ein
bisschen schwierig, aber ich bin absolut bereit und fit für
diesen Podcast. Keine Sorge, ich hab auch wieder
einen schönen Podcast. Hier stehen, das ist.
Schön deswegen. Also ich würde sagen.
Hau mal raus, das Thema ist, ich bin sehr gespannt und machen wir
das Beste draus. Bevor wir, bevor wir starten, so
wollte ich auch nochmal ganz kurz so mit der kleinen aufwach
Anekdote anfangen, weil deswegen hab ich gefragt ob du
ausgeschlafen. Erlebt hast du heute morgen
etwas erlebt, oder was? Genau, also ich bin quasi ich
wollte. Also Wecker hat mich gar nicht
so großartig geweckt, sondern eher ein Herr, der draußen in
einer Straße rumgelaufen ist. Also hier bei mir in der Nähe
ist gleich ein rewe, muss ich dazu sagen.
Hab ich dann irgendwann heute morgen.
Ich hatte Fenster offen ne und dann höre ich die ganze Zeit so
ein Herren da Rumbrüllen und der hat immer gesagt der Supermarkt
ist ein Verbrecher, der Supermarkt ist ein Verbrecher.
Das müsste das Supermarkt danach.
Was war? Auf jeden Fall ist der
Supermarkt, weil ich glaube, er hat irgendwie hat erzählt, dass
er keine Zigaretten bekommen hat oder die super teuer geworden
sind oder sowas und er sich aber auch Lack lammkoteletts
eingepackt hat und das aber nicht funktioniert und dann hat
er Hausverbot. Gekommen und hat sich wohl die
ganze Zeit von Rewe hingestellt und hat immer gesagt, der
Supermarkt ist ein Verbrecher. Ja, aber das ist alles in
während der Aufwachphase passiert, quasi.
Also das hat sich so schön langgezogen, du bist so langsam
wach geworden und dachtest dir, hä, wer ist denn Verbrecher, was
ist hier los? Ich glaube, ich habe heute
morgen meinen Wecker bestimmt 2030 Minuten setzen lassen und
das hat mich überhaupt nicht gestört.
Aber der Typ hat mich aufgeweckt.
Ganz witzig, weil bei mir war es heute komplett umgedreht.
Ich hab eigentlich eigentlich hör ich meinen Wecker ganz gut,
aber der ist sehr sehr chillig, ich hab so.
Quasi so eine Art Streaming Liste, bisschen zufällig mit
entspannter Musik quasi. Wieso n radiowecker oldschool
dich und hab dann eigentlich entspannte Musik und kommt ganz
langsam raus aus dem Schlaf ne, aber heute morgen irgendwie
keine Ahnung irgendein Song eingegangen den ich nicht
kannte, es war einfach viel zu laut, der Typ hat gefühlt mich
angebrüllt, der Sänger was ist denn hier los?
Alter das war also bei mir war es quasi genau umgedreht ich war
heute nicht so sanft, ich hatte nicht so eine sanfte
Aufwachphase. Also da hätte ich lieber gehört
wie Supermarkt beschimpft ich aber am.
Ende werden wir beide über Geschreie und Gebrülle.
Irgendwie. Aufgeregt.
Und dann kanns losgehen. Und jetzt geht es los mit der
Podcast Folge also los jetzt, ach, was ist das.
Thema Film ab. Ja genau, wir wollen ja ein
bisschen darüber sprechen, über ja die Art und Weise wie man
Coach schreibt oder was man so für was es so für Möglichkeiten
gibt Code zu schreiben im Sinne von jeder hat seine eigene
Handschrift. Stichwort.
Und man kann ja zum Beispiel Code sehr komplex schreiben, mit
viel Zeilen oder halt zum Beispiel so im.
Krassen Gegensatz dazu sage ich jetzt einmal, der klassische
Oneliner. Weißt du so, dass man halt so
ein bisschen so das gegenüberstellt?
So hat das alles irgendwie so seinen Sinn, weil ne.
Wie, wie schreibt also was die die Folge soll behandelt, wie
soll man Code schreiben? So das war ganz provokativ jetzt
OK. Also so in Richtung.
Wie weit kann man Optimierung und Code Reduktion treiben?
Meinst du das so also, also wie weit kann ich meinen Code
optimieren, dass es noch sinnvoll ist, weil du meintest
so online, das ist ja so ja so weit verbreitet, da guck mal,
ich hab die Lösung in einer. Zeile.
Ja genau, also ich kenne das Halt zum Beispiel von dieser,
also von der Plattform haben wir schon mal geredet, Code wars, da
hab ich zum Beispiel auch ne zeitlang mal n bisschen
rumgerodelt so Coding Katas gemacht.
Einfach so zum Beispiel morgens n bisschen reinzukommen, finde
ich immer noch ganz cool. Hab ich aber ein bisschen, muss
ich sagen, sollten wir vielleicht mal anfangen damit
mal wieder ne, aber da hab ich zum Beispiel auch wenn irgendwie
Aufgabe hat, dann denkt man kurz nach, schreibt dann den Code und
Haut den rein und danach kriegst du ja auch zum Beispiel Lösungen
präsentiert von Leuten, die es auch geschafft haben und
manchmal sind da echt krasse Lösungen drin, also ne, das ist
so das wo ich mir denke. Boah, ey.
Wie wird das? Funktioniert?
Ich weiß nicht, also ich wusste gar nicht, dass das irgendwie
ich hätte Benny drauf gekommen, dass diese Lösung zu dieser
Aufgabenstellung sozusagen passt, ne?
OK, das ist aber schon ein ganz guter Punkt.
Also hast du den Code gesehen, ihn sofort verstanden und dir
gedacht, OK, cool, wirklich cool gelöst oder so.
Ja OK, es ist wenig cool, was passiert da und das war
erfolgreich, war das eher A oder b?
Also es gab ja verschiedene Lösungen und es war alles dabei.
Also einmal sowas wie OK, ja klar.
Ganz klassisch, oder? Das war aber sehr elegant
gelöst, oder? Keine Ahnung, das funktioniert
also wirklich so verschiedene Stufen davon und da sind wir
eigentlich direkt beim Thema ne, also dass man sich halt sagt, so
OK, was macht denn Sinn für den Code zu produzieren, was meinst
du denn, also welche Art und Weise ist denn zum Beispiel?
Ich sah jetzt wieder ganz provokativ, welche.
Was ist schöner? Was ist schöner?
Das ist also, man kann das nicht pauschalisieren, ne, also ich
weiß so ein bisschen aus meiner Historie heraus, dass ich eine
Zeit lang irgendwie voll auf den Trip war.
Dass ich mir dachte, ich muss jetzt super hochwertigen Coach
schreiben. Also so, dass Leute sich denken,
boah krass, also was krass, so weißt du, und dann kommt man
halt schnell auch in diese Falle rein, dass man sich denkt, oh,
ich kann hier noch eine Zeile einsparen, oder das kann ich
noch zusammen packen, wenn ich das so und so berechne, dann
wird es noch weniger oder effizienter Code.
Das aber jetzt hast du mir gesagt, hochwertigen Code machst
du nicht mehr. Nee.
Jetzt hole ich halt die ja das Erste was mir einfällt rein
damit und fertig. Kompiliert nicht.
Egal. Jeder hat ja.
Seine also was was ich damit meinte ist einfach, dass ich so
auf dem Trip, weil ich muss jetzt alles komplett so weit
pushen bis nichts mehr geht und alles so hoch optimieren
sozusagen ne was aber ab einem gewissen Grad einfach quatsch
ist, weil was du dir dadurch leider einkaufst ist natürlich
wenn du im Team arbeitest, es gar nicht mehr so
unwahrscheinlich, dass Leute zu dir kommen und sagen, ja, ist ja
cool was du da gemacht hast. Das scheint ja auch zu
funktionieren. Aber ich versteh es nicht.
Also ich verstehe einfach nicht mehr was da passiert und das ist
in im Team Gefüge natürlich super schlecht, weil es wird ja
auch der Moment kommen, wo vielleicht andere diesen Code
erweitern müssen oder umbauen müssen und quasi eine
Abhängigkeit geschaffen wurde, dass du das machen musst, weil
kein anderer sich die Zeit hat sich da reinzudenken.
Ne also ich will jetzt nicht abstreiten, dass andere Leute
das irgendwann verstehen, wenn sie sich das länger angucken,
aber das ist ja absolut meiner Meinung nach nicht der Sinn.
Hinter dem Code, sondern du musst sehr schaffen, ihn so
lesbar zu gestalten und dann halt auch ruhig mal eine Zeile
mehr zu schreiben, dass man relativ schnell.
Je nachdem, wie groß die Funktion ist, quasi das
überblicken kann und weiß OK alles klar das und das passiert
das halt nicht so Black Boxen entstehen wie komme ich habe
hier ein paar Schnittstellen für dich, da hab ich was
implementiert die Funktion zu verwenden die funktionieren aber
guck ja nicht rein, guck nicht rein, wirst du nicht verstehen
so nach dem wollte das ist ja halt auch nicht der Sinn
dahinter. Ja, also da bin ich wieder bei
dir verkehrt. Dann bin ich total bei dir.
Also ich denke auch, dass wenn du Code im Team sag ich mal
schreibst, dann sollte jeder auch.
Nach relativ kurzer Zeit irgendwie ein gewisses
Verständnis davon haben, was passiert dann ne und da gehört
für mich zum Beispiel rein, dass die der funktions Name der
Klassen Name, was auch immer man dann halt eben hat, der Name des
Interfaces und so weiter also alles was man irgendwie benennen
kann, dass die auch wohl überlegt sind, ne, also das
gehört irgendwie dazu, weil ich hab es auch schon zum Beispiel
erlebt, dass man irgendwie n Pair programmiert hat und dann
hieß es so ja können wir benennen die Funktion erst mal
so. Ist prinzipiell nicht so
schlimm, wenn man sich hinterher noch mal überlegt.
OK, wie genau nennen wir die Funktion jetzt, damit sie
wirklich aussagekräftig ist? Weil das hatte ich auch schon
mal. Weißt du, dass man dann so ja
passt? Erstmal lassen wir so, mir fällt
grad nix Besseres ein und dann haben wir irgendwie sage ich mal
2 Monate später waren wieder an dieser Stelle und da hab ich
dann auch gesagt Na. Und was macht die Funktion?
Also ich weiß es nicht so und dann haben wir uns also wirklich
genau wir beide uns wieder angeguckt und dann scheiße
alter, wir müssen, also ich hab dann auch mal so ein bisschen
den Appell gespielt und gesagt, Na ja, also wir müssen auf jeden
Fall diese Funktion umbenennen, weil das ist halt auch ein
Problem, ne und das gehört alles da ein bisschen mit rein wie du
auch meintest natürlich auch die Art und Weise wie der Code
geschrieben ist. Was ich noch ergänzen würde,
ganz kurz ist, das ist ja nicht nur so ist, dass du im Team
sozusagen, dass es wichtig im Team ist, weil ich glaube, jeder
erfahrene Entwickler kennt das oder hat das irgendwann mal
erlebt in seiner Laufbahn als Entwickler oder Halt auch als
Entwicklerin. Das waren Sicherheit, denkt so,
du schreibst Code, guckst ihn dir, sag ich mal im Monat ein
halbes Jahr, ein Jahr später an. Was denkst sie?
Äh, was n das für ne Kacke so und dann guckst du dir an und du
bist halt der selber, der es gemacht hat und das ist das.
Ist gar nicht mal so selten ne, weil man halt dann wirklich auch
in diese Falle tappt wie du meintest.
Na ich lass es erstmal so oder a ja ich verstehe das schon, also
weil in dem Moment, wenn du gerade schreibst, weißt du ja
was diese Funktion machst, machst und dann denkst du ja,
OK, werde ich auch, das passt ja so ne, aber nee, oft passt es
nicht, wenn man sich da nicht wirklich mal Gedanken drüber
macht. Ein Punkt der gerade so die
Benennung von Variablen. Option, dass sich da wirklich
Gedanken zu machen. Und das ist genau so ein
optimierungs Fall. Viele scheuen sich davor,
Variablen mit langen Namen zu belegen.
Ne. Wo ich mir so denke, ja OK, wenn
irgendwann ist zu lang ist richtig, aber lieber ein paar
Zeichen mehr und man kann es halt in paar Monaten noch
verstehen was diese Variable beinhaltet.
Genauso bei funktions Namen, Klassennamen Interfaces was auch
immer auch so ne Sache die man vielleicht so über die Zeit ein
bisschen lernen. Weil ich weiß nicht, woher das
kam. Aber anfangs hatte ich auch
immer das Gefühl, ah nee, das ist zu lang, das muss kürzer
sein. Eigentlich ganz interessanter
Punkt, ja, ich meine, dafür gibt es ja auch Konventionen für in
Sprachen a Aussagen gibt es nicht ohne Grund.
Aber das ist ein interessanter Punkt und das finde ich, fand
ich abgefahren, weil ich mal ne Kleinigkeit, also ein kleines
Modul sag ich mal, hab ich mal in n go ne also go lang oder wie
man das nennt habe ich programmiert und das habe ich
auch mit jemandem gemacht, der sich so ein bisschen mehr mit
Golling auskennt. Und.
Da hatten wir dann auch so ein bisschen die Diskussionen über
variablen Namen, weil. Irgendwie die Konvention in go
ist. Es kommt ja wahrscheinlich auch
so ein bisschen aus den Sprachen C und C plus Plus, wenn ich das
richtig im Kopf hab. Aus der Ecke kommt das ja so ein
bisschen. Und da ist die Konvention, dass
variablen Namen sehr kurz gehalten werden.
Und dann haben wir halt relativ lange darüber diskutiert, weil
ich hab dann angefangen, das zu schreiben und hab dann halt
immer ein bisschen längere variablen Namen genommen, so was
wie, ich sag jetzt mal der der variablen Name, Certificate oder
Zertifikat ne war dann halt einfach ja, mach doch NC.
Und ich dachte mir so, aber wer will denn jetzt wissen, dass das
quasi wirklich die Variable ist? Weißt du so, dass das fand ich
sehr krass und das war dann so ein gewisses.
Diskussions Potential an dieser Stelle ne und am Ende.
Werde ich auch drauf eingestiegen.
Also ne, also c. Also da fallen mir jetzt 1000
Wörter ein oder Beschreibungen was diese Variable beinhalten
könnte. Ja, das ist halt.
Das ist halt so ein bisschen das Problem gewesen.
Weil Zertifikat wäre das letzte gewesen, wäre ich eher bei
Counter oder keine Ahnung irgendwie sowas halt ne.
Ja, genau, aber das war also gut.
Vielleicht in dem Kontext vielleicht möglich, dass man
dann ableiten kann, aber nichtsdestotrotz dachte ich mir
schon so, dass einfach viel zu kurz, aber da sieht man mal, wie
sich das Ganze unterscheidet. Aber da gibt es wahrscheinlich
kein wirklich richtig oder falsch ne, weil wenn du in einem
Team arbeitest, wo sich jeder auf einem bestimmten Code Style
committed, dann ist das ja wieder OK.
Also weißt du in gewissen Regeln, außer es kommt jetzt zum
Beispiel außer du oder ich komm dann das Team rein und sagen,
was ist denn hier los? Versteh ich nicht.
Blöd hatte der kann man Vereinbarungen treffen und
sollte man auch, aber ich also ja gut ist natürlich jedem
selbst überlassen, ich will das jetzt nicht zu sehr kritisieren,
aber ich finde, wenn man sich darauf einigt, dass Variablen
ein 2 Buchstaben lang sein können oder nur dürfen, dann
wird es halt schwierig und ich glaube das kann sich keiner
merken. Also 4 Buchstaben hast du ja
auch nicht um das wird ein Buchstaben.
Das zu beschreiben, so weißt du ja, ja, also ich weiß, dass du
ihm, was du meintest mit C plus plus, dass da gerne mal kürzer
gehalten wird, aber so kurz nur auch nicht.
Also du hast schon eigentlich in der Regel Variablen so benannt,
dass man das noch verstehen kann, ist auch Branchenabhängig
am Ende es. Gibt ja auch so.
Keine Ahnung, denn so Konvention für physikalische Größen und
sowas, dass das natürlich wieder quasi Abkürzungen hat, oder?
Ja, sag ich mal Buchstaben OK, ist richtig, das hat ja wieder
irgendwo eine Verbindung am Ende, aber ich bin trotzdem der
Meinung, dass man eine Variable so beschreiben sollte, es vom
Namen her, dass ein anderer Code aus deinem Team das auch schnell
versteht, was da drin steckt. Ja, ja, auf jeden Fall.
Also ich bin da auch total dafür, dass man einfach sagt.
Also für mich sind gibt es so n paar Regeln wo ich mir denke das
ist wichtig und das kann ich auch irgendwie allen mitgeben
die jetzt hier zuhören und zwar einfach, dass man wirklich sich
Gedanken einfach mal sagt. OK, ich nehme jetzt nicht die
erste Variable, also die variablen Namen oder die erste
funktions Namen, was auch immer, alles was man irgendwie in
irgendeiner Art und Weise benannt.
Würde ich sagen. Und da gehst du ja
wahrscheinlich mit. Haben ja gerade darüber
gesprochen, dass man sich einfach mal wirklich an der
Stelle vielleicht ein paar Minuten mehr Zeit nimmt und
sagt, OK, was passiert hier wirklich?
Und wie kann ich jetzt sozusagen dieses entsprechende Konstrukt,
Ding, was auch immer benahmen? Ne das das ist glaube ich
wirklich ein wichtiger Punkt, weil.
Es ist ein unglaublich wichtiger Bestandteil von Code, dass man
ihn gut lesen kann. So würde ich zumindest ne das
sehen. Auf jeden Fall ja.
Aber da waren wir jetzt zum Beispiel auch gesagt, das kann
ja vielleicht auch, gefällt dir irgendwie ein Beispiel, ein
Tino, was, wo es wirklich wichtig ist zu sagen, OK, wir
optimieren das ganze jetzt und machen jetzt zum Beispiel mal
übertrieben gesagt n Onliner, anstatt dass man jetzt sagt, ich
hab jetzt irgendwie ein Code, der super lesbar ist.
Mhm. Also ein Beispiel wäre oder wo
mir das halt oft begegnet ist, ist natürlich auch im C Bereich.
Wenn du verschiedene Bibliotheken verwendest oder so
C plus plus alles so hoch optimierte Bibliotheken, die ja
eigentlich auch dafür gedacht sind, angewendet oder verwendet
zu werden und nicht da drin rumzupfuschen ne ja irgendwelche
Beispiele, keine Ahnung. Nimmst du zum Beispiel jetzt für
bildverarbeitungs Sachen die Open CV Library, die ist halt
wirklich sehr mächtig und effizient.
Und irgendwo eine Art Blackbox. Also du weißt natürlich, was die
Funktion macht, ne, da sind dann halt meinetwegen irgendwelche
Algorithmen implementiert und ich würde jetzt zum Beispiel
nicht auf die Idee kommen. Bei mir zu denken, das ist nicht
effektiv oder effizient programmiert und ich muss das
vielleicht mal reinschauen oder selbst umsetzen, weil die sind
wirklich sehr hoch optimiert und da würde ich dann halt einfach
von der Blackbox ausgehen, sozusagen ne, aber das ist genau
der Punkt. Die Entwickler, die diese
Bibliothek entwickeln, ich kenne niemanden und ich habe auch
selbst mitgemacht, aber ich kann mir vorstellen, dass auch
anstrengend ist. Dann halt sich also in wirklich
komplexe Algorithmen reinzudenken, dann noch
optimierte Funktionalitäten. Drin zu haben, dass das wirklich
alles effizient abläuft. Dann wird der Code
wahrscheinlich auch nicht mehr so einfach zu lesen sein.
Ja, das ist auf jeden Fall ein spannender Punkt, weil ich kenn
auch niemanden. Und falls hier gerade
irgendjemand zuhört, der oder die vielleicht genau das Macht
und da sehr krass involviert ist, solchen Hoch optimierten
Bibliotheken, Black Boxen, was auch immer arbeiten würde, uns
interessieren und auf jeden Fall, vielleicht kann man da
auch vielleicht ein Interview machen, also meldet euch bei uns
über Instagram zum Beispiel. Cody The Coding.
Auf jeden Fall. Das wäre wirklich spannend, weil
ich hab das mal so im kleinen Rahmen gemacht für ein Projekt
quasi in C, ne ne inline bibliothek geschrieben, also ich
will jetzt nicht weiter darauf eingehen, was das jetzt bedeutet
mit Inliner und so, vielleicht machen wir es, dann können wir
das machen, das wäre gut. Damit ich auch weiß.
Und da hab ich halt auch, denn das war genau meine Phase, wo
ich alles hoch optimiert habe und dann hat das funktioniert.
Wirklich konnte man gut verwenden und so, aber ich weiß,
dass ein Kollege zu mir. Gekommen ist der da was
integrieren wollte in die Bibliothek und sich dachte, er
hätte was passiert da ne und dann dachte ich mir naja im
ersten Moment weil es frisch war so ist doch ganz logisch was da
passiert, aber ein halbes Jahr später habe ich auch geguckt und
dachte mir Ui jetzt weiß ich was er meinte weißt du und das ist
das ist halt immer dieser Trade off den du am Ende hast.
Ja aber da hast du. Das dann erstmal von dort aus
ein bisschen mitgenommen, wahrscheinlich ne so.
Du hast das gemacht und warst dann noch so ein bisschen im
weil du meintest du hattest das am Anfang so oder eine Zeit lang
wo du so. Versucht hast alles immer sehr
stark zu optimieren, kam daher aus dieser Zeit gerade.
Ja, natürlich. Also im Embedded Bereich hast du
ja oft wirklich Zeit kritische Anforderungen oder halt wirklich
nicht so viel Zeit, da quasi Laufzeit oder Speicher zu
verschwenden und dann fängst du halt an zu optimieren.
Ja und ja, auf jeden Fall kommt das aus der Zeit aber.
Aber das fand also das war halt auch so.
Ich fand es auch geil, diesen Code zu optimieren und es hat
Spaß gemacht, glaub ich zu überlegen, wie kann ich denn
jetzt noch ein paar Zyklen einsparen, um noch weniger
Laufzeit zu verbrauchen oder was auch immer ne, aber du merkst
halt schnell, dass es nicht Team tauglich ist am Ende oder ist es
sehr schwierig ist das Team tauglich.
Zu gestalten, ja versteh ich, aber das ist ein guter Punkt,
weil das ist ja genau NN sehr interessanter Bereich, das weißt
du ja meintest. Ne Embedded ist ja
wahrscheinlich ein gutes Beispiel dafür, wo man eben mehr
optimieren muss. Na also wenn ich jetzt zum
Beispiel daran denke, dass ich ja auch viel im Web und in der
Web und App Entwicklung, sag ich mal gearbeitet hab ne so die
letzten 5 Jahre. Da ist es meiner Meinung nach
zum Beispiel nicht notwendig und da kann man sich auf jeden Fall
schon ein bisschen mehr noch austoben, weil man hat meistens
mehr Speicher zur Verfügung, man muss nicht auf jeden jedes Bit
und Byte achten und da finde ich, ist es auch durchaus
wichtig, dass wenn man die Freiheiten hat, halt eben
möglichst auch zu sagen, also ne, immer in den Grenzen, wie
weit man das machen kann, möglichst den Code lesbar zu
gestalten und da hatte ich zum Beispiel auch ein krasses
Beispiel, das ging dann auch um so ne Tabelle, wo Daten
angezeigt werden sollten. An der Oberfläche, also einer
Website. Und da hat dann ehemaliger
Kollege von mir n. Eine Komponente also diese
Tabelle geschrieben, super. Allgemein also man konnte alles
einstellen, sortieren, egal welche Daten da drin standen und
so weiter das war ne so ne Komponente und solange du die
benutzt hast ne wie eine Blackbox hatten wir gerade
darüber gesprochen alles cool und dann gab es diesen Zeitpunkt
wo ich was anpassen musste wo es quasi über den Anforderungen
quasi was reinkam und ich musste genau diese Komponente von
dieser Tabelle anfassen und. Das war also musst du dann den
Code. Genau, quasi.
Und das war so heftig. Verallgemeinert mit Generics und
so weiter. Wo man irgendwann überhaupt
nicht mehr geblickt hat, was passiert hier eigentlich und das
fand ich wirklich schwierig und an der, also das sind so meine
Grenzen, wo ich mir sagen würde, OK.
Ganz ehrlich, solange man etwas hat, was man auch regelmäßig und
es war eine Art von Regelmäßigkeit, wo also an ne in
der man diese Tabelle auch verändern musste.
Macht es keinen Sinn meiner Meinung nach, dass man dann so
ne hoch. Generische optimierte Tabelle
hat ne an der Stelle ist für mich auf jeden Fall ein
Beispiel, was mir jetzt direkt eingefallen ist.
Was finde ich in der Web Entwicklung auch nicht so viel
zu suchen, hat also klar. Also Code duplikationen
vermeiden, auf jeden Fall, aber nicht um jeden Preis.
Ja, also war das denn also, dass der Kollege dann nicht mehr
greifbar war, um die Änderung zu machen im Urlaub oder vielleicht
irgendwie gewechselt, oder also warum musstest du dann da
reinschauen und konntest es nicht nur noch anwenden,
sozusagen. Ja, also er war im Urlaub gerade
zu der Zeit auf jeden Fall. OK, also absoluter Klassiker und
genau in dem Moment. Ja genau.
Dann passieren. Aber nichtsdestotrotz, so weiß
nicht, man hat ja dann auch so weiß nicht, es ist ja immer auch
so, dass wenn du im Team arbeitest.
Du kannst natürlich Fragen, das ist klar.
Aber es bringt ja auch nichts, jemanden total rauszureißen aus
der Arbeit, die Person dann gerade macht.
Und das ist dann irgendwie. Ich hab mir schon gedacht, na
gut, du wirst du schon verstehen, ich muss jetzt nicht
irgendwie unbedingt den Fragen, aber nichtsdestotrotz dauert das
ja dann einfach zu lange ne und das bringt ja auch nichts, wenn
man jedes Mal wieder die entsprechende Person fragen
muss, die das gemacht hat und eventuell wie wir gerade auch
schon gesagt haben, die Person selber vielleicht
hundertprozentig weiß wie es geht und auch erst mal gucken
muss so, dann ist ja auch keinem geholfen, weißt du und deswegen.
Ne. Ob die Person jetzt da war oder
nicht. Ne.
Ja, spannender Punkt. Also man merkt ja, dass man ja
doch immer wieder quasi auf so eine Situation trifft, wenn man
den hat, sich wirklich als Entwickler wirklich überlegen
muss. So, ja wenn ich es nicht doch
vielleicht ein paar Zeilen mehr schreiben und dafür
verständlicher, finde ich auf jeden Fall spannend, dass also
das halt auch in sämtlichen Bereichen einem begegnet, ne,
weil du jetzt meintest der Web oder App Entwicklung, dass du da
natürlich auch versucht irgendwelche Komponenten so
allgemeingültig und konfigurierbar wie möglich zu
machen. Jeder das verwenden kann für
seinen Anwendungsfall ist natürlich dann auch wieder so
ein typisches Rabbit Hole am Ende ne und dann geht man
vielleicht übers Ziel hinaus. Aber kennst du das auch, wenn
man jetzt nicht unbedingt Code Optimierung, aber wenn jetzt zum
Beispiel wenn Java so mit Klammern arbeitet, mit den
geschweiften Klammern, weil wir ja auch am Anfang noch mal
gesagt hatten, so Handschriften von Entwicklern und Entwickler
innen und ich kenne das auch, dass jeder da so ein bisschen
eigene Feinheiten hat, und kennst du das, dass man zum
Beispiel manche. Setzen diese geschweifte Klammer
direkt diese erste um diesen Code Block zu öffnen, direkt in
die Zeile vom IF und manche in die nächste Zeile.
Ja. Und das ist noch, was mir gerade
so einfällt, weil das hat jetzt nicht großartig was mit
Optimierung zu tun. Aber schon so ein bisschen mit
der Code variiert und die Lesbarkeit kann durchaus
beeinflusst werden dadurch, dass man ja zum Beispiel andere
Gewohnheiten hat und sich auf andere Gewohnheiten einstellen
muss. Ja, ist eigentlich ein gutes
Beispiel. Also ich weiß.
Damals in der C Welt haben viele.
Das sind die nächste Zeile gerutscht, dass du quasi so eine
Zeile nur mit der geöffneten Klammer hast.
Dann neue Zeile Einrückung und der.
Code als ich angefangen habe zu programmieren, habe ich es auch
immer so gemacht. Ja, ist ist gängig, also ist
jetzt nicht so, dass das ein absolutes No go ist oder keiner
macht. Ich persönlich mag es aber
überhaupt nicht, weil irgendwie alles länger wird ohne Mehrwert
zu generieren. Also ich finde es auch rein
optisch nicht förderlich, also es ist nicht so, dass ich mir
denke, jetzt sehe ich viel besser, wo dir der Bedingungs
Block ist oder der Funktions Block.
Also überhaupt nicht. Ich finde es eher, ich empfinde
es als störend. Also bei mir geht die geöffnete
Klammer halt auch in der gleichen Zeile wie zum Beispiel
die Funktion los. Ja, bei mir mittlerweile auch so
ne, aber ich hatte. Ich hatte genau in diesem Punkt,
deswegen hatte ich wollte ich damit einleiten, weil.
Ich wusste gar nicht, warum. Ich dachte immer, das ist
Scheiße, also wenn man das nicht, wenn man die geschweifte
Klammer nicht direkt in die nächste Zeile setzt, dann sieht
das Kacke aus, so und irgendwann dachte ich mir, was ist
eigentlich dein Problem, also was ist das Problem dabei das so
zu machen, weil du ja ich gehe total bei dir mit, ne du
schaffst mehr Zeilen ohne Mehrwert so und ja.
Aber wie gesagt, ich hab beides gemacht, weil das irgendwie so
ein bisschen Konvention war in dem C Projekt und das haben alle
so gemacht. Dann habe ich es auch gemacht
da, also ich bin da nicht so der komplett sich dagegen sträubt,
aber ich fand es also. Es hat sich nicht richtig
angefühlt. Aber da sind wir auch wieder bei
Konventionen innerhalb eines Teams.
Ne, weil ich glaube, dass es durchaus sinnvoll ist, wenn sich
zum Beispiel ein Team neu bildet oder man ein neues Team Member
bekommt, ne, dass man bestimmte, sagen wir mal Rahmenrichtlinien
für den Code einfach ein bisschen festzieht ne, also das
hilft schonmal, dass man zum Beispiel dann sagt, Pass auf, du
bist vielleicht der neue hier, wir machen das so, dass wir
sozusagen die geschweifte Klammer einfach mal eine Zeile.
Drücken oder so ne. Also du meinst er wird erstmal
die ersten 2 Wochen richtig beatmet und danach traut er sich
gar nicht mehr anders zu koten. Nein, also das ist ist ist auf
jeden Fall noch mal. Wir können ja auch noch ne Folge
machen über so sag ich mal Teambuilding ne im Sinne von was
man vielleicht am Anfang von einem von einem, wenn sich ein
Team zusammenschließt macht, weil ich finde es ist ja auch
gut, wenn man zum Beispiel sagt, OK, es kommt jetzt ein neuer
Mensch rein in das Team und man sich dann sagt, so OK,
vielleicht kann man ja von wem anders lernen und dann kommt
vielleicht ein gutes Argument und man sagt.
Ja, stimmt eigentlich. Ja, wir sind die ganze Zeit,
weißt du, wie sagt man, man sieht den Wald vor lauter Bäumen
nicht, ne, aber genau, ich finde dieses Gespräch und zu sagen
macht das immer so oder ihr müsst das jetzt alle so machen
wie ich das bringt ja nix aber ich glaub so ein gewisses
Commitment erreichen. Ja, also man sollte halt schon
gucken, dass er halbwegs einheitlich ist vom vom vom Stil
her ja zumindest innerhalb eines Projekts oder einer Software.
Auf jeden Fall aber an sich. Du hast es ja gerade selbst
gesagt, der Stil der eigenen Programmierstil ändert sich ja
auch und entwickelt sich definitiv, wie beispielsweise
jetzt so ne ganz einfache Sache, wie mit den Klammern oder die
Art und Weise wie man Variablen und Funktionen benennt, der.
Ja, das. Stimmt, das sind also ich finde
es auch gut, man trifft ja auf unterschiedliche Stile, wenn man
mit unterschiedlichen Entwicklern zusammenarbeitet und
einfach mal fragen, warum machst du das eigentlich so und so und
dann wird es ja n Grund geben und es ist nicht
unwahrscheinlich, dass man sich auch denkt so ja, also hab ich
das noch gar nicht betrachtet und du hast recht, also wenn ich
jetzt die Code Zeile lese mit deinen mit deinen funktions
Namen zum Beispiel. Ja.
Dann versteh ich wirklich auf Anhieb.
Was das macht? Ja.
Also du hast recht, also ich sollte, dann eignet man sich das
vielleicht so ein bisschen an und dadurch entwickelt sich der
eigene Stil. Man gibt wieder Input an andere,
bekommt Input und ich meine cool ist ja wenn du dann im Team,
dann wenn jeder sich so weiterentwickelt, weil wie
gesagt, es geht ja nicht nur um das algorithmische denken und
das Programmieren an sich, sondern halt auch um die Code
Qualität und zu Code Qualität zählt das nun mal enorm mit rein
genau. Also auf jeden Fall, wie gut man
den Code lesen kann, wie verständlich man gestaltet, ne.
Es kommt auch ein bisschen drauf an, so wie man die Funktion
kapselt und ne, also das sind ja alles so verschiedene Aspekte,
aber allein schon die Lesbarkeit und Verständlichkeit einfach vom
geschriebenen Code, vom vom geschriebenen Wort ist ja schon
wichtig. Da fällt mir zum Beispiel noch
eine Sache ein, weil du meintest, man entwickelt sich ja
auch in punkto variablen Namen. Ich hab zum Beispiel wenn du
jetzt keine Ahnung mehrere Module hast von irgendwas ne und
du willst irgendwie nisch speichern, hab ich früher immer
geschrieben Module list. So, bis ich irgendwann mal bis
irgendwann mal ein anderer Entwickler zu mir kam und
meinte, Na ja, aber wieso nennst du das denn jetzt?
Modul ist doch einfach Modules, du siehst vorne das Ding heißt
Modules, hat vielleicht sogar noch n Datentyp, je nachdem was
du für ne Programmiersprache genau je nachdem was für eine
Programmiersprache benutzt, aber irgendwo siehst du also entweder
du siehst es direkt in der Typ Bezeichnung der Variable selber
sozusagen was für ein Typ ist oder eben wenn du dann halt
sozusagen die Werte belegst. Also irgendwo wird ne.
Liste da reinkommen und dann sieht man ja OK eine Liste und
da dachte ich mir auch so, ja gut, eigentlich total redundant,
wenn man das so sieht, ne. Was gutes Beispiel also?
Wissen total solide, also total simples Beispiel, aber.
Seitdem programmiere ich halt so und ich finde, dass es durchaus
lesbarer ist, also dass man halt einfach einfacher, schneller den
Überblick darüber bekommt, was im Code passiert und man weniger
lesen muss. An der Stelle auch ne.
Also du hast sozusagen dein erster Blick fängt sozusagen
mehr ein. Ja, aber das ist wichtig, dass
man sich da, und ich glaube, da ist auch wichtig, dieser
Austausch, weißt du mit verschiedenen Entwicklern und
Entwickler innen zu haben und auch Code von anderen Leuten und
sich selber zu lesen und zu hinterfragen, zu evaluieren.
Ja. Das ist, ich will jetzt nicht
vertiefen, weil wir jetzt schon ziemlich lange nicht Folge
aufnehmen. Aber eine ein kleiner Funke
noch, das hatte ich mal in einem Blog gelesen, fand ich ziemlich
spannend, ist einfach dieses ja, wie oft liest.
Du Code ja. Und dann denkt man sich so was
meint er damit? Nein, das war wirklich genau so
gemeint. Wie oft liest du Code, wo du
weißt, dass er gut ist? Also in irgendwelchen berühmten
Libraries oder irgendwelchen Packages einfach mal
reinzuschauen, wie die das machen, ja.
Und wirklich wie ein Buch Code zu lesen und da sich was
rauszuziehen. Und da muss ich sagen, das mache
ich selbst auch sehr wenig. Ja.
Nur eigentlich immer nur, wenn ich es musste.
Also wenn ich halt wirklich wissen will, was da drin steckt,
was wenn die ich was verwende oder irgendwie sowas.
Also wenn ich wirklich aktiv daran arbeite aber zu sagen ich
k ich guck jetzt einfach mal irgendwo rein, so weißt du das
hab ich auch nicht guter. Punkt.
Also die Frage, ob ich das machen würde ich dir gern
beantworten, aber der Manager guckt schon, müssen die Folge.
Es rum. Ja, wir müssen jetzt abbrechen.
Ich guck da auch nicht so oft rein, aber ist auf jeden Fall
ein guter Tipp. Sollte man öfter machen.
Ja, ja. Damit belassen wir es auch,
würde ich sagen, jetzt an der Stelle hat auf jeden Fall Spaß
gemacht, drüber zu quatschen, ich finde es wirklich ein sehr
wichtiges Thema, deswegen, liebe Zuhörerinnen, liebe Zuhörer,
falls du noch Fragen dazu hast oder Anmerkungen, meld dich auch
diesbezüglich gerne bei uns, auf welchem Kanal auch immer die
Links zu den ganzen Kanälen findest du in den Show Notes,
aber ansonsten vielen Dank fürs Zuhören, wenn Dir der Podcast
gefällt, abonnieren auch gerne, lass ne Bewertung da und ja
ansonsten würde ich sagen. Bis zum nächsten Mal.
Eure Kording war dies. Gemeinsam besser.