Latest / Coding Buddies | Tech & Dev-Mindset / #157 IOSP - Das Coding Prinzip das wir nicht kannten (und trotzdem kickt)

Transcript

#157 IOSP - Das Coding Prinzip das wir nicht kannten (und trotzdem kickt) · Coding Buddies | Tech & Dev-Mindset

• 0:00
  Heute sprechen wir über ein Clean Code Prinzip, das er
• 0:02
  ehrlich gesagt selbst noch gar nicht kann.
• 0:03
  Dabei ist die Idee eigentlich relativ simpel, es ist das
• 0:05
  Integration, Operation, Segregation, Principle oder
• 0:08
  kurz. Iosp Coding Buddies Dein Podcast
• 0:13
  rund um Softwareentwicklung und aktueller Tech News.
• 0:15
  Herzlich Willkommen. Moin Moin und herzlich
• 0:30
  Willkommen zur neuen Folge des Coding Buddies Podcasts.
• 0:34
  Schön, dass du wieder eingeschaltet hast.
• 0:35
  Liebe Zuhörer, liebe Zuhörer, deine Gastgeber.
• 0:38
  Wie soll es auch anders sein, meine Wenigkeit, der Tino und
• 0:43
  der fantastische Fabi. Er lächelt mich an, wie immer
• 0:46
  seit Jahren schon, er hat Bock, er ist bereit, fabi, was geht
• 0:50
  ab, was geht ab? Was geht, weißt du, ich denk mir
• 0:54
  so bestimmt, wenn. Wenn so Leute angekündigt
• 0:57
  werden, weißt du im Fernsehen bei irgendeiner Show oder so.
• 0:59
  Ja, genau so muss ich das anfühlen.
• 1:01
  Ja, du kannst nicht anders als zu grinsen und dir zu denken, so
• 1:04
  okay es geht los. Also meinst du ich hab Potenzial
• 1:07
  das zu machen? Ja, auf jeden Fall.
• 1:09
  Vielleicht werde ich so professioneller Ankündiger neben
• 1:11
  dem Podcast noch, aber dann kann man den Buchen, um angekündigt
• 1:15
  zu werden dann. Kann man mich buchen um.
• 1:19
  Rauszulaufen ich lauf raus, egal froh.
• 1:26
  Genau, man bucht eigentlich nur das Paket, dass ich dich
• 1:28
  ankündige und du dann immer so erscheinst.
• 1:30
  Ja Jo, was geht ab, hat gar nichts mit dem Thema zu tun.
• 1:36
  Okay das waren die 2 wieder, jetzt geht's weiter.
• 1:39
  Lass uns. Weiter geht nicht im Programm.
• 1:41
  Die Na, wie geht's dir die Nachricht?
• 1:45
  Gut, gut soweit, hab gut Laune. Warum schön einfach so einfach
• 1:49
  so. Aber weißt du es, ich finde, es
• 1:51
  ist wichtig, auch einfach mal gute Laune zu haben und ich find
• 1:54
  es auch immer krass, wenn Leute einfach fragen, was ist mit dir
• 1:56
  los, ja was? Gehört sich diese dolle?
• 1:59
  Laune heute ja und ja, was denn passiert ja nichts, ich hab
• 2:02
  einfach gute Laune, ist einfach n schöner Tag.
• 2:04
  Es ist zwar super kalt irgendwie heute wieder, ich weiß auch
• 2:07
  nicht was da los ist. Die.
• 2:10
  Frage ist ja. Wenn sich Leute darüber wundern,
• 2:12
  dass jemand gute Laune hat, heißt das dann nicht eigentlich
• 2:15
  das andere, dass die Leute, die gefragt werden, eigentlich
• 2:18
  ursprünglich immer schlechte Laune haben und das jetzt so n
• 2:21
  Ausreißer ist, dass die Person ne gute Laune hat?
• 2:23
  Gute Frage, gute Frage oder erwartet man halt von dir?
• 2:28
  Ja, man erwartet vielleicht von der Person, dass sie schlechte
• 2:30
  Laune hat und ist dann verwundert, dass sie gute Laune
• 2:33
  hat, was bei dir aber nicht der Fall ist, weil wie gesagt, du
• 2:35
  hast eigentlich immer sehr oft gute Laune, was sehr angenehm
• 2:38
  ist. Danke.
• 2:41
  Und diese gute Laune möchte ich auch nutzen, um mit dir heute
• 2:44
  mal n richtig cooles Thema zu besprechen.
• 2:45
  Weil heute geht es um n Thema warte.
• 2:47
  Ganz kurz Nino, Sag kurz das Thema ja und dann will ich noch
• 2:52
  eine Sache kurz sagen, bevor wir richtig reinstarten.
• 2:55
  OK, krass, heute haben wir n Community Thema.
• 2:57
  Es ist n Wunsch aus der Community und was ich halt an
• 3:00
  dem Thema so besonders cool finde ist, dass ich absolut
• 3:03
  keine Ahnung hab worum es ging anfangs also ich hab davon noch
• 3:06
  nie gehört, du glaub ich auch nicht.
• 3:09
  Aber wir wollen heute mal wieder über ein Coding Principle, weil
• 3:13
  ja also ein Prinzip der Softwareentwicklung sprechen.
• 3:16
  Wir haben ja schon einige besprochen, ja, also wir hatten
• 3:20
  Drive, wir hatten Kiss, wir hatten Solid, jagten die also
• 3:23
  die ganzen Klassiker hatten wir ja hier im Podcast schon
• 3:27
  besprochen, also, liebe Zuhörer, liebe Zuhörer, falls du Bock
• 3:30
  hast auf n paar Coding Principles, die haben wir hier
• 3:33
  schon besprochen im Podcast, aber heute geht es um ein.
• 3:37
  Prinzip was ich echt noch nie gehört habe, aber vorher dein
• 3:39
  Punkt bevor wir es vergessen, weil dann können wir so richtig
• 3:41
  reinstarten. Genau also was ich sagen wollte,
• 3:44
  wenn dir das jetzt bekannt vorkommt, diese ganzen anderen
• 3:46
  Prinzipien, du hast vielleicht die Folgen schon gehört oder ist
• 3:48
  das jetzt hier deine erste Coding Buddies Folge und du
• 3:51
  denkst dir aber so, ja ich will diese anderen folgen aber noch
• 3:53
  mal hören interessiert mich gerade, dann lass auf jeden Fall
• 3:56
  ein Follow da, das hilft uns auf jeden Fall, aber vor allem auch
• 3:59
  dir, liebe Zuhörer lieber Zuhörer, weil du dann quasi
• 4:02
  nichts mehr verpasst. Also denk dran und.
• 4:05
  Tino, Ich würd sagen, jetzt ja, starten wir in das Prinzip rein,
• 4:09
  hau mal raus was. Ist das ja.
• 4:13
  Und zwar geht es heute um IOSP ja, und ich möchte mit dir
• 4:16
  einfach mal klären IOSP, oh mein Gott, klingt erstmal cool, aber
• 4:20
  was ist das überhaupt? Warum existiert noch ein
• 4:23
  weiteres Prinzip, weil ich glaub ich hab jetzt 4 gelistet, die
• 4:26
  wir alleine nur in diesem Podcast behandelt haben, weil es
• 4:28
  halt sehr gängige sind, es gibt ja noch viel mehr und.
• 4:33
  Bringt es wirklich was? Also das coole ist ja dadurch,
• 4:36
  dass wir uns damit noch nie beschäftigt hatten oder es
• 4:38
  irgendwie an uns so n bisschen vorbeigerauscht ist.
• 4:41
  War es jetzt echt cool sich das anzuschauen, jetzt mit dir zu
• 4:44
  besprechen und dann einfach mal n Fazit zu ziehen, bringt das
• 4:48
  was oder ist es nur so? N weiteres Prinzip was irgendwie
• 4:51
  na ja OK cool zu wissen, aber ist jetzt nicht notwendig so ne
