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.