Was für unglaubliche Tricks ich drauf habe und der Rest deines Teams denkt sich so. Ja OK, dann kannst du dich in Zukunft selber um diese Klasse kümmern, Kollegen genau dann. Coder alleine weiter das da steigt ja niemand mehr durch. Coding Boys Dein Podcast wohnt im Softwareentwicklung und aktueller Tech News. Herzlich Willkommen.
Halli Hallo ihr lieben, herzlich Willkommen zur neuen Folge des Coding Buddies Podcasts. Es geht wieder los, ne neue Folge startet und damit werde ich natürlich wieder den wunderbaren Tino begrüßen. Tino, wie geht's dir? Moin Moin Fabi, schöne Einleitung, gefällt mir ja, mir geht's gut. Ich hoffe dir auch. Ich glaube, wenn man das mit der Stimmlage sagt, dann kannst du alles sagen, ja. So, so, Showmaster Game Master
mäßig. Ja genau da hängt man dir direkt an den Lippen, das ist das kommt gut, das find ich. Gut, muss man mal so zu weißt du so, wenn Leute eigene Kinder haben, muss man sagen und jetzt ihr lieben Kinder gehen wir ne Runde spazieren und das wird der absolute Knaller. Und danach und danach? Räumt ihr euer Zimmer auf? Yeah. Ja, das wäre das. Könnte sein, könnte funktionieren. Es reißt halt einfach mit. Ja, das ist einfach motiviert. So, ich räum mein Zimmer auf jetzt.
Jetzt ist OK. Kurz Pause. OK, Ach nee, Tilo, erzähl doch mal was haben wir denn heute auf dem Programm, worum geht es denn heute, was ist der Titel? Nee, nicht der Titel, das Thema des der heutigen Folge. Ja, es geht also nicht um Zimmer aufräumen an sich, aber aufräumen ist kein schlechtes Stichwort. Und zwar wollen wir uns heute mal so ein Prinzip in der Softwareentwicklung vornehmen. Und zwar das Dry Prinzip, was im Endeffekt für Don't repeat yourself steht.
Wofür steht das Don't repeat yourself, OK? Tippte Witz, was dich einfach. Du bist ja hart rangekriegt. So, jetzt hab ich kein Bock mehr. Macht euch voll geil. Sei ehrlich, du hast jetzt die ganze Zeit auf diesen Moment gewartet. Oder das war bei dem Alten. Ach so war OKOKOK ja gut, war nicht schlecht. Und die Leute fallen darauf. Rein Liebe zuhören lieber zu. Ich hoffe, du konntest jetzt auch darüber lachen, dass ich darauf reingefallen bin. Es tut mir leid. Na, alles gut, und zwar
aufräumen. Das Stichwort jetzt hast du mich aus dem Konzept gebracht, weil es spielt dieses Prinzip auch in die Codequalität mit rein sauberen Code zu haben, der wirklich wartbar und aufgeräumt ist und das ganze Prinzip wollen wir heute mal ein bisschen erklären beleu. Chten, die vor und Nachteile nennen. Und ich sage bewusst Nachteile, weil es auch so einige, ich sag mal Herausforderungen dabei gibt.
Es ist nicht nur alles grün und positiv dabei, sondern ich finde man kann das auch ein bisschen kritisch betrachten, das würde ich auch gerne mit dir machen heute. Ja, auf jeden Fall. Also ich finde das ja immer ganz schön, wie du ja weißt, wenn man irgendwie so eine kleine
Analogie nimmt, aber. Vorher können wir einmal gucken, dass Don't Repeat yourself steht ja für also, dass man sozusagen sich, na ja, natürlich nicht wiederholen soll, klar, aber es geht ja darum um Redundanzen im Code zu vermeiden, ne und jeder kennt das ja vielleicht vielleicht auch nicht, ist so eine Sache, aber den Sachverhalt kennt jeder, zum Beispiel Briefe schreiben und stell dir vor, du hast.
Eine Geburtstagsparty hast einen runden Geburtstag, willst alle Leute einladen und sagst jetzt okay ich möchte irgendwie eine Einladungskarte rausschicken und wenn man sich jetzt überlegt okay ich fange jetzt an, Brief zu schreiben, zum Beispiel lieber Gast 1 und dann geht's los, kommt die Einladung, die ganzen Informationen, wann geht's los, wo findet statt und so weiter und sofort, das musst du ja an jede Person schreiben, so und wenn du dich jetzt händisch machen würdest und
jeden Brief immer wieder gleich schreiben würdest, immer wieder, dann ist es ja irgendwie. Ja, weiß ich nicht. Das macht ja keiner. Also da kommt man ja relativ schnell auf die Idee, warte mal, ich muss keine Ahnung sagen wir mal 50 Briefe schreiben. OK, krasse Party. Wird ne gute Party. Ich muss 50 Briefe schreiben, aber eigentlich steht immer das Gleiche drin, außer dass du die Person, den Namen der Person, die du einlädst, eben ersetzt.
Dann kommt man ja vielleicht relativ schnell darauf zu sagen, Don't repeat yourself, also schreib ich einmal n Vordruck Druck das 50 mal auf aus und schreibt dann die entsprechenden Namen von den Leuten die ich einlade rein. Mit Hand oder auch direkt über den Computer.
Ja, ein ganz gutes Beispiel, weil du natürlich auch, also ich sag mal, wenn du 50, mal diese Einladung schreibst, ist ja die Wahrscheinlichkeit gar nicht so gering, dass du irgendwo einen Fehler an Schreibfehler oder so einbaust. Zuerst 5 schreibst du noch konzentriert und sauber und dann wird's denke ich mal immer fahrlässiger du.
Hast einen wichtigen Punkt bei der Nummer auch noch genannt, was denn die finale Optimierungsstufe ist, indem du einfach sagst, lieber Gast und das schickst du einfach raus. Finde ich gut, warte ich notiere mir das eben. Da kann ja gar nichts mehr schief laufen. Der aber gutes Beispiel genau, und da würdest du das ja auch wieder verändern und wiederverwenden und dich nicht ja selbst wiederholen. Ganz gutes Beispiel. Was eigentlich auch so, dass die Kernaussage des Prinzips ist.
Also es ist nicht unbedingt die Aussage. Also einmal und nur einmal. Das ist auch noch n anderes Prinzip. Da kann man später noch mal drauf eingehen, um das ein bisschen zu differenzieren. Aber im Endeffekt geht es halt wirklich darum anstellen, wo ich merke, ich habe Redundanzen, diese zu vermeiden, einfach
genau. Das fängt ja beispielsweise, wenn man jetzt auf Code Ebene ist, damit an, dass man zum Beispiel, wenn du eine Berechnung einmal durchführst, anstelle 1 irgendwo in deiner Software und diese Berechnung anstelle 2 nochmal durchführst und anstelle 345 dann.
Möchtest du ja sozusagen nicht, dass du das jedes Mal wieder an den entsprechenden Stellen hast, sondern vielleicht dann eine zentrale Stelle hast, dass du diese Redundanz vermeidest und einmal diese Berechnung, die vielleicht, sagen wir mal aus 10 Zeilen Code besteht, einmal in deinem Code hast. Und dann halt nicht überall immer wieder im Code. Genau, dass du halt, sage ich mal, diese Berechnung oder zum Beispiel Daten, die du aber reinstellt.
Bereitstellst Mensch heute ist aber schwierig. Dass du quasi so ne Wissenseinheit schaffst, halt darüber und dann die Abfragen kannst. Und dann hast du halt so n zentralen Punkt, wo du quasi das Wissen rausziehen kannst. Beispielsweise für Daten und nicht überall immer wieder dieses Wissen aufbauen musst. Genau in Form von Funktion, Berechnung, wie auch immer. Und das sorgt halt dafür. Dass man halt auch eine geringere Fehleranfälligkeit hat.
Das, was wir nämlich gerade. Quasi in dem Briefbeispiel ja schon mal so n bisschen angeteasert haben, ist natürlich auch n großer Pluspunkt an diesem Prinzip, dass wenn du es an einer zentralen Stelle hast und ja hoffentlich auch abgetestet ne. Dass du quasi weniger fehleranfällig bist im Gesamtsystem mit dieser Funktion, weil du es halt zentralisiert hast, dass es abgetestet. Du weißt, das funktioniert.
Und wenn du es dann daraus verwendest an verschiedenen Stellen kannst du dir eigentlich auch sicher sein, dass das funktioniert, nicht Fehler fehlerhaft ist. Und du kommst ja auch noch zu dem Punkt, dass wir haben ja auch schon öfter mal in unserem Podcast über Refactoring
geredet. Und sowas hatte ich tatsächlich auch schon mal refactor du bist dann an einer Stelle des Codes und Refactors diese Stelle und merkst dann okay warte mal hier, hier könnte ich was verbessern und dann hatte ich es
tatsächlich auch schon mal. Ich glaube also, es klingt jetzt gerade so wie wow, echt, du hattest das mal, aber es ist glaube ich es passiert öfter mal irgendwie oder im Laufe einer Softwareentwicklungskarriere, dass man sowas mal hat und zwar habe ich dann halt dieses Codesstück Refected und dieses Codestück war aber ein redundantes Codestück.
Was sich sozusagen nicht nur, also es waren 2 Sachen, eigentlich zu tun, einmal ne Erweiterung und dazu dann hat sich n Refactoring angeboten, was aber dazu geführt hat, dass Codestelle 1. Diese Erweiterung bekommen hat und auch verschönert wurde und Erweiterung 2 eben nicht mehr. Und dann hast du ja diesen Effekt, dass du unterschiedliche Verhalten hast an unterschiedlichen Bereichen der Software Punkt 1 und Punkt 2 ist du findest diese Duplikate.
Sogar eventuell noch schwerer, die du ja vorher 1 zu 1 dupliziert hattest. Und das macht die Sache dann auch noch n bisschen schwieriger. Das heißt also es. Wird es wird halt inkonsistent an der Stelle. Genau. Und wenn du das aber raus ziehst und dieses Prinzip Don't repeat yourself anwendet, das heißt, du hast eine zentrale Stelle, wie wir gerade meinten, und dann musst du etwas refectern oder etwas erweitern, dann hast du halt genau diesen Effekt.
Dass sozusagen die Erweiterbarkeit oder Wartbarkeit einfach auch verbessert wird durch das Prinzip. Ja, dazu fällt mir auch direkt aber auch ein Nachteil ein. Da würde ich auch später drauf eingehen. Ich hoffe ich denke dran, weil nicht, dass wir jetzt vor und Nachteile hier hin und her werfen, das sollten wir vielleicht ein bisschen strukturierter machen, aber ansonsten erinnere mich mal bitte daran.
Ist aber auf jeden Fall im Großen und Ganzen auf jeden Fall ein großer Pluspunkt. Ja der der quasi das Drive Prinzip da anzuwenden, also unter Gesichtspunkt. Fehleranfälligkeit, die verringert wird und natürlich die Wartbarkeit, die da enorm gesteigert wird, weil du halt nur noch eine Stelle im Code anrühren musst. Und es wird ja auch, also es wird ja auch übersichtlicher, zunächst erstmal. Wenn ich jetzt diese Funktion rausziehe, dann packe ich das an eine Stelle.
Ich kann darauf zugreifen, das ist ja grundsätzlich erstmal übersichtlicher. Genau also mit der Prämisse, dass du natürlich dann diese diesen Codeblock, den du Kapselst in eine Funktion beispielsweise. Natürlich auch gut benennst, damit du weißt, was die auch wirklich. Tut ja gut, klar, also das ist jetzt mal vorausgesetzt. Genau. Und ich finde halt auch ein Punkt noch dazu, den ich spannend finde, ist, dass man ja auch so gesehen eigentlich eine
Effizienzsteigerung hat. Weil. In dem Moment, wenn ich das Vereinheitliche und. Verwendbar mache für andere und ich merke, ich brauch öfter in meiner Gesamtsoftware diese Funktion oder diese Daten die ich damit bereitstelle. Dann Steiger ich natürlich auch die Effizienz. Im Code selbst, weil ich weiß, OK, ich habe jetzt diese Anlaufstelle und. Ich implementier n neues Feature an einer anderen Stelle und so.
Ah jetzt brauch ich Daten XYZ ah ja OK warte das kann ich mir jetzt hierherziehen, das geht ja dann leichter von der Hand als wirklich jedes Mal wieder selbst zum Beispiel mühsam die Daten zusammen zu sammeln oder aufzubereiten. Wenn ich jetzt so eine zentrale Stelle dafür habe. Ja, auf jeden Fall. Und mit der Übersichtlichkeit, was du vorhin meintest, spielt oder spielst du wahrscheinlich auch darauf an, dass du im Endeffekt natürlich weniger Code hast. Also wenn du jetzt 5 * 10 mal
also 10 zeilen. Die Rauslagerst hast du natürlich nur einmal noch diese 10 Zeilen Code und dann halt eben immer noch diese Aufrufe. Ne das? Da liegt zwar auch ne Challenge drin, auch später, seid gespannt. Aber grundsätzlich ist das erstmal dieser positive Effekt, der dadurch entsteht. Würde ich sagen. Wie findest du generell dieses Prinzip erstmal so? Bevor wir jetzt natürlich auch noch das ganze Challengen wollen. Also grundsätzlich finde ich es sehr gut das im Kopf zu haben.
Also ich finde man sollte davon gehört haben, es muss ja jetzt nichts. Also ich finde man neigt ja immer dazu oder man will immer alles einen Namen geben und ein total cooles Prinzip daraus machen, aber der Kerngedanke der dahinter steckt, den sollte man auf jeden Fall immer im Kopf haben, ob man das jetzt Dryprinzip nennt oder nicht,
eigentlich egal, aber halt. Dass man auf Redundanzen achtet und halt auch berücksichtigt, ob man das Reflect dann kann und vereinheitlichen kann oder nicht finde ich ist schon sehr wichtig und wenn wir das jetzt dafür steht ja so gesehen, dass dry Prinzip, deswegen würde ich sagen, es ist auf jeden Fall ein wichtiger Prinzip. Ja, finde ich auch das sollte man auf jeden Fall im Kopf haben.
Was ich dabei auf jeden Fall, also wenn man jetzt mal übergehen und sagen, OK, es ist ein wichtiges Prinzip, aber. Es ist ja nicht einfach nur, dass man sagt, OK, es gibt dieses Prinzip und benutzt es immer. Dafür hätte ich direkt mal eine kleine Story, die ich mal erlebt habe, die mir auf jeden Fall total gezeigt hat, dass du do it yourself. Grundsätzlich do it yourself.
Das Don't repeat yourself zwar an sich ein gutes Prinzip ist, aber man das ganze Halt auch übertreiben kann oder so machen kann, dass es eigentlich wirkt in dem Fall überhaupt nicht mehr meiner Meinung nach und von einigen, die auch im Team dabei waren auch ein Business, so das Gefühl da war. Aber auch wir haben darüber gesprochen und wir haben halt so gesagt. Nette Idee, aber die Umsetzung ist schwierig. Da ging es um eine Tabelle und
diese. Tabelle hat der verschiedene Spalten, das heißt du hast Spaltenköpfe oben und es ging darum, dass du jede Tabelle ordnen solltest, ordnen können, also sortieren können solltest. Ne, also zum Beispiel alphabetisch der Größe nach. Was auch immer verschiedene Sachen und die Schwierigkeit dabei war, dass das zum Beispiel die Daten, die da drin standen in dieser Tabelle. Also wir hatten verschiedene Tabellen, und das war halt so,
dass diese Tabellen jeweils. Filter bekommen haben oder nicht Filter, sondern sortierreihenfolgen Möglichkeiten, die man anwenden konnte. Ne und? Dann war es aber so, dass du natürlich sagst, OK, du sortierst ja unter Umständen Strings anders als Zahlen oder sortieren.
Anders als vielleicht auch Objekte nach bestimmten Kriterien. Ja, und da war es dann aber so, dass diese, dass ein Kollege gesagt hat, OK, ich nehme alle Filter und Verallgemeinere diesen Filter so extrem, dass du am Ende alle Daten, die du haben wolltest, da reinschmeißen konntest, also sozusagen so ein sogenanntes Generic, und das war am Ende auf der einen Seite was cool, weil für die Anwendung, wenn du sagst, ok, ich will eine neue Tabelle erstellen.
Ein neuen neues Objekt in die Tabelle einfügen ne, also ne Spalte mit einem neuen Objekt was da Daten drin anzeigt dann. Konntest du das relativ schnell machen, aber irgendwann kamen wir an den Punkt, dass wir gesagt haben, wir müssen diese
Tabelle erweitern. Ja, und mussten in diesen Code reingucken und ich und ich glaub ich hab insgesamt mit 2 anderen Leuten dann über n paar Tage daran gearbeitet beziehungsweise da drauf geguckt und wir waren 3 gute Entwickler und haben uns echt schwer getan diesen Code zu verstehen und da muss man natürlich auf der einen Seite sagen okay Respekt an den einen Kollegen der das gemacht hat, dass er irgendwie das Skill Level auch hatte, diesen Code SUV zu verallgemeinern, also so
eine so hohe Abstraktion zu bilden, aber auf der anderen Seite hat es. Nicht wirklich uns was gebracht am Ende, sobald es an die Erweiterbarkeit ging, die wir ja auch schon angesprochen. Hatten ja. Die man ja eigentlich gewährleisten möchte, oder? Mit diesem Prinzip verbessern möchte. Und das ist halt wirklich ein großes Problem an diesem Drive Prinzip beziehungsweise eine Herausforderung.
So klingt es immer schöner. Man neigt halt schnell dann zu diesem Overengineering, dass du sagst okay ich. Hab jetzt hier eine Funktion, die habe ich jetzt in ähnlicher Weise an 2 stellen. Das ist nämlich auch das, was ich noch anmerken wollte zu deinem Beispiel vorhin angenommen, ich habe diese Funktion sehr ähnlich und merke, aber anstelle A brauche ich sie so ein bisschen abgewandelt und anstelle b bleibt sie wie sie ist.
Und jetzt will ich die zusammenfügen, dann habe ich ja eine Art Varianz drin oder so optionale Stränge und dann geht es halt los, dann denkst du ja okay, dann machen wir, dann abstrahieren wir das, dass die Grundfunktion gleich ist. Das ist mein zentrales. Denkt.
Und dann kann ich davon ableiten, beispielsweise und so weiter und dann kapselst du das immer weiter und abstrahierst das immer weiter und dann wird es nachher so n overengineering Prozess, dass es am Ende gar keinen Mehrwert mehr gibt, wenn ich wirklich mal wieder an die Kern oder an die ja doch an die Kernsubstanz diese eigentlichen Funktionalität ran muss und da was ändern möchte, wie du ja auch gerade in so einem großen Extrembeispiel genannt hast, dann brauchst du auf einmal
Ewigkeiten. Das überhaupt noch zu verstehen und quasi zu adaptieren, und das kann halt auch nicht der Sinn sein im Sinne von wir haben gut wartbaren Code, weil das ist auch nicht mehr wartbar. Dann am Ende, das heißt es ist immer so ein so ein Balanceakt finde ich zu sagen, bin ich an dem Punkt, wo ich wirklich dieses 3 Prinzip anwenden sollte oder muss und ich refecter jetzt mein Code und Lager das aus.
Oder bin ich eigentlich noch an einer Stelle, wo ich mich zwar so gesehen wiederholt habe, aber es an der Stelle keinen Sinn macht, das zusammenzufassen, weil einfach nur ganz andere Probleme dann auf mich zukommen? Das ist halt im ersten Schritt zwar besser. Aber dann eigentlich der Software am Ende oder dem gesamten Quellcode schadet.
Ja, und das ist finde ich ein Spagat, den man da macht, das ist nicht so einfach und deswegen dieses Drive Prinzip sollte man auf jeden Fall im Kopf haben, aber man sollte da mit einem gesunden Maß rangehen finde ich und das auch mal kritisieren ob es denn wirklich immer die richtige Entscheidung ist das umzusetzen sozusagen. Definitiv also allein schon so eine grobe Daumenregel zu sagen, du hast es, du hast, sage ich jetzt mal einen Code ein, also ein Codeabschnitt.
Mal in deiner Software OK, don't repeat yourself, auf jeden Fall nicht logischerweise, du hast es zweimal, macht eigentlich noch keinen Sinn, weil du weißt ja noch gar nicht, ist es jetzt so, dass sich dieser codeblock halt wirklich noch vermehrt oder nicht? Braucht man den wirklich noch an
anderen Stellen? Muss ich mir jetzt schon den Aufwand machen, das Ganze sozusagen zu abstrahieren, abzukapseln, wie auch immer hast du es dreimal drin, würde ich sagen okay die Tendenz geht auf jeden Fall. Lasst uns das mal rausziehen in den eigenen Bereich.
Ja, das ist nämlich ein guter Punkt, weil 3 ist bei mir auch so ein Schwellenwert, wo die Überlegung losgeht, wo ich mir denke, okay, jetzt ist es schon dreimal drin und es ist schon sehr ähnlich und dann ist es ja so auch gerade mit steigender Erfahrung, dass wir ja schon im Kopf ungefähr hast, wie du das rausziehen könntest, was du machen müsstest, wie du es referdern müsstest und wegst dann, oder ich fange dann so an, quasi abzuwägen. Ist das? Lohnt sich das oder lohnt es sich nicht?
3 ist da so bei mir so ein bisschen Schwellenwert, ganz ehrlich. Zweimal drin ist, dann ist es zweimal drin. Ja genau, mittlerweile früher, so sag ich mal n paar Jahre zurück, wenn man sagt ich möchte unbedingt super cleancode schreiben und ich möchte ne richtig geile codebasis haben, wie man ja auch so quasi so ein Entwicklungsschritt hat und sich super viele Gedanken darüber macht. Da dachte ich mir es ist doppelt ich habe ein Duplikat, jetzt muss ich das zusammenpassen,
also so richtig. Wirklich straight diese Prinzipien durchsetzen und dann machst du aber auch relativ schnell die Erfahrung. Geil ist das auch nicht, weil dann hast du auch schnell mal einen sehr komplexen Code, der im Nachhinein kein Stück besser ist als es vorher war. Also du hast keine richtige Rabbit hole, wären dann
definitiv. Ich sag mal so, es ist ja natürlich auch so. Lassen wir mal die Kirche im Dorf, es kommt ja immer noch vor, dass man vielleicht auch mal man ist im Eifer des Gefäß, und dann findet man auf einmal 5 stellen, ich nenne jetzt einfach irgendeine Zahl, die größer als 3 ist. Code, wo man sagt, Oh warte mal irgendwie. Na ja, das muss ich wohl noch
mal aufräumen. Das typische Refactoring, es kommt ja dahin oder man man merkt vielleicht später so OK warte mal das was ich hier mache und was ich da mache und was ich dort mache. Sehr, sehr ähnlich und ich kann es schon vereinheitlichen. Also das ist nicht immer zwangsläufig. Die Intuition ist, dass es von vornherein das gleiche ist und man dann direkt sagt, Oh, das müssen wir ja, ich weiß ja, dass das auf der anderen Stelle im Code oder in meiner Software auch schon so da ist.
Also. Diese Gedanken. Manchmal ist man im Eifer des Gefechts, hat es gerade nicht im Kopf und merkt es später. Und dann ist halt auch hilfreich zu sagen, beim Refactoring zu Challengen kann ich das jetzt zusammenfassen, kann ich jetzt sozusagen Don't repeat yourself anwenden. Und da. Habe ich noch mal eine interessante Frage an dich. Kennst du das, dass du 2 verschiedene Arten hast? Dieses also oder 2 verschiedene Codesstücke, die sehr ähnlich sind, aber vom. Kontext her doch sehr
verschieden. Also du meinst, dass man quasi auf den ersten Blick sagen würde, man kann die sehr einfach zusammenfassen, weil. Sie doch von der Funktion, wenn man auf den ersten Blick ähnlich aussehen, oder wie? Genau. Ja, kenn ich. Und oftmals ist aber auch die Antwort, nein kann man nicht oder es würde halt sehr sehr komplex und abstrakt werden, um
das zu machen. Also wie gesagt das ist n Prinzip in meinen Augen und es ist eher wichtig sich Gedanken darum zu machen, das heißt erst mal zu challengen ob es denn funktioniert und der bessere Weg wäre das jetzt so zu refactern wenn aber die Antwort ist ganz ehrlich, das bringt nur Chaos rein nur um diese Funktion zusammenzufügen und dann wären
die Aufrufe kompliziert. Irgendwelche Abstraktionsebenen einbauen, dann weiß ich nicht, ob da der Mehrwert so groß ist am Ende oder ob ich mir andere Probleme denn einkaufe. Und das ist halt so n klassischer Fall beim Refactoring wie Du meinst, dann findest du auf einmal mehrfach stellen. Wo ähnliches passiert und dann entwickelst du so n Gefühl dafür und sagst Mhm ah, das müsste man glaub ich noch mal refactern das das kann man.
Ich glaub das kann man irgendwie zusammenbringen so absolut legitim und das passiert immer wieder, es ist ja nicht so, dass du Code schreibst und quasi festsetzt, so nach dem Motto, Ja jetzt habe ich es zweimal verwendet, aber ich werde es auf jeden Fall nicht noch mal verwenden, ich muss es nicht, ich muss jetzt nicht nach Dry quasi refectern oder?
Ich habe gerade eine Zeile Code geschrieben, das war Nummer 3 und jetzt refect dann natürlich ist es so nicht wie wie man jetzt in der Theorie quasi das erklärt, aber gerade im Refekter Schritt wirst du sowas ja irgendwann merken und dann musst du es meinen Augen abwägen. Das ist dann genau dieser Balance Akt dahinter. Also ich finde zum Beispiel auch, dass sinnvolles, sich darüber Gedanken zu machen.
Manchmal finde ich es aber auch sinnvoll, das sind auch nicht zu krass zu durchdenken, weil manchmal sitzt man vielleicht davor und denkt sich und so und dies und das vielleicht auch einfach mal anfangen. OK, warte mal, das sind jetzt 2 verschiedene Sachen. Ich glaube die kann man vereinheitlichen und dann einfach mal ausprobieren.
Ne manchmal. Also mir mir persönlich hilft das auf jeden Fall, es wäre n Ansatz den ich auch weiterempfehlen kann und dann vielleicht auch hinterher zu merken na Moment. OK, ich hab jetzt zwar Zeit investiert und es ist jetzt diese Zeit nicht wert gewesen, weil ich zu dem Schluss gekommen bin, es funktioniert nicht so richtig oder ich hab es mir anders vorgestellt.
Aber nichtsdestotrotz lernt man ja genau aus diesen Sachen auch sehr, sehr viel, dass man es einfach mal macht und entweder es schafft und sagt, OK, nee, das war das war ne gute Idee und ich hab es durchgezogen und es gefällt mir wirklich besser oder dass man sagt, ich hab es probiert, aber es ist irgendwie nicht so geil, weil als kleines Beispiel, wenn du einen sehr ähnlichen Code hast und dann aber am Ende eine Funktion rauskommt, der du noch ein bool Fleck übergeben musst um zu
sagen aber. Bitte an der Stelle A und an der anderen Stelle in dem Fall B. Dann ist das ja nach Cleancode. Übrigens haben wir auch eine Reihe dazu cleancode hört euch lieber, hört euch die Anwendung interessiert, Liebe zuhören, lieber Zürcher, dann ist das nach Cleancode natürlich auch keine gute Praxis diese bool Variablen einzubauen, nur um an
einer. Stelle. Genau. Nur um an einer Stelle mal zu sagen, Nimm die oder die Abzweigung, aber der Rest des Codes ist gleich gleich beispielsweise. Und in solche Fallen nenne ich das jetzt mal, bin ich auch schon gelaufen, dass ich mir dann dachte, das kann man super vereinheitlichen und dann kann ich aber an den Punkt, da ich mir dachte. Na, sieht irgendwie jetzt aber nicht mehr so geil aus, wie ich mir erst dachte.
Also du hast es zwar vereinheitlicht, aber die Anwendung dieser Vereinheitlichung war überhaupt nicht intuitiv am Ende. Ja, der ist n absolut klassisches Problem. Was ich früher auch viel hatte, weil du meintest einfach mal anfangen. Hatte halt so ne Phase wo ich alles immer so super akkurat machen wollte und so richtig clean coden wollte.
Ne, also ich wollte halt so richtig geilen Code schreiben auf gut Deutsch und dann fängst du und die Falle oder die Falle dabei ist zu sagen okay ich schreib ne Funktion und dann denkst du im Kopf so. Hab das Gefühl, das könnte ich
noch mal gebrauchen. Ich muss das jetzt gleich schon so auslagern, damit das später, damit ich das nicht doppelt schreibe, die Funktion und mach's dir schon über Sachen Gedanken, die einfach noch gar keine Rolle spielen und da kommen auch so andere Prinzipien rein, da können wir auch gerne mal folgen zu machen, zum Beispiel das Kiss Prinzip, Keep it simple, stupid, weil an der Stelle mach's doch erstmal so einfach, mach doch erstmal den Progress und lass doch die
Funktion so es wird sich zeigen ob du das Refact. Dann musst dann beispielsweise nach dem. Prinzip, weil Refactoring wird für immer dazugehören. Es ist einfach ein fester Bestandteil der Softwareentwicklung, also ist es auch OK zu Refectern in meinen Augen, oder also weißt. Du definitiv. Also nicht die. Nicht Schrödingers Don't repeat yourself machen. Muss das werden oder nicht? Kann man es denn auslagern, oder? Das werden wir erst erfahren, wenn wir die Kiste öffnen.
Aber ich find halt auch, und das ist auch find ich einfach NN sehr, sehr wichtiger Leitsatz irgendwie. Klar kann man Sachen Refectern vereinheitlichen, sozusagen Don't repeat yourself anwenden, aber ich finde darüber über diesem Prinzip steht immer noch, wie gut kann ich diesen Code
lesen. Genau, also es kommt vielleicht noch n bisschen drauf an, weil wenn du sagst ey ich schreib jetzt ne Library und diese Library ist abgekapselt, da wird eigentlich nicht mehr dran gearbeitet, die ist sozusagen in Stein gemeißelt und die wird heute da sein und die wird morgen da sein und die wird in 100 Jahren noch da sein.
OK, optimier Sie bis zum Umfallen meinetwegen, aber wenn du ne Software hast, in der du am Team arbeitest, wo andere Leute immer wieder was erweitern müssen, die Software muss muss verstanden werden. Der Code meint Ich muss verstanden werden, dann ist die Lesbarkeit deutlich darüber über Abstraktion und Vereinheitlichung und sonst? Was ja das erschwert ja auch im Team die Zusammenarbeit, wenn man es mal so betrachtet. Mal angenommen, du würdest alles
so krass abstrahieren. Dass du alles so auf einzelne Punkte zurückführst und dann willst du jetzt verschieden daran entwickeln oder weiter anstellen in deiner Software und dann kommst du immer wieder auf diesen einen Punkt. Das kann ja auch zu Konflikten führen am Ende, was vielleicht unnötig ist, weil du es gar nicht so hättest auf so einer hohen Abstraktionsebene programmieren müssen.
Es ist ja, wie auch wenn du mit jemandem sprichst, kannst du ja eine sehr hochgesprochene Sprache verwenden. So und am Ende weiß keiner, was los ist. Und am Ende denkt sich jeder so etwas. Was will der jetzt von mir sagen? Du kannst es doch einfach mit normalen. Orten sagen und jeder versteht, was du meinst.
Und dann kommst du ja meistens weiter und so sehe ich das halt beim Code am Ende auch, weil es bringt dir ja nichts, wenn du dich hinstellst und sagst, guck mal wie unglaublich elegant ich programmieren kann, was für unglaubliche Tricks ich drauf habe und der Rest deines Teams denkt sich so ja okay, dann kannst du dich in Zukunft selber um diese Klasse kümmern. Kollegen ja genau dann Code alleine weiter, da steigt
niemand mehr durch. Absolut klassisches Ding, aber genau die Challenge. Dabei auf der anderen Seite kann man natürlich auch sagen okay. Genauso kann man sich natürlich auch hinstellen und sagen, dann erklär mir das mal. Vielleicht ist man ja auch selber einfach nur zu blöd. Wahrscheinlich aus der Sicht des Codes, der es gemacht hat, ja. Oh Mann ey, aber worauf ich noch eingehen wollte ist, weil Don't repeat your safe. Das klingt auch ein bisschen
irreführend. Also ich verstehe das Prinzip, aber nicht so, dass man. Nie quasi doppelten Code drin haben sollte oder Duplikate. Deswegen meinte ich auch, man darf das auch nicht verwechseln, es gibt nämlich glaube ich auch so ein. Only One oder so heißt das Prinzip. Was halt wirklich sagt.
Nein, es wird alles nur einmal gemacht, es gibt keine Duplikation, aber das Dry Prinzip verstehe ich gar nicht so, sondern wenn es gegeben ist durch unterschiedlichen Kontext oder so, dann kannst du das, dann musst du dich wiederholen, aber dann ist es so gesehen auch keine Wiederholung, weil es einem anderen Kontext dient, auch wenn dir zum Beispiel die Funktion sehr ähnlich ist oder von mir aus auch identisch, aber irgendwie in dem Rahmen in dem Kontext, in dem man sich bewegt,
eine Unterscheidung stattfindet, dann ist das doch völlig legitim auch beide drin zu haben. Der Unterschied ist ja, wie du schon meintest 5 war ne schöne Zahl. Übrigens wenn ich 5 mal exakt das gleiche mache, dann kann ich das Prinzip anwenden, ja. Also don't repeat yourself heißt nicht, du darfst niemals einen Variablennamen doppelt vergeben. Naja aber ja mal blöd gesagt. Also mal wirklich. Zugespitzt. Das sagt es halt nicht aus.
Ja, also wie gesagt, das ist auch immer noch da, spielt auch viel, wie wir es ja eben auch schon angeschnitten haben, eine Zusammenarbeit, eine Rolle im Team, weil ich finde zum Beispiel auch, das ist mir eben noch so ein bisschen entfallen oder lag mir noch auf der Zunge, es kommt natürlich auch immer ein bisschen auf die Projektgröße, die Teamgröße drauf an, weil angenommen, du hast wirklich eine Software, an
der du alleine arbeitest. Dann kannst du natürlich angenommen, du bist jemand, der sehr stark gerne. Agiert kannst du das sicherlich machen. Ne, dass du sagst, OK, das ist irgendwie auch in Anführungsstrichen meine Software, da kann ich mit machen was ich möchte so dann ist das in Ordnung.
Blöd wird es finde ich, wenn du an den Punkt kommst wo du dann einfach sagst OK. Egal, was die anderen sagen, ich setze jetzt ne hohe Abstraktionsebene auf und ist mir egal ob die da nicht durchsteigen. Also da finde ich sollte man auf jeden Fall auch immer gucken, also nicht immer ne, sondern in bestimmten Situationen zum Beispiel auch das Beispiel noch mal sozusagen den.
Rahmen zu schließen das Beispiel von vorhin, was ich angesprochen hab, wäre schön gewesen, wenn man einmal kurz über es war ja auch ne recht große Veränderung n recht großes Refactoring dann weil es wurde ja auch sehr viel dann angefasst, weil wir einige Tabellen irgendwo hatten, ja, dass man da vielleicht auch dann einmal im Team drüber spricht und sagt Okay, wie wäre es denn, ich hätte da eine Idee, sich die Idee anzuhören, im Team einen
Konsens zu bilden und zu sagen. Lass uns das bis dahin machen, aber vielleicht nicht weiter. Das ist auch ein ganz cooler Punkt, den du ansprichst. Und zwar wir haben ja gesagt, das ist so ein Abwägen, also so eine Balance zwischen. Ich hab quasi eine hohe, wie soll ich sagen, Lesbarkeit und Verständlichkeit. Also ich ich verstehe was da drin passiert und auf der anderen Seite.
Habe ich dann halt so diese Aspekte, der zum Beispiel die Wartbarkeit, die erhöht wird, wenn es nur ein Punkt ist, was wir so als Vorteil genannt haben. Und jetzt habe ich so diese Gegenüberstellung und ich finde, das muss man halt ausbalancieren, zu sagen, ist mein Code noch verständlich und. Habe ich zum Beispiel Dry angewandt, um die Wartbarkeit und die Fehleranfälligkeit, also die Wartbarkeit? Erhöhen und Fehleranfälligkeit.
Verregert so ne und das musst du irgendwie ausbalancieren und ich finde, das ist eigentlich die Schwierigkeit dabei, diesen Mittelweg zu finden. Und weil du jetzt die Teamarbeit genannt hast, finde ich es zum Beispiel echt cooler Aspekt, wenn man sagt okay, wir machen jetzt Code Reviews, weil dann guckt man da zusammen drauf und erkennt vielleicht ja ne, hier können wir das Re factor, hier können wir das zusammenfügen. Wenn man sich einfach auch Meinungen von anderen aus dem
Team einholt. Um zu entscheiden. Ist. Diese Duplikation jetzt in Ordnung, ne, also Redundanz ist ja nicht zwangsläufig immer schlechter. Also ich finde man darf das halt nicht so engstündig betrachten, sondern man muss dann entscheiden, ist es an der Stelle gerechtfertigt oder haben wir einen Cooleren weg, indem wir das zusammenfassen? Definitiv. Ich finde, das ist ein ganz Gutes, das rundet die Sache ganz gut ab.
Dankeschön. Dankeschön. Also im Endeffekt ist es ja so, wenn wir uns das ganze jetzt noch mal, wenn wir das ganze jetzt noch mal Revue passieren lassen. It yourself don't repeat yourself Prinzip. Ich will immer do it yourself sein. Das Don't Repeat yourself Prinzip ist ja im Endeffekt dafür da, dass man hauptsächlich Redundanzen vermeidet. Die Erhöhung der Wartbarkeiten. Gewährleistet und auch Erweiterbarkeit und auch eine Fehlervermeidung. Irgendwie.
Dadurch schafft bei der Erweiterung oder der Wartung, und das ist natürlich auf jeden Fall auf der haben Seite, und es ist natürlich ein Prinzip, was man definitiv bei der Programmierung immer im Hinterkopf haben sollte, so, aber vielleicht möchtest du noch mal ganz kurz zusammenfassen, wo man vielleicht darauf achten könnte, wenn man das denn an, also wo die Herausforderungen liegen. Ja, also wie gesagt, die Challenges dabei sind.
Kann zwar eigentlich immer N-Weg finden es zusammenzufassen, aber die Frage ist leidet darunter die verständlichkeiten Lesbarkeit, das heißt, dass andere auch Probleme haben diesen Code dann nachzuvollziehen, also dass man halt nicht in diese Reporter geht und sagt zum Beispiel, ich abstrahiere jetzt alles, damit alles aus einer Funktion aufgerufen werden kann, dann parametrisiert man die und dann ist geil. Dann habe ich eine Funktion für die gesamte Software, jetzt war ganz überspitzt.
Overengineering. Style genau das ist halt den wirklich. Over engineering at its best. So, und das macht halt den einfach auch gar keinen Sinn mehr, deswegen so als Take Home Message. Redundanzen sind nicht zwangsläufig schlecht, also man darf nicht so engstirnig an die Sache rangehen und sagen, ich darf das auf gar keinen Fall machen, das habe ich früher mal eine Zeit lang gemacht, weil ich dachte okay, sonst ist es nicht gut gecoated, aber das stimmt in meinen Augen einfach nicht.
Aus meiner Sicht ist das nicht richtig, das so zu betrachten, sondern. Es ist eine Richtlinie, es ist ein Wegweiser und. Es animiert halt, sich die richtigen Gedanken zu machen, zum Beispiel beim Refactor. Ja, find ich gut. Weise Worte, mein Herr.
Danke, danke. Und es ist halt wie gesagt Kontextabhängig auch n wichtiger Punkt nicht von Projekt zu Projekt kannst du sagen OK ich hab jetzt wieder so ne Art Datensammlung hier, ähnlich wie beim anderen Projekt, da jetzt auf jeden Fall Drive soweit, das kann halt wieder unter anderen Gegebenheiten komplett anders aussehen, definitiv mehr habe ich auch dazu nicht also ich denke wir haben das eigentlich relativ kleine Prinzip ausführlich besprochen und ich.
Finde es auch gut, dass wir das auch kritisch beleuchtet haben, weil wie gesagt, das muss man auch mal aus der Sicht betrachten. Ja, es ist ja nicht immer alles Gold, was glänzt oder wie es so schön heißt, selten, dass ich mein Sprichwort richtig sage. Es ist nicht alles drivers. Glaube ich. Genau so sagt man eigentlich so. Sagt man eigentlich. Ja, dann würde ich sagen, wenn du auch nichts mehr hast, würde ich auch die Folge jetzt beenden, ja. Danke für den.
Haus ja ausführlich beleuchtet ja, vielen Dank auch für deine Geschichte mit der Tabelle, weil das war ein super Beispiel. Waren es denn vielleicht doch zu extrem wird. Ohne jetzt dem Entwickler zu nahe treten zu wollen, weil er hat es ja scheinbar auch echt geil gecoded, aber das ist halt so. N klassisches Beispiel von andere verstehen es irgendwann. Nicht mehr, dann hast du keine Frage, ne, das will ich damit ja auch gar nicht sagen, nur an der Stelle hat es halt im Team nichts.
Gebracht ne genau und das ist genau der Trade, auf dem man dann hat irgendwann. Ja, ansonsten liebe zuhören, Liebe zuhören. Falls du Anmerkungen hast zum Drive Prinzip, Ergänzungen oder vielleicht auch Erfahrungen gemacht hast, wann es dir geholfen hat und wann nicht, dann lass uns das doch gerne wissen.
Die Mail findest du wie immer, also die Mail vom Podcast in den Shownotes schreib uns gerne, wir würden uns freuen, wir werden auch darauf eingehen, dann Diskussionen sind immer herzlich willkommen, ansonsten wenn du sonst Feedback hast, lass uns das auch gerne zukommen, empfehle auch gerne wenn dir Podcast gefällt. 2 oder 3 Leuten diesen Podcast weiter, das würde
uns auch sehr freuen. Ansonsten findest du in den Show Notes auch noch einen Link. Da hast du die Möglichkeit eine kleine Spende zu hinterlassen, falls dir das zusagt, was wir hier machen und möchtest, dass noch weitere Folgen entstehen. Weil das hilft uns auf jeden Fall, unseren Content zu
verbessern und dranzubleiben. Es macht uns ja auch ne Menge Spaß und ansonsten würde ich sagen, hören wir uns alle beim nächsten Mal wieder und bis dahin bis zum nächsten Mal deine Coding Buddies. Gemeinsam besser. Was?