• 4:56
  also das Fazit würde ich gerne mit dir am Ende ziehen aber.
• 5:00
  Lass uns mal anfangen. Was ist also jedes Prinzip hat
• 5:03
  ja ne gewisse Grundidee und da würde ich dich mal bitten mir
• 5:07
  das noch mal zu erklären und natürlich auch den Zuhörern.
• 5:10
  Also IOSP. Ja, es steht ja für oder IOS.
• 5:14
  Steht ja für Integration, Operation und Segregation.
• 5:18
  Also es ist auf jeden Fall sehr viel Asian da drin.
• 5:20
  Ja, das geht nicht so sonst. Nur für zungenbrecher.
• 5:26
  Reimt sich das oder reimt sich das nicht?
• 5:28
  Ich weiß es gar nicht, es ist reimt sich theoretisch oder
• 5:30
  reimt. Auf, Na ja, Reim, weil es immer
• 5:33
  die gleiche Wortendung ist, direkt off topic, da würd ich
• 5:36
  schon sagen, das sind aber keine guten Reime, ne, also wenn du
• 5:38
  immer die gleiche Endung nimmst, dann ist so na ja so hausmaus
• 5:41
  mäßig. Weißt du ja.
• 5:43
  Also der beste Reim ist ja auch, dass Haus sich am besten auf.
• 5:45
  Haus reimt also ja. Also OK ist ne.
• 5:49
  Sichere Sache Off. Topic Ende.
• 5:53
  Und zwar die Grundidee ist eigentlich relativ einfach, von
• 5:57
  diesem IOSP oder IOS Principal, und zwar sagen wir mal, dass du
• 6:03
  ne Funktionalität hast, ja, die entweder also oder eine Funktion
• 6:07
  hast, die entweder Integration oder Operation ist.
• 6:10
  Das heißt, eine ganze Gesamtfunktionalität wird
• 6:12
  irgendwie auch unterteilt, dann am Ende zwischen Integration und
• 6:15
  Operation, ne, dass du dann sagst, OK.
• 6:18
  Du du willst. Irgendwas erreichen.
• 6:21
  Hast aber ne klare Trennung zwischen diesen beiden Dingen.
• 6:24
  Ja, was das jetzt ist das da gehen wir gleich noch drauf ein
• 6:27
  Segregation ist halt diese ne die Trennung am Ende und
• 6:31
  Operation bedeutet im Endeffekt hier passiert die eigentliche
• 6:35
  Logik ne das heißt alles was sozusagen Operation ist ist am
• 6:38
  Ende wirklich Logik die dahinter steckt, also zum Beispiel
• 6:41
  Business Logik, es geht um Berechnungen, Entscheidungen,
• 6:44
  Transformationen frag mich nicht irgendwie sowas ne.
• 6:49
  Und Integration ist dann im Endeffekt so das Gegenteil.
• 6:52
  Hier wird, da wird sozusagen an der Stelle von der Integration
• 6:55
  wird nur orchestriert, da wird im Endeffekt nur gesagt, OK pass
• 6:58
  auf, es wird jetzt Funktion a aufgerufen oder es wird Funktion
• 7:00
  B aufgerufen. Es ist im Endeffekt nur so ne
• 7:04
  Art. Ablauf, die irgendwie
• 7:07
  dargestellt. Wird ne, also du hast so
• 7:09
  vielleicht. Als kleine Analogie dazu in
• 7:12
  einem Restaurant ne, das ist ja unser Ding, wir gehen ja gerne
• 7:15
  essen jetzt. Wird es wieder spannend?
• 7:18
  Hau. Raus, dass du sagst, du hast
• 7:20
  halt. Du hast zum Beispiel n Koch und
• 7:21
  n Kellner ne, sowas haben wir eben öfter mal schon mal gehabt,
• 7:24
  aber man kann es halt ganz gut erklären daran und der Koch
• 7:27
  macht halt eben das Essen. Ne das ist halt die Operation,
• 7:30
  also er tut diese Business Logik die Business Logik ist.
• 7:33
  Ich koche nehme die Zutaten des Essens und bereite das Essen zu
• 7:36
  Input Output so nach dem Motto Ne der Kellner allerdings.
• 7:40
  Ist halt hier an der Stelle die Integration der dann aber sagt
• 7:43
  OK Pass auf, du willst das und das Essen, ich leite das mal
• 7:46
  weiter an den Koch bitte das und das kochen, ja dann kommen
• 7:49
  mehrere Bestellungen rein. Ja es wäre ja zum Beispiel auch
• 7:52
  blöd wenn jetzt die letzte Bestellung als erstes an den
• 7:54
  Koch geht und die Person die als erstes im Restaurant war und
• 7:58
  bestellt hat aber als letztes quasi das Essen kriegt ne also
• 8:01
  es geht so n bisschen um diesen Ablauf, um die Organisation, was
• 8:05
  muss wann gemacht werden und der Koch.
• 8:07
  Ne, das war die jetzt also erstmal der Kellner Integration
• 8:10
  und der kocht die Operation, der bereitet dann im Endeffekt diese
• 8:13
  Dinge zu. Ne, ja genau 2 Köche, also nicht
• 8:17
  nur die Reihenfolge des Essens, sondern dass jeder auch sein
• 8:19
  richtiges Essen bekommt. Also gut, das find ich find das
• 8:25
  ist n gutes Beispiel, auch wenn es jetzt wieder Restaurant und
• 8:27
  Essen ist. Aber es zeigt halt ganz klar
• 8:30
  warum es Sinn macht ne also das Prinzip sagt Ja.
• 8:34
  So gesehen erstmal nichts weiter als trenne klar den Operation
• 8:39
  Anteil vom Integration Anteil und es kann niemals beides sein.
• 8:44
  Also n Koch kann nicht gleichzeitig auch n Kellner
• 8:46
  sein, Kellner kann nicht auch Koch sein also klar vielleicht
• 8:50
  kann ein Koch mal es gibt 2 Köche und der arbeitet heute als
• 8:53
  Kellner OK Diskussion ja OK. Aber in diesem Prinzip geht es
• 8:59
  halt darum, in dem Moment, wenn es sozusagen ausgeführt wird, ne
• 9:03
  oder halt auf Code ebene, dass ich sage, OK, das ist halt immer
• 9:05
  Integration, ja dann ist bei der Analogie n bisschen schwammig,
• 9:09
  aber ansonsten passt das. Ich stell mir das gerade so vor,
• 9:12
  dass der Kellner sagt, kann ich ihre Bestellung aufnehmen.
• 9:14
  Ah OK, eine Lasagne, vorzügliche Wahl, dann klebt, dass ich so n
• 9:17
  schnorrisser. Angebe der.
• 9:18
  Sie wird so aufgibt. Dann.
• 9:22
  Aber genau das ist, was du gerade beschrieben hast.
• 9:24
  Das Problem, was quasi dieses Prinzip adressiert, weil wenn
• 9:29
  man sich jetzt vorstellt, der Kellner nimmt die Bestellung
• 9:32
  entgegen, sagt vorzügliche Wahl, klebt sich den Schnorriss an und
• 9:35
  geht in die Küche, fängt an zu kochen und kommt dann irgendwann
• 9:39
  mit dem Essen wieder. Das wird natürlich irgendwann im
• 9:43
  Chaos, je mehr Interaktion sozusagen da ist, ne je mehr
• 9:48
  bestellt wird je mehr gekocht werden muss.
• 9:51
  Das ist ja dann am Ende kein klares Aufgabengebiet mehr, und
• 9:54
  das heißt, das wird irgendwann im Chaos versinken, sag ich mal.
• 9:59
  Das ist ja so das, was man versucht zu adressieren damit ne
• 10:02
  und man kann das ja auch ganze mal n bisschen technischer
• 10:06
  machen, ne also die Analogie ist ja immer gut um reinzukommen,
• 10:10
  aber jetzt nehmen wir mal n Beispiel, was schon sehr codenah
