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?