Latest / Coding Buddies | Tech & Dev-Mindset / Das DRY Prinzip - Effizienz oder Stolperfalle?

Transcript

Das DRY Prinzip - Effizienz oder Stolperfalle? · Coding Buddies | Tech & Dev-Mindset

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