• 10:14
  ist, sag ich mal um das Ganze auch n bisschen zu
• 10:16
  verdeutlichen. Nehmen wir uns mal als Beispiel
• 10:20
  das hatte ich in einem Artikel gesehen das fand ich auch ganz
• 10:22
  gut wenn wir uns jetzt so ne Art rechnungssystem vorstellen ne
• 10:26
  dann hat ja so n System oder so ne rechnungssoftware zum
• 10:30
  Beispiel NEAP System oder was auch immer das jetzt am Ende ist
• 10:33
  ne hat ja am Ende verschiedene Bestandteile also beispielsweise
• 10:37
  kann es n frontend haben worüber ich denn meine Eingaben machen
• 10:40
  kann Es gibt n backend es wird ne Datenbank geben
• 10:43
  logischerweise wo Sachen gespeichert werden.
• 10:45
  Und wenn man sich jetzt vorstellt, wir haben so n
• 10:47
  rechnungssystem und wollen jetzt ne neue Rechnung anlegen, ja
• 10:51
  dann kann es natürlich sein. OK, das Backend sagt Pass auf
• 10:56
  create invoice, die Funktion hab ich für dich ja also einfach ne
• 11:00
  Rechnung erstellen, das klingt jetzt erstmal gut ja gut ich
• 11:03
  will ja auch ne Rechnung erstellen, hier hast du die
• 11:04
  Daten die du brauchst und jetzt erstell mal ne Rechnung so das
• 11:07
  ist für mich jetzt so der Ablauf.
• 11:10
  So, und das Backend denkt sich jetzt, OK, ich guck mal die
• 11:12
  Daten durch, ich analysier die Daten, ich mach vielleicht noch
• 11:16
  Berechnung sowas wie steuerberechnung ne das wird
• 11:18
  automatisch ermittelt, dass die Rechnung halt auch richtig
• 11:21
  ausgeschrieben ist sozusagen. Vielleicht werden noch Daten
• 11:25
  eingetragen, die irgendwie aus der Datenbank gezogen werden,
• 11:28
  sowas wie Kundendaten oder die Firmendaten ja, also was halt so
• 11:31
  auf ne Rechnung noch gehört und am Ende muss ja so ne Rechnung.
• 11:35
  Auch noch abgelegt werden. Ne, das heißt in deinem System
• 11:38
  im Endeffekt landet sie in der Datenbank und das sind ja jetzt
• 11:41
  so relativ viele Prozesse, die da passieren unter dem Wunsch
• 11:47
  eine Rechnung zu erstellen. Ne von oben sag ich mal was dann
• 11:51
  unter der Haube passiert ist ja schon ziemlich viel und da setzt
• 11:54
  jetzt das Prinzip an und sagt ja genau das ist das Problem, du
• 11:58
  machst jetzt. Einerseits Berechnung sowas wie
• 12:01
  Steuern, dann ziehst du noch Daten irgendwo her, gleichzeitig
• 12:05
  kümmerst du dich noch um das Speichern der Rechnung, das
• 12:07
  heißt du hast auch irgendwie Datenbank Zugriff und das ist
• 12:10
  einfach Operation, zum Beispiel die Steuerberechnung und
• 12:15
  Integration Zugriff auf die Datenbank, Sachen abspeichern,
• 12:19
  alles in einem ja und ich ruf die Funktion auf und hoffe
• 12:23
  einfach, dass es gut geht und hab auch keine Flexibilität.
• 12:26
  Zum Beispiel ne andere Integration zu machen, es nicht
• 12:29
  in der Datenbank zu speichern, sondern weiß ich was ganz
• 12:32
  woanders oder ich möchte ne andere Steuerberechnung haben
• 12:35
  oder so. Das ist halt alles sehr eng
• 12:39
  verkapselt so ja du musst. Halt sehr krass.
• 12:42
  Eingreifen dann am Ende in den Code, wenn du irgendwas ändern
• 12:44
  willst. Ich hab mir das ungefähr so
• 12:47
  vorgestellt, weil wir auch wie gesagt davon auch das erste Mal
• 12:50
  so, ich sag mal richtig gehört haben, also war uns ja kein
• 12:54
  Begriff. Und ich hab mir es ungefähr so
• 12:57
  vorgestellt dass du dann wenn du dieses IOSP nicht machen würdest
• 13:01
  ne dass du dann einfach sagst du hast zum Beispiel ne Funktion
• 13:04
  die heißt do everything ne so und das ist dann sozusagen auf
• 13:09
  der metaebene jetzt die Integration ne also die
• 13:13
  schlechte Integration die nicht vorhandene Integration weil die
• 13:15
  sagt mach einfach jetzt alles ne also egal was und dann werden
• 13:19
  halt ganz viele verschiedene Sachen gemacht dann wird gesagt
• 13:21
  ja OK aber angenommen du hast zum Beispiel.
• 13:25
  Variante a dann mach halt Variante A und ansonsten mach
• 13:28
  halt b oder vielleicht sogar C ne, dass dieses Ganze auf
• 13:32
  splitten, was eigentlich ne eigene Funktionalität irgendwie
• 13:36
  benötigen würde, dann im Endeffekt in Operation liegt.
• 13:40
  Ne, also in einer Schicht, die am Ende alles macht, so hab ich
• 13:44
  mir das zumindest vorgestellt. Genau.
• 13:47
  Und wenn man jetzt dieses ios p denn mal auf das Beispiel
• 13:50
  anwendet, ne und kein do Everything oder einen create
• 13:54
  invoice haben möchte, dann müsste man sich jetzt halt
• 13:57
  überlegen, wie kann ich den Operation Anteil und den
• 14:01
  Integration Anteil klar voneinander trennen, dass es
• 14:03
  halt sauber ist und ich quasi Funktionen habe, die immer nur
• 14:09
  entweder Operation sind oder Integration.
• 14:12
  So und dann kann man ja einfach mal so durchgehen, was hatte ich
• 14:15
  gesagt zum Beispiel? Steuern berechnen, das ist ganz
• 14:20
  klar ne Operation, ne, da darf da ist ne Logik drin, da ist ne
• 14:24
  Berechnung drin, also irgendeine Formel, wahrscheinlich auch noch
• 14:28
  irgendwelche Bedingungen und das sind alles Anzeichen bei dem
• 14:31
  Prinzip sagt man auch hast du sowas wie IF else drin, hast du
• 14:36
  ne Schleife da drin? Das sind oder richtige
• 14:40
  Berechnungen das sind alles Anzeichen für den Operation Teil
• 14:43
  und ich finde das klingt auch logisch also da gehe ich mit dem
• 14:45
  Prinzip ja auch voll mit das das würde ich auch sagen ja das ist
• 14:48
  Operation so ja also das sind logiken am Ende so und die
• 14:53
  orchestrierung wie du es genannt hast diese Integration ist ja im
• 14:56
  Prinzip sicherzustellen dass der richtige Ablauf passiert ne dass
• 15:01
  ich erst meine ganzen. Items nenn ich es mal berechnen
• 15:05
  und erstellen muss die auf die Rechnung gehören bevor ich
• 15:08
  überhaupt ne Rechnung anlegen kann, dass ich danach
• 15:11
  sicherstellen muss, dass es auch gespeichert wird in der
• 15:14
  Datenbank ist auch n extra Schritt und dann komm ich halt
• 15:17
  von einem do Everything zu calculate Texas, ich nenn es mal
• 15:25
  einfach so ne create invoice. Und so weiter.
• 15:30
  Und dann hab ich halt verschiedene Funktionen, die ich
• 15:31
  aufrufe. Safe Invoice von mir noch am
• 15:34
  Ende ne und dann kann ich das so aufrufen.
• 15:37
  Ich seh n klaren Ablauf, ich hab so n Integration ne Funktion die
• 15:40
  nur Integration macht, das heißt sie kümmert sich nicht darum wie
• 15:42
  es passiert, sondern was. Passiert nicht wie, sondern was,
