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