• 15:46
  ja. Genau ne Ich hoffe es war
• 15:48
  richtig rum ja und das heißt es wird einfach nur gesagt das muss
• 15:53
  passieren das muss passieren das muss passieren ob bei Safe
• 15:56
  invoice das jetzt lokal auf der Platte abgelegt wird oder in
• 16:00
  einer Datenbank abgespeichert wird ist ja das wie und das
• 16:03
  interessiert den integrationanteil nicht und
• 16:05
  durch diese klare Trennung kann ich halt sagen ich kümmere mich
• 16:08
  um Integration oder ich kümmere mich um Operation und kann das
• 16:12
  getrennt und entkapselt voneinander betrachten was
• 16:15
  natürlich Vorteile einfach mit sich bringt.
• 16:17
  Ne. Was ich halt interessant finde
• 16:19
  ist wenn du dir das jetzt so überlegst dann hast du ja
• 16:21
  vielleicht irgendwie so ne Art sagen wir mal so ne Art
• 16:24
  baumstruktur ne du hast du fängst irgendwo an und dann wird
• 16:29
  durch die Integration halt erstmal so durchgetingelt und
• 16:31
  gesagt OK warte mal wir müssen jetzt das und das machen das
• 16:34
  kommt als erstes dann kommt das dann kommt dies oder jenes Na
• 16:37
  Moment vielleicht kommen wir jetzt aber auch an den Punkt wo
• 16:40
  wir diese Berechnung ausführen müssen oder diese ne dass du am
• 16:43
  Ende sozusagen in diesem? Ich nenn es jetzt mal, ist jetzt
• 16:48
  nicht fachlich ganz richtig, aber an diesem Entscheidungsbaum
• 16:50
  sozusagen irgendwo unten angekommen bist, wo dann diese
• 16:53
  tatsächliche Business Logik für diesen entsprechenden Case, der
• 16:56
  halt irgendwie jetzt relevant ist, am Ende angewendet wird?
• 16:58
  Ne, das konnte ich mir an sich auch ganz gut vorstellen, aber
• 17:04
  was mir da so in den Kopf kam war dann so OK.
• 17:06
  Warte mal, wir haben ja gerade gesagt, IF Else sind Dinge die
• 17:09
  irgendwie auf. Logik.
• 17:12
  Sagen wir mal, schließen lassen ist Operation.
• 17:16
  Wenn ich mir jetzt aber sage, OK, es ist also ne Art Baum, wo
• 17:19
  du immer nur sagst, OK, wir müssen irgendwie an ne Operation
• 17:22
  kommen, die dann am Ende ausgeführt wird, also halt
• 17:25
  irgendwie Entscheidungen checken müssen, OK das oder das ist für
• 17:30
  mich ja schon so ne Art. OK, entweder du machst das IF
• 17:33
  oder du machst das Else ne, also das heißt prinzipiell ist es ja
• 17:38
  vielleicht so n bisschen dann auch irgendwie aufgeweicht, weil
• 17:41
  du kannst ja gar nicht unbedingt sagen.
• 17:44
  Entweder das oder das. Wenn du kein FL verwenden darfst
• 17:47
  und es dann schon wieder Operation wäre, weißt.
• 17:49
  Du ja, und das find ich ganz interessant, weil beim
• 17:53
  Recherchieren quasi von diesem Prinzip bin ich auch drauf
• 17:57
  gestoßen, dass selbst die Verfechter und Begründer nenn
• 18:01
  ich es mal ne. Sagen ja.
• 18:05
  OK, das ist eine Stelle, wo quasi auch so Entscheidungen in
• 18:09
  den Integration teil kommen können, weil sonst stellt sich
• 18:12
  natürlich als erste Kritik daran die Frage, ja gut, jetzt muss
• 18:18
  ich aber bedingt einen Ablauf haben, ne eine Orchestrierung
• 18:22
  zum Beispiel muss ich steuern berechnen oder nicht, um das
• 18:27
  Beispiel noch mal zu nehmen, ne einfach nur zu sagen in dem und
• 18:30
  dem Fall. Muss ich jetzt calculate Texas
• 18:34
  aufrufen oder nicht beispielsweise?
• 18:37
  Und das ist halt ein richtig spannender Punkt dabei, weil
• 18:40
  wenn du das und das gilt, da muss man fairerweise sagen, das
• 18:43
  gilt aber auch für alle Prinzipien, das haben wir auch
• 18:45
  bei jeder Principal Folge gesagt, ein Dogmatisches
• 18:50
  umsetzen. Bringt zwar noch immer so n
• 18:54
  bisschen die Vorteile mit, aber man kauft sich auch wieder viele
• 18:57
  Nachteile ein und genauso ist es für mich an dieser Stelle auch
• 19:00
  und ich fand es interessant, dass sozusagen die Fans davon
• 19:03
  und die das Ganze ins Leben gerufen haben auch sagen, Nein,
• 19:06
  nicht dogmatisch verfolgen, sondern wirklich das n bisschen
• 19:09
  weicher betrachten und da fand ich die Lösung dahinter, die
• 19:13
  vorgeschlagen wurde irgendwie recht spannend, weil zum
• 19:17
  Beispiel zu sagen wenn das keine Ahnung, ich muss mir irgendwas
• 19:23
  ausdenken jetzt ja, ob das jetzt Sinn macht oder nicht, aber wenn
• 19:25
  zum Beispiel die Rechnung in einem Land wie Deutschland zum
• 19:30
  Beispiel gestellt wird, dann berechne die Steuern ansonsten
• 19:34
  andere, beispielsweise ne, das heißt, wir haben jetzt mal so
• 19:37
  konstruiert ne fallunterscheidung
• 19:39
  beziehungsweise ne Bedingung, ne, also wenn das Land
• 19:42
  Deutschland ist, dann macht das ansonsten was anderes.
• 19:45
  Und anstatt in dieser Integration Funktion.
• 19:50
  Dann zum Beispiel zu sagen, If Country ist gleich Germany, so
• 19:55
  ne, dann sollst du das in eine Funktion auslagern, weil dann
• 20:00
  ist diese Funktion wiederum ja Operation.
• 20:03
  Dann hast du zwar die Unterscheidung in deine
• 20:05
  Integration Funktion, aber die Entscheidung, also wie wird
• 20:10
  getroffen in einer Operation Funktion und damit ist es quasi
• 20:14
  wieder sauber genug gekapselt. Um das Prinzip einzuhalten,
• 20:19
  dachte ich mir OKOKOKOK verstehe ich, kann ich auch in gewissen
• 20:25
  Grad leben mit der Lösung, aber es hat mir auch n bisschen
• 20:28
  Kopfschmerzen bereitet, aber ich weiß nicht wie du das siehst.
• 20:32
  Immer kurz zusammenfassen also im Endeffekt wäre es ja so, dass
• 20:34
  du die Integration hast, die zum Beispiel sagt, Ich mach a mach B
• 20:39
  berechne Steuern, mach C oder irgendwie sowas ne und.
• 20:43
  Dieses berechne steuern, würdest du aber aufrufen auf so ne Art
• 20:46
  Zwischenebene die dir sagt, Check also berechne Steuern am
• 20:51
  auf der Klasse, entscheide welche Steuern du berechnen
• 20:54
  musst. So weißt du so und dann hast du
• 20:57
  quasi diese Zwischenschicht die dann sagt OK angenommen das oder
• 21:01
  das, dann berufe ich vielleicht zum Beispiel den.
• 21:05
  Deutschen Steuerservice auf oder den was weiß ich dänischen
• 21:08
  Steuerservice oder so ne, also dass man halt das so dann
• 21:11
  trennen würde und demzufolge hättest du ja dann irgendwo auch
• 21:15
  ne Operation auf dieser Ebene halt an diesem Knotenpunkt, der
• 21:19
  da drüber sitzt zu entscheiden mach ich das oder das ne, also
• 21:23
  welchen steuerservice ruf ich jetzt auf?
• 21:25
  So als Beispiel hab ich das so richtig verstanden.
• 21:27
  Genau, ja. Also.
• 21:31
  Ja, also im Prinzip ist es irgendwo auf der Integration
• 21:33
  Ebene aber noch mal ausgelagert zu einer eigenen Operation Ebene
• 21:37
  und dadurch ist es OK. Das war so die Argumentation
• 21:40
  dahinter, und da geh ich halt wie gesagt auch mit, weil ein
• 21:45
  Punkt warum es das IOSP gibt, oder?
• 21:48
  Was so der Benefit dabei ist, ist ja testbarkeit in dem
• 21:51
  Moment, wenn ich das klar voneinander trenne, kriege ich n
• 21:55
  Riesenbonus in Sachen Unit Test. Ja, also ich kann halt auf
• 21:58
  Operation Ebene wunderbare Unit Tests ansetzen, ne, weil das
• 22:02
  halt wirklich nur so Logiken beinhaltet, die ich dann einzeln
• 22:05
  abtesten kann und sicherstellen kann, dass meine Logiken
• 22:08
  funktionieren und auf Integration Ebene wie der Name
• 22:11
  schon sagt, kann ich halt dann schon nachher Richtung
• 22:13
  Integration Test gehen und das auch sehr gut umsetzen.
• 22:16
  Das versteh ich und das ist wirklich n großer Benefit, dass
• 22:19
  es sich lohnt, sich darüber Gedanken zu machen, welche
• 22:24
  Gefahr ich dabei sehe. Und da bin ich mal gespannt, wie
• 22:26
  du das siehst. Ja, wir sind weg vom Spaghetti
• 22:30
  Code, den ich anfangs genannt hatte mit der Create invoice, da
• 22:34
  passiert alles drin, das schreit schon nach Spaghetti Code, der
• 22:38
  da am Ende hinauskommt. Hinzu mit dem neuen Prinzip,
• 22:42
  wenn ich es jetzt ganz, ganz streng verfolge, dass ich bei
• 22:45
  dem sogenannten Ravioli Code am Ende bin, dass ich es halt so
• 22:49
  krass modularisiere, dass das auf Kosten der Lesbarkeit geht,
• 22:55
  also dass ich am Ende nicht mehr weiß, was passiert hier
• 22:58
  eigentlich, weil ich nur noch hin und her springe und jetzt
• 23:01
  muss ich da, OK, was macht die Funktion?
• 23:03
  Ja OK, warte mal, aber das passiert nur, wenn ich warte in
• 23:05
  die Funktion reingucke also du. Du hast halt, ich finde es halt
• 23:10
  witzig das Ravioli Co zu nennen, weil du hast ja diese kleinen
• 23:12
  ganz vielen Zacken so außen muss ich sagen, war bei mir jetzt
• 23:15
  auch nicht so mega geläufig. Ich hatte das schon ein 2.
• 23:18
  Mal gehört, aber es macht natürlich Sinn wenn man mal
• 23:20
  drüber nachdenkt, dass du halt dich quasi so fein
• 23:23
  modularisierst und dass du halt überall diese.
• 23:27
  Zacken hast sozusagen ne. Na, du hast diese Zacken oder
• 23:30
  diese Batches, weil ein Ravioli halt so ein einzelner Ravioli
• 23:33
  ist. So n Spaghetti ist ja so n
• 23:34
  riesiger Spaghetti, weil dass du sagst, OK, du hast halt einmal
• 23:37
  sozusagen ne riesen Funktion, die ewig lang ist und genau bei
• 23:40
  Ravioli sind es halt irgendwie so batches.
• 23:42
  Ich find es aber lustig, weil. Ich.
• 23:44
  Könnte schwören, ich hätt das schon mal gehört, aber hätten
• 23:49
  hätt ich, wär ich jetzt nicht quasi bei wegen dieser Folge
• 23:52
  wieder darüber gestolpert. Ich, ich hätte es nicht
• 23:55
  reproduzieren können, also im Sinne von ich aus meinem Mund
• 23:59
  wäre nicht Ravioli Code mal wieder rausgekommen.
• 24:02
  Weil ich es einfach. Verdrängt hab das ist.
• 24:04
  Das das müssen wir jetzt wieder vor uns mitnehmen.
• 24:05
  Lass doch mal das Gute, wenn wir uns Thema gerade so Community
• 24:08
  wünsche uns angucken, da können wir mal selbst mal ne Menge
• 24:11
  lernen bei und wieder auffrischen.
• 24:13
  Kennst du diese, diese Nudeln, die aussehen, wieso
• 24:16
  Schmetterlinge, die haben auch irgendein Namen, frag mich ob es
• 24:20
  so n Code gibt. Die haben auch irgendein Namen,
• 24:23
  ja. Weiß nicht, komm ich nicht
• 24:26
  drauf. Ich überleg grad, vielleicht
• 24:28
  fällt es mir noch ein. Ich, ich, ich kenn nur Penne,
• 24:32
  aber das ist was anderes. Na, welches Prinzip könnte das
• 24:36
  symbolisieren? Arigatoni gibt es auch noch, OK,
• 24:39
  aber wieder auf dem Bild. Jetzt hast du alles rausgehauen,
• 24:42
  was du weißt, OK, deswegen kommen wir mal wieder zu dem
• 24:45
  Thema, wo du dich auf jeden Fall besser auskennst als mit Nudeln
• 24:50
  kochen. Kann ich.
• 24:51
  Lass uns noch mal über die Tests reden.
• 24:54
  Speziell über die Trennung, Operation, Integration.
• 24:56
  Ich hab es ja gerade schon so n bisschen angeteasert.
• 24:59
  Wo siehst du denn noch so Vorteile da drin für die
• 25:02
  Testbarkeit für die Testbarkeit? Na ja, also prinzipiell ist es
• 25:11
  schon auf jeden Fall nicht verkehrt, dass du die Logik
• 25:15
  abtesten kannst. Ich, ich denk mir halt so.
• 25:17
  Ja, also auf Integrationsebene kannst du Integrationtests
• 25:20
  nutzen, das sagt ja auch schon irgendwie der.
• 25:23
  Ich sag mal der Name aber trotzdem denk ich mir immer so
• 25:27
  Na OK aber man muss es auch immer noch n bisschen
• 25:30
  differenzieren find ich so n bisschen weil wenn du irgendwo n
• 25:34
  Service hast ne wo du am Ende trotzdem irgendwie an die
• 25:37
  Datenbank rangehst innerhalb dieses Services was ja auch
• 25:40
  öfter mal ganz gerne gemacht wird also angenommen du sagst du
• 25:42
  hast irgendwo dein dein dein Blatt unten wo deine Operation
• 25:49
  sitzt zum Beispiel ja OK aber trotzdem kann er.
• 25:52
  An diesem Blatt irgendwo der Zugriff dann auf ne Datenbank
• 25:55
  hängen, das heißt irgendwas muss ja trotzdem dann mehr oder
• 25:58
  weniger gemockt werden. Weißt du oder gefaked werden
• 26:01
  oder was auch immer. Also es ist natürlich manchmal
• 26:04
  auch so, dass du einfach nur n Service hast, der vor sich
• 26:05
  hinarbeitet, wirklich Input kriegt und Output bekommt.
• 26:09
  Ja, aber jetzt wo ich drüber nachdenke ist es wahrscheinlich
• 26:14
  eher so gemeint, dass du erst diesen diesen Rückgabewert
• 26:18
  bekommst und dann die Integration wieder sagt.
• 26:21
  OK und jetzt? Gibst du das, machst du den
• 26:24
  Aufruf für die Datenbank. So könnte ich es mir noch
• 26:26
  vorstellen. Ja, jetzt wo ich gerade drüber
• 26:29
  nachdenke, wenn man das so macht, dann ist es wieder gut,
• 26:33
  dann bin ich dabei, aber ich hab gerade den Faden verloren, du
• 26:35
  hast gesagt, Vorteile für die Testbarkeit, na.
• 26:41
  Und dann mir noch mal kurz so n Kleinen so n kleinen, wie sagt
• 26:45
  man ne Wegweise geben worauf ich so n bisschen hinaus möchte,
• 26:49
  weil das fand ich interessant. Es wird ja argumentiert, dass
• 26:53
  ich durch IOSP so gut wie keine Mogstabs mehr brauche.
• 26:58
  Die Test Setups werden viel einfacher, gehst du damit, also
• 27:02
  siehst du das auch oder glaubst du, dass es vielleicht auch
• 27:05
  irgendwo wieder Grenzen gibt? Mhm, ich sag mal so.
• 27:09
  Also. Weil du dieses Beispiel.
• 27:12
  Was ich gerade genannt hab, so, wenn man es so durchzieht, dann
• 27:14
  hast du sicherlich die Möglichkeit da weniger von
• 27:18
  machen zu müssen. Ja, also wenn du das wirklich
• 27:20
  so. Aufziehst und sagst OK, die so n
• 27:24
  Service zum Beispiel schreibt nicht direkt in in in Repo oder
• 27:28
  so ne, damit du halt wirklich dieses diese diese Unit
• 27:31
  testbarkeit hast. Ne dass du wirklich sagst OK du
• 27:33
  hast halt n Service der Input bekommt, er erzeugt Output, den
• 27:37
  kannst du super testen und der Output wie er in der Datenbank
• 27:41
  geschrieben wird, das ist dann wirklich Integration Test mäßig
• 27:43
  wenn man das so macht dann finde ich ist es in Ordnung dann dann
• 27:47
  kann man diesen Benefit mitnehmen.
• 27:49
  Aber man muss natürlich dann, es ist halt n bisschen find ich so.
• 27:55
  Software Design zieht, also zieht man es durch oder zieht
• 27:58
  man es nicht durch und wie wie genau wie stark zieht man es
• 28:03
  dann am Ende doch durch? Also.
• 28:04
  Es ist ein. Bisschen bescheuert, aber wie du
• 28:06
  schon meintest, wenn man es wirklich zu über, also zu krass
• 28:09
  übertreibt, dann hast du halt diesen Ravioli Code und wenn du
• 28:13
  es aber zu. Wenn du so so anfängst, aber
• 28:16
  nicht so richtig durchziehst bis zu einem gewissen Punkt, dann
• 28:20
  bringt dir das irgendwie auch wieder nichts.
• 28:21
  Also du brauchst diesen Sweet Spot in der Mitte und nur dann
• 28:24
  würde ich sagen, bringt es irgendwie auch wirklich was.
• 28:27
  Ja. Ich glaub, ich hab deine Frage
• 28:29
  immer noch nicht ganz. Beantwortet.
• 28:30
  Nein, also ja doch, es geht ja genau das sind genau die
• 28:33
  Überlegungen, die ich mir dabei auch überlege, die Überlegung,
• 28:38
  die ich auch anstelle. Man denkt natürlich erstmal so,
• 28:41
  OK, jetzt hab ich so Operation Funktionen und die haben
• 28:43
  irgendwie keine Abhängigkeiten im Sinne von anderen Funktionen.
• 28:48
  Ne, da ist auch irgendwie keine Datenbank im Weg oder irgendwie,
• 28:50
  das ist wirklich nur Logik, nur ne Berechnung dann OK gut dann
• 28:55
  kann ich ja super geile Unit Tests schreiben dafür, da geh
• 28:57
  ich auch mit mit dem Prinzip aber wie schwer ist es dahin zu
• 29:01
  kommen und welche was kauf ich mir dafür ein?
• 29:03
  Das frag ich mich so ne natürlich.
• 29:06
  Brauche ich keine Mogs oder Stabs, wenn ich ne kleine
• 29:11
  berechnungsfunktion abteste? Ja, aber die ist so autark, die
• 29:16
  hat Eingabe und Ausgabe und das kann ich halt testen, dass das
• 29:19
  Richtige rauskommt. Aber wenn du jetzt mal n etwas
• 29:23
  komplexeres System nimmst, wie einfach ist das so umzusetzen,
• 29:27
  dass das auch. Nehmen wir jetzt zum Beispiel
• 29:31
  mal n Backend. Ja, dass das genauso auch alles
• 29:33
  funktioniert unter der Haube, oder wo muss man dann sagen, du
• 29:37
  Pass auf, ich muss das jetzt aber mal Kapseln oder
• 29:39
  zusammenfassen, weil es auch irgendwo zusammengehört und dann
• 29:43
  ist es halt kein sauberes IOSP mehr.
• 29:46
  Ja, ich stell mir zum Beispiel die Frage, wenn du jetzt mal
• 29:50
  sagst, so ne ganz klassische Aufbau, wir haben so, weil du ja
• 29:52
  meintest n Service und Datenbanken und wir haben zum
• 29:55
  Beispiel noch n Controller wo ich jetzt quasi.
• 29:58
  Endpunkte bereitstelle OK dann so n Endpunkt ist irgendwo
• 30:04
  Integration, ja der managt quasi was passieren soll, der ruft
• 30:07
  dann vielleicht einfach nur statischen Server sag ich schon
• 30:11
  n Service auf und die Rückgabe wird dann halt verwertet
• 30:16
  sozusagen ne also jetzt nicht, dass da irgendwas berechnet wird
• 30:18
  oder so OK geh ich mit dann gehen wir runter auf den Service
• 30:22
  im Baum sind wir so auf der nächsten Ebene ja und was macht
• 30:24
  n Service ja der hat. Im Prinzip guckt er so was hat
• 30:28
  er für Daten und interagiert mit den entsprechenden Repositories.
• 30:32
  Wenn wir jetzt so n ganz einfaches Crute Backend mal
• 30:34
  nehmen ja und sagen OK, ja wir wollen hier nur Sachen
• 30:38
  speichern, auslesen, verändern ne, aber da muss er ja irgendwie
• 30:42
  auf dem Repository arbeiten später oder zumindest die
• 30:45
  Aufrufe machen gut kannst du sagen im Baum OK ist es wieder
• 30:49
  irgendwie so n Knoten aber kein Blatt also kein keine Operation
• 30:53
  sondern der. Ist es weitere Orchestrierung,
• 30:56
  was jetzt aufgerufen wird? Und irgendwann bist du unten und
• 31:00
  sagst OK, das wird jetzt in die Datenbank gespeichert?
• 31:03
  Ja ja, gehst den Baum wieder hoch, sagst hier ist das
• 31:07
  Ergebnis Service sagt alles klar hier ist das Ergebnis gehst hoch
• 31:11
  Controller nimmt das Ergebnis und schreibt es zurück sozusagen
• 31:14
  also antwortet auf den Request. Ja dann das klingt erst mal
• 31:18
  wunderbar, dann gehst du einmal n Baum runter und wieder hoch.
• 31:21
  Finde ich würd ich jetzt sagen IOSP Check, so kann man so
• 31:25
  machen, aber ist das auch wirklich die Realität, dass das
• 31:29
  alles so einfach ist? Oder hat der Service nicht mal
• 31:32
  ganz schnell noch irgendwie ne Unterscheidung oder zum Beispiel
• 31:35
  ne Auswertung drin, dass du sagst so ja gut, was hab ich
• 31:38
  denn für Parameter bekommen? Ja n Key ja man will irgendwas
• 31:42
  anhand von einem Key aus der Datenbank holen ja aber der Key
• 31:44
  ist leer, also hier Exception beispielsweise.
• 31:48
  Ist das denn schon Operation? Muss ich ne Funktion aufrufen,
• 31:52
  die nur auswertet, dass dieser Key nicht leer ist und so weiter
• 31:58
  also weißt worauf ich hinaus möchte und das deckt sich ja mit
• 32:01
  dem was du meinst. Wie sauber zieh ich das durch?
• 32:05
  Ja, aber das ist ich find das ist ich hab auch mal n relativ
• 32:10
  großes Refactoring schon n bisschen länger her in der
• 32:13
  Software gemacht, weil es halt einfach dran war.
• 32:16
  Es war wichtig, musste gemacht werden.
• 32:18
  Und da gehst du halt wirklich, da gehst du halt einfach.
• 32:23
  Also wir sind auch wirklich da im Pair dann zusammen
• 32:26
  durchgegangen, verschiedenste Klassen, also es ich weiß gar
• 32:30
  nicht, ob das wirklich alles war, aber es war auf jeden Fall
• 32:32
  n Strang so n ich sag mal n feature ne wirklich n großes
• 32:36
  Feature was diese Software bereit gehalten hat oder zur
• 32:40
  Verfügung gestellt hat und man. Also wir sind dran gegangen in
• 32:46
  der in, in dem in dem Gedanken, dass wir gesagt haben, wir
• 32:48
  wollen das einfacher machen, weil keiner mehr, wenn er das
• 32:51
  irgendwie anfasst und da was machen muss, versteht, was da
• 32:54
  passiert. Also fachlich konnte man es
• 32:57
  irgendwie nicht verstehen, technisch wurde aber alles
• 32:59
  richtig umgesetzt, also ohne dass man jetzt irgendwie sagt,
• 33:01
  so OK, das ist irgendwie falsch, ne, es ist war schon richtig,
• 33:05
  nur dass halt auch der ganze Code sehr technisch beschrieben
• 33:09
  war, also du konntest quasi überhaupt nicht mehr erkennen.
• 33:12
  Auch fachlich. Wie ist irgendwas da drin, was
• 33:14
  passiert da ne? Also und wenn ich jetzt überlege
• 33:17
  ne noch mal rückblickend, dass man vielleicht zum Beispiel IOSP
• 33:20
  anwenden würde, dann ist es ja vielleicht nicht verkehrt, also
• 33:25
  haben wir in dem Moment zumindest nicht wissentlich
• 33:27
  gemacht und wir haben es auf jeden Fall refecter zwar, aber
• 33:30
  auch gar nicht so einfach, weil du dann genau in solche Punkte
• 33:32
  kommen, die kommst die wo du die du meintest, ne wo du dann sagst
• 33:36
  ja OK, lass uns das doch einfach sauber auftrennen.
• 33:39
  Aber so einfach geht das gerade gar nicht.
• 33:40
  Das ist wirklich gar nicht so easy, das auseinander zu nehmen,
• 33:43
  weißt du und ich finde aber auch immer, die Frage ist, in
• 33:47
  welchem, in welchem Frame bewegst du dich, weil wenn du
• 33:52
  zum Beispiel sagst, du bist jetzt in dieser Klasse und
• 33:54
  willst innerhalb dieser Klasse es wirklich schön trennen diese
• 33:58
  Funktionalität, weil du weißt, das ist da sind 2 Dinge
• 34:01
  ineinander gewurstelt, die gehören separat auseinander und
• 34:04
  du willst es aber wirklich in dieser Klasse trennen, dann.
• 34:08
  Bist du manchmal in diesem Frame so stark gefangen, anstatt
• 34:12
  vielleicht noch mal so n bisschen raus zu zoomen um zu
• 34:14
  sagen, OK, wir brauchen ja aber vielleicht mehr so ne Art
• 34:18
  Integration an dieser Stelle, die das ganze orchestriert und
• 34:21
  sagt was aufgerufen wird und dann trennst du vielleicht im im
• 34:25
  größten Fall vielleicht sogar auf den Service auf, weil du
• 34:27
  merkst, dieser Service heißt keine Ahnung, Order Service
• 34:32
  aber. Da sind 2 Dinge drin, die sind
• 34:35
  unglaublich krass, weil du dann zum Beispiel vielleicht einmal
• 34:38
  hast du n Valley Data, der da irgendwie reingemokelt ist und
• 34:43
  gleichzeitig noch irgendeinen Calculator oder so ne, aber das
• 34:46
  eine ist, es ist ganz anders, also das kannst du theoretisch
• 34:50
  trennen, aber wenn du manchmal diesen Frame nicht hast, wenn du
• 34:52
  dir nicht denkst, OK, ich kann das irgendwie trennen oder ich
• 34:54
  sollte das jetzt trennen, ne und dann ordentlich auf einer oberen
• 34:57
  Schicht Orchestrieren zum Beispiel.
• 35:00
  Dann dann ist das auch schwierig da vielleicht irgendwie was zu
• 35:02
  refactern und deswegen finde ich ist es gut dass du es sagst dass
• 35:06
  du sagst ey es ist manchmal wirklich nicht so einfach ne und
• 35:10
  es ist manchmal auch super schwierig zu sagen ich will das
• 35:12
  jetzt so durchziehen das ist einfach zu sagen aber es dann
• 35:14
  auch wirklich so durchzuziehen ja aber auch gleichzeitig wieder
• 35:18
  in diesem Sweet Spot dass du sagst OK wir wollen jetzt aber
• 35:20
  auch kein ravioli Code aber das ist schon echt hart ne aber Ich
• 35:25
  glaube gerade das wissen darum dass man bestimmte Dinge
• 35:28
  vielleicht. Nach einem bestimmten Prinzip
• 35:30
  machen kann, wie zum Beispiel IOSP, das kann schon helfen.
• 35:35
  Also wir, wir haben uns das ja jetzt angeguckt wegen dem Wegen
• 35:39
  des Community Wunsches und haben ja auch gemerkt, OK, hat
• 35:43
  vielleicht seine Schwächen, aber gleichzeitig auch eigentlich
• 35:47
  ganz geile Ideen, also zumindest Betrachtungsweisen ne die.
• 35:50
  Du da ja. Also es lohnt sich auf jeden
• 35:52
  Fall diese Denkweise anzunehmen, ne und mal zu challengen also
• 35:56
  was ich so für mich auch mitnehme ist einfach.
• 35:59
  Wenn ich refactor, um dein Beispiel noch mal aufzugreifen
• 36:02
  und um zu entscheiden, was refactor würdig ist und was
• 36:06
  nicht, ist es ja wirklich nicht schlecht zu sagen, ich gucke mir
• 36:09
  Funktionen an. Ist es Operation oder ist es
• 36:12
  Integration oder ist es nicht sogar beides und dann kann ich
• 36:15
  ja noch so weit gehen, dass ich es ja erkennen, erkennen kann.
• 36:17
  Zum Beispiel, daran habe ich da Berechnungen drin, habe ich da.
• 36:22
  Strukturen drin habe ich da schleifen drin.
• 36:25
  Alles, was wir eingangs erwähnt hatten, was so Anzeichen für
• 36:28
  Operation sind, das heißt, ich habe irgendwie so eine Art
• 36:30
  Analyse Tool auch um mein Code ein bisschen zu bewerten, dafür
• 36:34
  finde ich das zum Beispiel richtig cool oder auch was du
• 36:37
  meintest um noch mal ganz kurz zurück zu springen mit meinem
• 36:40
  einfachen Backend Beispiel, ja dann muss ich halt 2 Services
• 36:43
  machen. Ja okay wäre eine Lösung wenn
• 36:45
  ich jetzt sage ey ich muss Sie aber validieren ob der Input in
• 36:48
  Ordnung ist. Das ist jetzt in meinem Service
• 36:50
  drin, der mit dem Repository arbeitet.
• 36:53
  Ja nee, er macht doch n zweiten Service, der im Vorfeld das
• 36:55
  klärt und der Controller orchestriert sozusagen weiter
• 36:58
  und gibt dann einfach nur das Ergebnis zurück an den also ne
• 37:02
  Response ja und so kann man das aufbauen, klar, aber die Frage
• 37:05
  ist wo ist der Sweetspot zwischen richtig gut modularen
• 37:11
  Code der sich gut testen lässt und.
• 37:14
  Ravioli Code nenn ich es jetzt einfach mal so, weil das ja
• 37:16
  immer in dem Zusammenhang genannt wird.
• 37:18
  Ne und das ist glaub ich viel Erfahrung am Ende und bedarf
• 37:22
  mehrere refactors Refactorings wie ist denn wie sagt man das
• 37:27
  eigentlich das Refactors? Klingt hier so super.
• 37:32
  Ne refactorings ne was so. Ja.
• 37:36
  Und das ist n Lernprozess. Das ist wie bei jedem Prinzip so
• 37:41
  und in. Interessanterweise, was ich
• 37:43
  wirklich spannend fand dabei ist, wenn man sich das ganze Mal
• 37:46
  jetzt im Zusammenhang mit anderen Prinzipien mal vor Augen
• 37:50
  führt, was die eigentlich aussahen, ja, was sagt jetzt
• 37:53
  IOSP aus und beispielsweise auch sowas wie Single Responsibility
• 38:00
  Principle, ne, also jede jedes Element hat quasi eine klare
• 38:06
  Aufgabe. Ja.
• 38:08
  Und das ist schon ziemlich deckungsgleich, wenn man so
• 38:10
  drüber nachdenkt. Weil wenn ich sage, Operation
• 38:12
  Integration ist getrennt, das heißt, diese Funktion macht nur
• 38:15
  Operation, das ist sehr wahrscheinlich eine klare
• 38:18
  Aufgabe, anders wird es halt schon gar nicht mehr umsetzbar,
• 38:21
  wirklich sein, ne, sonst mixt du ja wieder Integration da rein,
• 38:25
  wenn du jetzt wieder mehrere Sachen da abhandelst.
• 38:27
  Das heißt, diese beiden Prinzipien haben auch irgendwo
• 38:30
  nen Nenner oder das dry Prinzip, ja Don't repeat yourself.
• 38:37
  Ja. Einfach, wenn man sich überlegt,
• 38:40
  was es aussagt. Ja, wiederhol dich nicht selbst.
• 38:43
  Nutze Code, den du geschrieben hast wieder und in dem Moment,
• 38:47
  wenn ich jetzt wieder Operation und Integration klar trenne,
• 38:49
  habe ich ja sehr wahrscheinlich auch Operation Funktionen, die
• 38:52
  ich wieder verwenden kann. Ne.
• 38:55
  So also das spielt auch sich wieder gegenseitig in die Karten
• 38:58
  und deswegen glaub ich es gibt kein richtig oder falsch an der
• 39:02
  Stelle. Wie bei allen Prinzipien,
• 39:04
  sondern und das find ich richtig cool, dass du das gesagt hast,
• 39:07
  weil das Fazit hab ich auch so, du kannst ja gleich noch, falls
• 39:10
  du noch andere Punkte hast noch mal sagen, aber für mich war
• 39:13
  auch so n Fazit einfach zu sagen es gibt einfach gute
• 39:18
  Denkanstöße, ja. Es ist nicht in Stein gemeißelt,
• 39:22
  sondern es ist n weiteres Tool n weiteres Prinzip um sich die
• 39:27
  richtigen Fragen zu stellen in Sachen Codequalität und das
• 39:31
  finde ich es super. Deswegen würde ich sagen ich
• 39:34
  kann das Prinzip nicht, aber ist cool, kann man drüber
• 39:38
  nachdenken, besonders sich die Frage zu stellen, zum Beispiel
• 39:40
  beim Refect, dann Operation oder Integration.
• 39:45
  Ja, am Ende ist es glaub ich auch wirklich einfach ne auch ne
• 39:47
  Erfahrungssache. Was kann man wo gut einsetzen
• 39:49
  beziehungsweise wie du meintest es ist ja auch deckungsgleich
• 39:52
  wenn du das eine Prinzip verstanden hast und umsetzt
• 39:55
  kannst du auch relativ schnell, vielleicht auch automatisch das
• 39:58
  andere Prinzip umsetzen, obwohl du es vielleicht gar nicht so
• 40:01
  kennst. Ja, also das muss man ja auch
• 40:03
  dazu sagen, aber trotzdem finde ich um das noch mal auch
• 40:06
  zusammenzufassen. Wenn du so NIOSP Prinzip zum
• 40:10
  Beispiel jetzt kennengelernt hast, auch, wie wir zum
• 40:13
  Beispiel, ist es jetzt nichts, wo wir uns jetzt zum Beispiel
• 40:15
  auch gesagt haben, Boah, das verändert jetzt wirklich alles,
• 40:17
  das ist voll krass so, unsere ganze Coding Welt hat sich auf
• 40:21
  den Kopf gestellt, so ist es nicht.
• 40:23
  Aber es ist halt einfach so weißt du du kannst so Dinge
• 40:26
  mitnehmen du kannst für dich weil du du hast Dinge erlebt du
• 40:29
  merkst vielleicht ey warte mal da und da wenn ich das aus der
• 40:32
  Sichtweise noch mal betrachte hätte es vielleicht geholfen
• 40:35
  beim nächsten Mal probier ich das mal aus ne und das ist halt
• 40:37
  einfach gut und dafür ist es halt nicht verkehrt so ich sag
• 40:41
  mal seinen wissenshorizont zu erweitern und dann ist das ne
• 40:44
  tolle Sache und zu don't repeat yourself da muss ich immer an
• 40:47
  eine Sache denken wo mal NN ganz Alter Kollege von mir gesagt
• 40:51
  hat. Und dann hier Don't repeat
• 40:53
  yourself Bauerbub und ich so wie heißt das noch mal?
• 40:56
  Und er so, Na Don't repeat yourself und ich dachte mir so I
• 40:59
  got you, ich wusste das hast. Du übrigens in der Podcast Folge
• 41:02
  bei mir auch gemacht. Das ist einfach.
• 41:05
  Werd ich dir nie verzeihen, ja. Kein Problem, lass Ding und.
• 41:11
  Demnach hast du deinen Joke wiederholt.
• 41:13
  Oh mein Gott, das ist ja noch viel schlimmer, ey ja, wie sagt?
• 41:17
  Man so schön, wer unschuldig ist, wer für den ersten Stein
• 41:19
  oder so n Kram. Ja, man erzählt auch immer die
• 41:25
  gleichen Floskeln am Ende wieder, aber ich muss da mal
• 41:27
  dran denken. Auf jeden Fall, Tino hat Spaß
• 41:30
  gemacht, war eine tolle Folge, vielen Dank dafür.
• 41:32
  Ja, auch vielen Dank noch mal für den Themenvorschlag,
• 41:35
  definitiv deswegen auch hier die Anmerkung, Liebe zuhören, Liebe
• 41:37
  zuhören, falls du Themenvorschläge hast, weil du
• 41:39
  denkst, ey, das wäre echt cool, wenn ihr darüber mal sprecht
• 41:42
  oder es ein Thema ist, was vielleicht nicht so bekannt ist,
• 41:44
  aber unsere coder Welt davon erfahren muss, dann.
• 41:47
  Dann schreib uns gerne auf der Plattform deiner Wahl oder per
• 41:50
  Mail würden wir uns mega freuen und wir setzen es natürlich auch
• 41:54
  um die Wünsche. Ganz genau.
• 41:56
  Und ansonsten würd ich sagen, Leute, liebe Zuhörer, lieber
• 41:59
  Zuhörer, bewertet gerne den Podcast, falls ihr das noch
• 42:02
  nicht gemacht habt. Das hilft uns auf jeden Fall,
• 42:04
  gerade wenn du sagst, dieser Podcast ist bringt dir Mehrwert,
• 42:09
  dann freut uns das natürlich mega und du kannst auch gerne
• 42:12
  gibt es auch n kleinen Spendenlink in den Shownotes
• 42:15
  würden wir uns auch mega drüber freuen.
• 42:17
  Ansonsten würde ich sagen, hören wir uns einfach in der nächsten
• 42:20
  Folge wieder bis zum nächsten. Mal deine Kollegen Wallis
• 42:23
  gemeinsam besser.