Stell dir mal vor, du machst so das Watte Abi oder deine Abschlussprüfung allgemein und kommst mit so einem Rechenschieber an. Also. Entweder so n absolutes. Genie. Ist find ich wahnsinnig. Wahnsinnig genau. Ah, verdammt noch mal von vorne alles zurückgeschoben. Coding Boys Deinem Podcast rund um Softwareentwicklung und aktueller Technews. Herzlich Willkommen.
Halli Hallo und herzlich Willkommen zur neuen Folge vom Coding Buddies Podcast. Es gibt mal wieder ne neue Folge und dafür brauchen wir alle hier beisammen und zwar dich, liebe Zuhörerin, lieber Zuhörer und mich, ich bin da und jetzt gucken wir einmal. Tino, bist du auch am Start? Ich bin auch am Start. Moin Moin Fabi, Was geht ab? Spoiler alarm. Ich hab dich. Schon in der Kamera gesehen. Haha, du wusstest, dass ich da bin. Ja, wäre auch komisch, wenn ich
passt. Schon so also Setting ist aufgebaut, wir können eine neue Folge aufnehmen, auf jeden Fall perfekt. Ansonsten ja, bist du fit. Wie geht's dir? Ja, mir geht's gut, ich hab eigentlich nichts zu beklagen, bin das ist gut, bin wach, bin da, hab Bock. Wie geht's dir aufmerksam? Bin bereit fürs Thema, quasi. Nee, das nicht. Geht es dir denn auch gut? Ja, ja, soweit schon.
Ich bin ein bisschen körperlich im Arsch, aber mental bin ich völlig am Start für die Folge. Was hast du denn gemacht? Nein, also nichts Wildes. Ich war gestern Bouldern. Ja, klar, klar. Nee, ich war Bouldern und hab jetzt natürlich so n paar Nachwehen. War ne sehr anstrengende Session, war auch sehr warm in der Halle, es hat es nicht einfacher gemacht. Ah. Ja, aber da, du weißt ja wieder, stimmts. Lehrer, oder? Ja, es war auf jeden Fall Lehrer.
Ich denke, es waren viele so clever und waren am See oder so und ich war mit n paar Leuten in der Boulderhalle. Ja, Na ja, auf jeden Fall. Ich kann jetzt wieder das typische, ich kann nichts greifen, ich krieg die Tasse, die Kaffeetasse nicht mehr gehoben und du weißt ja, wie es ist, du boilderst doch selbst. Nimm den Strohhalm, das ist. Sehr leicht im Strohhalm. Genau.
Genau, nee. Ansonsten ist aber alles tutti soweit, wie man so schön sagt, sagt man hoffentlich so und ich hab n schönes Thema mitgebracht für heute, was ich gerne mit dir bequatschen möchte, hau mal raus. Und zwar hatten wir vor kurzem ja mal angefangen. So. Prinzipien in der Softwareentwicklung zu erklären und hatten da ja. Das Drive Prinzip also Don't repeat yourself. Prinzip erklärt und n bisschen analysiert fordert und Nachteile benannt. Auch so Challenges die wir da
drin sehen. Und ja, das das fand ich cool und deswegen hab ich mir gedacht, bring ich mal noch n anderes Prinzip mit und ich glaube wir haben das auch in der Folge schon so n bisschen angeteasert für die aufmerksamen Zuhörerinnen und Zuhörer. Und zwar soll es heute um das Kiss Prinzip gehen und damit meine ich nicht die Hard Rock Band die es mal gab aus New York, die zwar fantastisch war, aber um die soll es nicht gehen, sondern um das Prinzip Keep it
simple stupid. Ach so, ich dachte, jetzt kriegen wir hier eine Anleitung zum Küssen. Der. So schlecht du bist allein. Ich, ich, ich aber der. Musste sein. Ja gut, ich mach alleine weiter, ich denke es ist besser. Nein, magst du vielleicht mal erklären, was hinter dem Kiss
Prinzip steht? Ja, also das Kiss Prinzip besagt, dass man Systeme und Lösungen eigentlich so einfach wie möglich gestalten soll oder halten soll und aber natürlich, und das ist die Schwierigkeit, glaube ich auch, auf die wir gleich auch insgesamt in der Folge auch ein bisschen eingehen, dass man natürlich die Funktionalität auch trotzdem im
vollen Umfang erfüllen soll. Und. Dabei liegt halt der Fokus darauf, dass unnötige und hier auch noch mal der das Hauptaugenmerk auf das Wort unnötig unnötige Komplexität zu vermeiden. Und damit kann man halt im Endeffekt natürlich auch die Lesbarkeit oder Verständlichkeit des Codes erhöhen, logischerweise wichtiger Punkt auf jeden Fall, wir hatten ja auch in der letzten Folge vom Don't repeat yourself.
Im Prinzip gesagt, dass es oder haben wir herausgestellt, dass es ja wirklich essentiell und wichtig auch ist, Code verständlich zu gestalten und natürlich auch, dass man den Code warten kann. Das spielt so ein bisschen Hand in Hand und da ist es natürlich einfach gut, wenn man versucht, möglichst einfache, simple Lösungen in die Software einzubauen. Ja, und das ist im Großen und Ganzen so, mal kurz abgerissen, das Kiss Prinzip, darum geht es.
Genau, also grundsätzlich klingt es gar nicht so kompliziert und auch irgendwie logisch, aber ganz. So einfach ist es dann am Ende doch nicht, weil wie du so schön gesagt hast, es geht darum unnötige Komplexität. Zu vermeiden, das heißt, es geht jetzt nicht darum.
Zeichen einzusparen oder Zeilen ne, also dass man es also einfach nicht im Sinne von Codes oder knapp, also wenig Codes, sondern es geht da eher um die Komplexität und um den Grundgedanken. Die erste simple Lösung, die dir für ein Problem in den Kopf kommt? Meistens. So nach dem Prinzip. Die beste Lösung gleich ist und auch die Robusteste, weil das ist das, was dir in den Sinn kommt.
Das ist nicht. Kompliziert gedacht, sondern es ist so okay du hast ein Problem, lass mich kurz nachdenken, so und so machen wir das und das ist oftmals nicht fernab von der finalen Lösung oder von dem von der von einer guten Lösung, sage ich mal. Und dieses Prinzip möchte halt dazu animieren, so verstehe ich es.
Halt auch in die Richtung zu entwickeln, dass man sagt, OK, es ist halt jetzt der erste Ansatz, aber das ist nicht schlimm, weil genau diese Intuition, die ich hatte, führt mich jetzt in die richtige Richtung. Ja, und das finde ich eigentlich auch da recht spannend.
Hinter dieser Philosophie sage ich mal, die dahinter steckt, weil ich glaub, jeder kennt das und das hatten wir ja auch so als Challenge bei dem Dry Prinzip, dass eine hohe Komplexität, wenn ich mich jetzt selbst nicht wiederholen möchte, da haben wir ja gesagt, man neigt denn dazu, oft vielleicht zu hohe Abstraktionsebene, noch mal so als kleiner Reminder in. Zu integrieren, und das ist ja natürlich dann fernab von
einfachen, simplen Lösungen. Und auch die Challenge dahinter, weil wer soll das am Ende noch verstehen oder warten, da hattest du ja ein cooles Beispiel gebracht mit dieser generischen Tabelle, die bezogen lieber Zuhörer, falls sich das Thema interessiert, dann hör gern dann noch mal in die Folge rein, weil das war wirklich ein Paradebeispiel dafür, wo das Dryprinzip dann. Limitierung hat beziehungsweise vielleicht nicht mehr der richtige Ansatz ist, um da so
dran festzuhalten. Ja, das war auf jeden Fall, hat auf jeden Fall dafür geführt, dazu geführt, dass auch die das, was wir hatten, die Wartbarkeit sehr eingeschränkt wurde, weil wir wollten diese Software oder diesen Software teil erweitern, und das ist uns schwerlich gelungen. Und wenn du dann am Ende natürlich an den Punkt kommst, dass du sagst, ja okay, das wollen wir nicht noch mal haben, weil sind wir, sind wir mal ehrlich und sagen Hand aufs Herz. Wenn man sich eine Zeit lang
irgendein Code nicht anguckt. Man vergisst auch, was da drin ist. Also es ist ja so, dass du selbst deinen eigenen Code schreiben kannst. Irgendwann nach 2 Wochen, 2 Monaten wieder zurückkommst und dir denkst, was habe ich ja noch mal fabriziert.
Wer war das? Also das geht ja auch und da ist es dann natürlich nicht hilfreich, wenn man sagt, okay, wir haben jetzt eine Anpassung, vielleicht kommt irgendwann noch mal eine und wir haben das dann auch tatsächlich Gechallen gesagt, okay wollen wir das vielleicht noch mal. Vereinfachen, also nicht verallgemeinern, sondern eben vereinfachen. Also das ist ja sozusagen dann wieder weg vom Don't repeat yourself Prinzip.
In dieser Abstraktionsebene hinzu Air Kiss ne zu diesem Kiss Prinzip und da muss man natürlich dann auch wieder
gucken. Wie stark also es wäre natürlich blöd, wenn man sagt, EY, wir machen jetzt hier Don't repeat yourself, dann beim nächsten Mal sagt man, ach, das ist ja aber viel zu abstrahiert, lasst uns das lieber einfacher machen, wir refactor nass und dann beim nächsten Mal sagt sie wieder ja, lass uns das doch mal abstrahieren, weil das könnte man ja super machen, das soll es natürlich nicht sein, dass man
immerhin und her geht. Aber in dem Fall hatten wir das dann nochmal umgebaut und mehr das Kiss Prinzip angewandt um halt eben die diese Lösung möglichst einfach zu gestalten, auch wenn sie dann nicht mehr so manche würden es elegant nennbar
hinterher. Und das ist, weil du meintest, ihr habt dann das Prinzip angewandt, finde ich halt spannend, weil so grundlegend von der Definition oder der Philosophie her sind sie ja eigentlich nicht gegensätzlich, die Prinzipien. Also du kannst ja sagen, ich möchte mich nicht wiederholen und ich Sorge dafür, dass es so diese einheitliche Wissensbasis gibt, und die kann ja auch einfach und straight geschrieben sein.
Das Problem ist, und das zeigt auch das Beispiel mit dieser Tabelle ganz gut, wenn ich jetzt so krass in dieses Rapid hole gehe, dass ich sage, nee, ich muss das jetzt hier verallgemeinern, ich muss jetzt ne einheitliche Wissensbasis schaffen, aber ich möchte alles da drin abbilden können und ich abstrahiere und abstrahiere, dann gehe ich so extrem in die Dry Richtung, dass quasi dieses Kiss Prinzip komplett verletzt wird. Wenn ich jetzt sage, ich möchte
beides. Eigentlich einhalten und genauso, wenn ich es total vereinfache, werde ich irgendwann an den Punkt kommen, dass ich mit einfachen Funktionen ja nicht mehr schaffe, mich nicht mehr zu wiederholen, weil es einfach zu unterschiedlicher Kontext dann auf einmal ist. Das heißt, ich werde Sachen doppelt schreiben, wenn diese Funktion einfach sein sollen oder nicht komplex so rum, das ist besser gesagt.
Dass man sich das wieso eine Gewichtung vorstellen kann von beiden Prinzipien. Und dann musst du gucken, in der Mitte zu bleiben und nicht nach links oder rechts weg zu driften. Vielleicht kann man sich so das ganz cool vorstellen. Ich finde, man kann an der Stelle auch noch mal ein bisschen abgrenzen.
Welche? Also für mich ist dieses dry Prinzip, beispielsweise um das noch mal ganz kurz zu sagen, hat 2 verschiedene Facetten, weil auf der einen Seite hast du ja die Möglichkeit zu sagen, ey, du hast. Code duplikationen, die du einfach in eine Funktion auslagerst und das ist zum Beispiel ne Sache, wo definitiv die Komplexität des Codes nicht steigt.
Das ist auch keine Abstraktionsebene, von der wir hier reden, wenn wir von abstraktionsebenen reden ne, sondern eher wenn man jetzt zum Beispiel sagt Okay, du hast vielleicht irgendwie ein Interface, wo verschiedene Implementierungen zu diesem Interface dahinter hängen und dann hast du zum Beispiel eine Abstraktionsebene gezogen, die unter Umständen. Je nachdem, wie viele du davon brauchst, irgendwann das ganze sehr, sehr komplex und
undurchsichtig macht. Das sind nicht so 2 verschiedene Sachen, weil das eine ist Don't repeat yourself, das andere auch, aber auf verschiedenen Ebenen. Genau. Und dann? Nimmst du das Kiss Prinzip und sagst okay du kannst ja zum Beispiel sagen, ich habe eine Lösung und diese beiden Lösungen hast du einmal eine Lösung, die ist sehr sehr einfach und
straight. Und einmal hast du eine Lösung, die ist sehr, sehr kompliziert und führt aber am Ende zum gleichen Ergebnis. Das wäre so, wie wenn du jetzt zum Beispiel, sagen wir mal, du erklärst ein gesellschaftliches Spiel auf eine super einfache Art und Weise und jeder versteht sich sofort und sagt ja alles, klar, verstehe ich.
Und auf der anderen Seite gibt es n anderen, der erklärt das gleiche Spiel total kompliziert, ist aber am Ende das gleiche Spiel und keiner versteht es so. Da ist natürlich klar der einfache straighter Ansatz besser, bedeutet ja aber nicht zwangsläufig, dass du bei deiner einfachen Straightnerklärung beispielsweise nicht dich vielleicht mal wiederholst. Also kann ja vorkommen und dann kannst du ja sagen okay pass auf, ich habe eine einfache Lösung, da habe ich vielleicht
ein paar. Code duplikationen drin oder was auch immer. Und natürlich kann man dann sagen, ich nehme auch noch mal 3 mit rein, also handle nach dem Dry Prinzip und. Entferne sozusagen Redundanz so also deswegen wollte ich noch mal sagen, das ist ja genau, um das noch mal zu unterstützen, was du meintest, es sind ja nicht 2 Prinzipien, die gegeneinander arbeiten, sondern die können ja Hand in Hand gehen.
Genau. Und das eine kann halt auch dafür sorgen, dass das andere noch besser umgesetzt ist. Nur dass sie extremfälle dann schnell quasi in die andere Richtung kippen können und das dann doch wieder in die Farbe. Richtung in Sachen gut entwickelter Code wie auch immer gut bei jedem aussieht. Aber jetzt nach diesen Prinzipien gut entwickelter Code, dann halt wieder in die Gegengesetzte Richtung kippt. Mal so ein dieses Kiss Prinzip, wenn man jetzt mal so Analogien ziehen möchte.
Beispiele so wie was kann man sich darunter vorstellen, ich. Find das was bei mir so n Beispiel ist. Ist zum Beispiel N Taschenrechner. Das klingt jetzt n bisschen weit hergeholt, aber es gibt ja so verschiedene Arten Taschenrechner, ne, es gibt diesen ganz einfachen. Wo du so n bisschen Preise zusammen addieren kannst, weißt du, der kann halt so plus minus geteilt mal und du kannst halt so.
Hast halt 0 bis 9 deine Zahlen und es gibt die die halt schon irgendwelche mathematischen Funktionen können. Oder weißt du die so für die in wissenschaftlichen Bereichen verwendet werden oder keine Ahnung im Matheunterricht ab klasse 10 oder weiß ich ab wann wo du denn sagst okay wir brauchen jetzt einen krasseren Taschenrechner der weiß ich was berechnen kann. Rechenschieber genau das ist so die einfachste Form. Jetzt muss ich kurz da mit Rechenschieber ist natürlich super.
Stell dir mal vor du machst so das Watte Abi oder deine Abschlussprüfung allgemein und kommst mit so einem Rechenschieber an, also entweder ist ein absolutes Genie oder völlig wahnsinnig genau verdammt noch mal von vorne alles zurückgeschoben. Okay auf Topic beendet und dann ist ja genau die Sache so. Keine Ahnung, du hast eine Tasse für eine Division und du willst es eigentlich.
Du sagst, ich will jetzt 2 zahlen voneinander dividieren beispielsweise und dann fängst du ja nicht an bei so einem simplen Taschenrechner zu sagen, na ja, aber warte mal was für ne Division will er denn machen an der Stelle? Vielleicht geb ich ihm jetzt aber noch ne Zusatztaste und er konfiguriert erst diese Division. Will er ne ne bruchzahl danach haben oder will er ne Ganzzahl Division machen? Nee das muss mir der Anwender jetzt erstmal sagen, weißt du also so mal als Analogie, dass
du dir denkst, nee, keep it simple. 90% der Leute oder 99% der Leute wollen einfach keine Ahnung, irgendwelche Zahlen miteinander dividieren und dann soll ne Bruchzahl am Ende rauskommen um im Durchschnitt zu berechnen oder so weißt du beim Einkauf keine Ahnung oder oder wir haben jetzt in der Gruppe hat jeder mal jetzt ein Bier geholt, hier weißt du wir waren alle was trinken und was hat es jetzt pro Person gekostet im Durchschnitt sowas weißt du dann also die Taschenrechner App die
standardmäßige ist ja auch super simpel gemacht. Das stimmt also ich find immer, also mir hat das auch tatsächlich schon oft geholfen und auch im Team geholfen. Also ich bin totaler Verfechter davon, mir zu sagen. Wie geht es denn super einfach? Also ich versuche also das das ist tatsächlich irgendwie ich, ich manchmal.
Ich weiß nicht ob du das kennst, aber manchmal hab ich dann auch das Gefühl, bin ich vielleicht doch einfach zu einfach gestrickt, dass ich nur Lust habe, mir zu versuchen. Ne komplexe Lösung versucht also es nicht einzugestehen, also dass ich nicht es mir eingestehen möchte, dass eine
Lösung auch komplex sein muss. Manchmal könnte vielleicht auch so ein kleines Problem sein, weil ich möchte mal gerne sehr einfache Lösung und manchmal klappt's und das hilft dann auch und manchmal klappt es halt eben nicht, also zum Beispiel in der Vergangenheit hatte ich auch im Team. Wenn ich dann im Pair Programming mit einem
Teamkollegen gearbeitet habe. Wo also wurden gleich so bei bestimmten Lösungen kam so richtig komplexe Ideen raus und ich so, na lass uns das doch vielleicht erstmal einfach machen, weil guck mal, wir brauchen doch eigentlich nur sowas zu machen und das hat auch. Dazu geführt, dass die Lösung am Ende tatsächlich einfacher wurde. Und das fand ich schön.
Aber manchmal, wo die Lösung vielleicht wirklich nicht so einfach und simpel gehalten werden konnten, habe ich mich mich dann manchmal gefragt, so hm. Vielleicht bin ich auch ein bisschen beschränkt, ich weiß es nicht. Also weißt du, ich weiß nicht,
ob du kennst das Schwein aber. Also das ist mal mal ganz als blödes Beispiel vielleicht oder nicht als blödes Beispiel, sondern vielleicht als Beispiel, was man sich auch vorstellen kann, wenn du. In deiner Anwendung etwas asynchron machen musst und aber sagst Ey synchrone Bearbeitung codebearbeitung ist doch viel einfacher, es aber nicht funktioniert synchron, dann kannst du ja so oft versuchen zu zu sagen, ey lass doch mal das ganze synchron und einfach auch
verständlich zu machen. Wenn es aber nur asynchron funktioniert, weil die Anwendung das so hergibt oder der Prozess der dahintersteckt, weißt du das als Beispiel. Naja klar, weil das sequence seller kannst du einfach im Kopf einfacher bilden und auch codechn. Ist leichter verständlich. Logisch ist n ganz gutes Beispiel auf jeden Fall, aber es gibt halt einfach Sachen, die kannst du nicht, die kannst du dann nur asynchron lösen, das ist auch n wirklich n klassisches Beispiel.
Was bei mir, ich kann auch so aus der Vergangenheit noch einen kleinen Plausch mal einwerfen. In meiner Embedded Zeit hatte ich auch mal ne Phase im Projekt weiß ich nicht.
Auf jeden Fall weiß ich wie ich es nennen soll, da habe ich mich auf jeden Fall darum gekümmert, dass wir so ein Inhouse library geschrieben haben und das war halt in der C Welt so eine Header Only inline Library, die war die Funktion die ich da geschrieben habe, waren halt hoch nach hochoptimiert klingt jetzt zu hoch dran, aber ich habe versucht sie bestmöglich zu
optimieren. Weil klar im amented Bereich hast du halt beschränkte Ressourcen und da muss das halt schon alles passen und dann ist es halt wirklich so ein Rabatt Hay und das finde ich hat nichts damit zu tun, dass denn Leute sag ich mal beschränkt sind in Ihrer Vorstellungskraft das zu verstehen oder so, aber du beschäftigst dich ja tagein tagaus damit und steckst halt voll in dieser Materie drin und für dich ist das logisch, was da Komplexes passiert.
Weißt du also das so? Wenn ich jetzt glaube ich jetzt 23 Jahre später, weiß nicht wie lange das erste drauf gucken würde, würde ich nur noch sehen, dass irgendwelche Bits da durch die Gegend geshiftet werden. Irgendwelche Funktionen, die Funktionen sind Gott sei Dank, da bin ich mir sicher, so benahmt, dass ich verstehe. Was das Resultat ist, davon aber die Implementierung. Ja würd ich glaub ich jetzt auch
nicht mehr sofort durchdringen. Das heißt es ist wirklich nen ne ne Frage wie nah du an dieser Entwicklung dran bist.
Um diese Komplexität greifen zu können und genauso ist es ja auch, wenn du sehr komplexe asynchrone Prozesse hast, macht es für dich vielleicht Sinn. An der Stelle und für andere ist es aber n enormer Aufwand sich da reinzudenken und deswegen bin ich von damals wie es umgesetzt hab, irgendwann gedanklich weggegangen und wieder mehr Richtung dem Kiss Prinzip, dass ich mir dachte, war es das jetzt wert ist so komplex zu machen, weil es sind auch Kollegen zu mir gekommen, die dann an dieser
Library weiterschreiben wollten und aber nicht wussten was Niveau das ist. Ähnlich wie dein Tabellenbeispiel. Und dann dachte ich mir, war es das jetzt wert, vielleicht diese 1 2% noch rauszukitzeln. Wenn jetzt aber niemand damit arbeiten kann, übertrieben gesagt, weil das Halt wirklich komplett fernab von dem Kiss Prinzip Dame ja. Und das meinte ich ja auch schon in dem in der anderen Folge von dem 3.
Prinzip, das. Man natürlich Sachen optimieren kann ohne Ende, aber immer den Trade auf dem Kopf haben muss. Okay wie stark wird das noch weiterentwickelt, wieviel wird denn da auch noch vorausgesetzt, dass andere Leute das verstehen und natürlich auch noch zu gucken, wer aber mit einem also.
Jeder hat ja vielleicht auch so seine Qualitäten und in dem Fall warst du zum Beispiel jemand, der das Halt hingekriegt hat, das möglichst stark zu optimieren und n anderer Kollege hat dann vielleicht andere Qualitäten, aber ist dann vielleicht nicht so stark da drin diesen Code, dann diesen optimierten Code so gut zu verstehen. Und wenn du jetzt aber zum Beispiel jemanden hast, wo du weißt, keine Ahnung, wir sind so, wenn ich sage hier. Ich hab's absolut ausoptimiert, sagt er.
Haha, ich hab noch nicht mal angefangen, das Auszuoptimieren, also das sind ja dann dann dann weiß der okay es kommt immer finde ich, auch ein bisschen darauf an, mit wem man dann arbeitet und wo die Qualitäten liegen und ich finde, das ist auch ein generellwichtiger.in der Teamarbeit, wenn du weißt, mit wem du arbeitest, weil du kannst. Natürlich weiß ich nicht, unglaublich komplexe Lösungen
schaffen. Und kann du kannst dich dafür auch feiern, aber die Frage ist Halt, bringt es dir was in diesem Team, dann sozusagen. Wenn das aber am Ende eher behindert, das gesamte Team und die den gesamten Fortschritt kleiner Exkurs jetzt gerade, aber ich finde das ist ein wichtiger Punkt, den manche glaube ich auch nicht so richtig vor Augen haben. Ja ja, ist halt die Frage mit wem wie du so schön meint es mit wem arbeitest du daran und was
für ein Produkt ist es am Ende? Man konnte es jetzt insofern rechtfertigen, dass diese inhouse library ja quasi nur Anwender hatte und wenig Entwickler. Die war jetzt auch nicht so riesig. Hat aber im Prinzip auch so ein bisschen das 3. Prinzip unterstützt zu sagen okay wir lagern diese Funktion, die wir an vielen Stellen brauchen.
Es waren halt auch so mathematische Berechnungen und sowas, das lagern wir halt aus in eine eigene Lipp und die kannst du dann einfach einbinden sozusagen und verwenden, das heißt du hast halt mehr Anwender am Ende, aber trotzdem gab es ja den Punkt, dass sie erweitert werden sollte von anderen Entwicklern. Und dann hast du halt den Salat, sozusagen ne, weil dann ist es halt auf einmal echt komplex, da
kleine Änderungen zu machen. Ja und das ist halt nicht cool dann so und wenn du jetzt sage ich mal von Grund auf an einem Produkt arbeitest oder ein sagen wir mal allgemein an einem Projekt wo viele Entwickler sind, wo auch vielleicht in Zukunft noch Entwickler dazu kommen, dann willst du den ja nicht unnötig die Einarbeitungszeit schwierig machen, das heißt dann sollte es schon eher. Der Fokus auf Wartbarkeit und Verständlichkeit liegen
sozusagen. Und dann kann man sich manchmal, wie gesagt, in anderen, sagen wir mal, sind wir mal bei Web Applikationen oder so ey, ganz ehrlich, da kannst du auch diese 1 2% wirklich pfeifen und sagen, nee es ist viel wichtiger, dass die Leute es verstehen halten. Ja, auf jeden Fall.
Und da, das ist halt immer so, dieser Trade, auch bei diesen, bei so einem Prinzip dann am Ende deswegen ist finde ich dieses Kiss Prinzip auch wie du meintest, dass du Verfechter davon bist oder es magst erstmal den Simpl. Zu verfolgen kann ich halt absolut nachvollziehen und ist es auch oftmals der der richtige Weg so zu starten.
Was ich manchmal schwierig finde, ist, ich weiß nicht das das das kennst du ganz bestimmt auch, aber stell also sagen wir mal man programmiert ne. Neue Funktionen. Irgendwas. Sag ich jetzt mal. Du musst irgendwas sortieren und. Irgendwas mit Kot. Meinst du sagen wir mal du musst was sortieren? Du musst dabei noch irgendwas filtern, du musst dann noch irgendwie die Daten mappen oder verändern auf ne gewisse Art und Weise und so weiter und dann
hast du vielleicht. Ein Array von Objekten und innerhalb dieses Objektes hast du ein Attribut oder eines solchen Objektes. Hast du ein Attribut, was auch wieder ein Array ist. So, und das musst du alles irgendwie durchgehen. Dann musst du das kurz mal im Kopf. Sehen.
Im Endeffekt hast du, wenn du sozusagen also im Worst case hast du so eine n hoch 2 n quadratkomplexität, weil du ja sagst ich gehe einmal durch alle Objekte durch und muss dann vielleicht noch mal bei jedem Objekt noch mal durch das eine Array. Laufen so zum Beispiel. Und. Klar weiß ich, dass es definitiv eine bessere Lösung gibt als mit 2 Vorschleifen darüber zu
laufen. So, aber deswegen finde ich es trotzdem nicht schlimm, wenn jemand sagt, EY, ich will jetzt erstmal kurz mit 2 vorschleifen drüber laufen. Weil voll oft hab ich erlebt, dass jemand das zum Beispiel
machen möchte. Manchmal mach ich das auch selber, ne, dass ich sage, komm ich mach es jetzt erstmal zum Beispiel ne neue Sprache du. Bist vielleicht noch nicht so drin in dieser Sprache und vielleicht kannst du das funktional lösen oder so ne, also auf ne andere Art und Weise, dass du jetzt nicht irgendwie diese 2 vorschleifen
ineinander geschachtelt hast. Trotzdem finde ich, dass es manchmal erst mal sinnvoll ist zu sagen, ich versuche diesen Sachverhalt, den ich mir gerade vorstelle, diese Funktion schreibe ich erstmal runter und wenn es erstmal 2 vorschleifen sind so und dann kann ich das ganze ja hinterher immer noch einmal. Optimieren, verbessern, ne andere Möglichkeit nehmen im optimalen. Im Optimalfall hat man Tests dazu, die dir sagen, Ey das funktioniert auch, du kannst jetzt refatern wie du.
Willst und dann kannst du es ja und. Manchmal hilft es auch einfach, was ich mitgekriegt hab, weil ich auch schon mit Leuten gearbeitet habe, die sozusagen in der Ausbildung waren. Wenn man es so nennen möchte, habe ich gemerkt, dass es auch diesen Leuten einfach hilft fürs Verständnis, dass man das erstmal auf diese Art und Weise
macht, weil. Es bringt dich im Team, sage ich jetzt mal, mit diesen 2 Leuten, mit denen du dann arbeitest, auch direkt weiter, wenn du die andere Person auf deinem Level
sozusagen abgeholt hast. Dass du weißt, weißt du, wo wir hin wollen, ja, weiß ich, und dann kannst du viel besser auch mit der Person arbeiten, als wenn du sagst, Pass auf, wir machen das jetzt so und so, und dann ist die Person schon raus und denkt sich okay ich weiß gerade gar nicht, was hier passiert und im Worst case kann diese Person, das traut sich nicht zu sagen, dass sie da nicht hinterher kommt oder so, also. Solche Sachen. Also einfach mal ein paar Facetten, wo ich mir denke.
Ich finde es absolut valide zu sagen, klar geht das meistens besser als einfach 2 vorschleifen ineinander zu verschachteln. Aber fang doch erst mal so an. Ist doch ne einfache Möglichkeit, dann kann man das immer noch besser machen oder verschönern.
Ja, also es ist halt auch extrem sprachenabhängig da ne, also du hast ja dann irgendwie so Best practices in jeder Sprache wie man sowas lösen kann, weil du ja schon meintest, dann filterst du oder keine Ahnung, rufst irgendeine Flat Funktion auf um erstmal diese. Diese Dimension da rauszukriegen oder wie auch immer ne, das ist ja dann wirklich sprachenspezifisch und wahrscheinlich gibt es da auch schönere Lösungen. Dann und da ist halt der Trade Off, ist die Lösung schöner im Sinne von.
Weniger Code und immer noch super verständlich. Ne oder was was man ja auch öfter schon gesehen hat ist, dass irgendwie ne wilde Kombination an irgendwelchen Funktionen aufgerufen werden. Es funktioniert, das Ergebnis stimmt, aber eigentlich hängst du jetzt da und guckst dir diese Verschachtelung an okay was ist der Input von dieser Funktion?
Das okay, aber der Input ist wiederum eine Funktion, ein Ergebnis, eine andere Funktion und dann guckst du erstmal was kommt da raus, was kommt denn da raus, wo du so richtig deep Dive in der Sprache drin sein muss um das sofort zu verstehen und das ist dann so wie du meinst. So für neue die ins Projekt kommen, die vielleicht erstmalig mit dem Framework oder der Sprache arbeiten, dann halt auch nicht mehr so einfach und das ist halt immer dieser Trade Off am Ende.
Ich fand das super lustig. Und deswegen finde ich. Erstmal was du findest, sorry. Also deswegen finde ich, dass man dieses Kiss Prinzip genauso wie auch das Dry Prinzip einfach immer so ein bisschen im Hinterkopf haben sollte, dass man da ruhig mal auf seine erste. Auch mal hören kann. Und selbst wenn die 2 Vorschleifen sind, die verschachtelt sind, dann mach es
erstmal. Warum nicht klar, wenn du jetzt natürlich im Kopf schon hast, weil du dich wirklich vielleicht gut in der Sprache auskennst, dass du es eleganter lösen kannst und es trotzdem noch verständlich ist, dann kannst du natürlich auch das machen, das ist jetzt nicht gesagt, ich muss erst mal den Simpelsten weg gehen, sozusagen. Aber ich finde es im Hinterkopf zu behalten ist halt schon. Sehr essentiell und verbessert auch die Codequalität würde ich
schon sagen. Und was ich, was ich eben noch sagen wollte, ich hatte das mal mit, als ich angefangen habe mit Kotlin, da hatte ich ein Projekt, da sind wir von Java auf Kotelett umgestiegen und Kotelett hat mir einen sehr hohen Anteil oder eine Möglichkeit, funktional zu programmieren, und das haben wir dann auch so gemacht.
Dann waren wir aber manchmal an einem Punkt, dass dann auch jemand, ich weiß gar nicht mehr, ich krieg es nicht mehr 100% zusammen, aber ich glaube, es kam dann jemand ins Team, der sich auch noch besser mit Content aus. Das auch schon länger gemacht hat, der hat damit gearbeitet hat und hat dann zum Beispiel auch.
Also du musst dir vorstellen, das war ne Menge von, also ne Menge viele Verarbeitungsschritte in einer Funktion, das heißt du hast zum Beispiel dir deine Liste Set map, Objekt was auch immer ne hast du genommen und hast dann immer aufgerufen Map Filter mach dies Punkt mach das Punkt und so weiter das heißt du hast so Verarbeitungsschritte gehabt die man dann auch sieht an sich eine schöne Sache.
Witzigerweise wurde dann einmal so das Ganze auseinander genommen und an einigen Stellen hieß es so ja okay. Also das hier ist zum Beispiel völlig, also bringt nichts.
Also du könntest zum Beispiel diese 3 Sachen auch weglassen, einfach nur das machen, also eine andere Funktion an die Stelle einsetzen und das ist dann auch so ein bisschen so eine Limitierung wieder, weil wenn du dich damit nicht auskennst, ist es vielleicht ganz schön und es sieht vielleicht ganz gut aus, aber auf der anderen Seite hast du vielleicht völligen Overhead, weil du einfach dir denkst.
Und jetzt haue ich noch die Funktion oben drauf und dann kommt noch die Funktion. Und dies. Konnten auch ne Funktion. Und das war das. Und dann wieder zurück zum Anfang und wieder von. Das war dann manchmal, also gerade am Anfang, auch bei bei Kotlin auch sehr interessant und? Ja, ja, das ist doch n klassischer Fall von Over Engineering am Ende. Du versuchst halt, denn so krampfhaft das geil zu machen, war blöd gesagt.
Also du denkst ja, ich will jetzt so richtig geilen Code schreiben und wir haben die Funktion und die verwenden wir jetzt auch und dann kommt jemand und sagt Na ja Leute aber also wenn ihr das schon machen wollt, dann habt ihr. Über um 5 Ecken gedacht, macht es doch einfach so und so und das ist ja auch wieder cool. Dann von dieser Erfahrung zu profitieren und da merkt man dann wieder Keep it simple. Warum? Warum bin ich überhaupt in diesen weggegangen? So ne, das ist doch eigentlich
völlig unnötig. Gewesen. Aber natürlich hat man auch immer noch mal natürlich das auch zu Challengen und zu sagen, ja gut, Keep it simple, so weit wie es halt eben geht, was natürlich auch definitiv ein Punkt ist, ist, dass es natürlich auch öfter mal, das kennen wir ja selber, man hat eine Aufgabe, sagt okay wir nehmen jetzt erstmal eine einfache Lösung und es fallen einem dann aber trotzdem immer noch weitere Edge Cases ein. Du denkst dir so ja okay, aber was ist denn in der Situation
und in der. Und dann? Dann ist es ja schon manchmal so, dass sozusagen, wenn man jetzt davon ausgeht und sagt, Nimm doch einfach die erstbeste Lösung, die dir einfällt. OK, ist bestimmt erstmal n Ansatz, aber es kann durchaus sein, dass die der Funktionsumfang dann wenn man n bisschen länger über bestimmte Sachen nachdenkt oder über n Feature in der Software oder so, dass es dann durchaus sein kann, dass.
Der erste Ansatz, vielleicht auch einige Punkte vernachlässigen würde, die dann runterfallen würden. Dass er die Challenge dann am Ende ne. Also wenn ich jetzt sehr engstirnig dieses Prinzip durchsetze und mir wirklich denke, so das erste was in meinen Sinn kommt, das ist die Lösung und dann habe ich aber halt nur sozusagen den Happy Pass berücksichtigt, der funktioniert dann auch, aber wie du so schön sagst, dann kommen die Edge Cases dazu und dann wird zwangsläufig die
Komplexität steigen müssen. Und dann fährst du halt mit dem Kiss Prinzip, wenn du es so richtig Straight durchziehst auch nicht mehr gut am Ende, sondern wirst Gefahr laufen, dann sozusagen an den Anforderungen vorbei zu implementieren, weil du halt gewisse Fälle nicht betrachtest. Dann mit deiner Lösung oder nicht abhängst.
Obwohl man ja natürlich, und da können wir noch mal sozusagen auf die anfängliche Definition zurückgehen, es geht ja darum, sozusagen unnötige Komplexität zu vermeiden. Da muss man halt dann einfach gucken, dass man sozusagen den Blick fürs Wesentlichen. Nicht verliert, weil wenn man sagt, ich mach es jetzt ganz einfach, könnte es natürlich dazu kommen, dass man eben solche Edge Cases außer 8 lässt, die ja aber eigentlich sozusagen ne notwendige Komplexität haben
um das Feature zu erfüllen. Genau, ganz genau.
Weil deswegen steht da ja, also deswegen sagt man ja unnötig, weil an der Stelle ist es dann notwendig, wie du so schön gesagt hast, aber das ist die Gefahr, wenn ich jetzt so richtig straight in dieses Prinzip gehe, dass ich sowas dann übersehe und mir nicht denke, nee, es ist schon notwendig an der Stelle diese Komplexität zu erhöhen, sondern mir denke, Nein, Komplexität ist schlecht, es muss alles ganz einfach sein, und das ist ja, das ist halt diese Balance dann
einfach. Zwischen dieser Einfachheit und Komplexität, das zu schaffen, also quasi richtig zu entscheiden, was es nötig und was ist unnötig, und das ist nicht einfach, das würde ich jetzt mich auch nicht hinstellen. In erster logischen Fall A ist es so nötig. Im Fall B ist es notwendig, so dass, so ist es ja nicht, aber wenn man es im Hinterkopf behält, dann Challenge man zumindestens die Entscheidung und das ist ja ne der wichtige Punkt dabei.
Aber da spielen natürlich auch ne Menge Anforderungen wieder mit rein. Haben wir übrigens, liebe Zuhörer, lieber Zuhörer, wenn dich das auch interessiert und du vielleicht auch mal die ein oder andere Challenge mit Anforderungen in deinem. Software Entwicklungsleben hattest, dann hör dir gerne die Folge über Anforderungen an. Auf jeden Fall ja auch ein sehr spannendes Thema. Ja, aber magst du es noch mal n bisschen zusammenfassen?
Also wir haben ja jetzt ne Menge Vorteile, aber auch Herausforderungen dabei beleuchtet auch mal so n bisschen. Ja, persönliche Erfahrung dazu gegeben. Magst du das noch mal jetzt so on Point zusammenfassen für unsere Zuhörerinnen und Besucher? Als Tino Ich versuche es. Aber schön einfach und keine unnötige Komplexität ist. OKOKOK jetzt ist aber ganz viel Druck auf mir. Nein, also. Das Kiss Prinzip soll dafür
sorgen, oder? Das kann man im Hinterkopf behalten, um einfache, verständliche Lösungen zu generieren, die am Ende natürlich auch ne wartbare Software ermöglichen. Und. Da soll man halt einfach drauf achten.
Natürlich das einfach zu gestalten, aber so einfach oder die Komplexität soweit zu vermeiden, wie es auch überhaupt funktioniert, das heißt, da ist diese diese schmale Gratwanderung, die wir gerade beschrieben haben, wichtig zu sagen, man versucht den Code möglichst einfach zu halten, klar, aber muss im Hinterkopf auch behalten, dass man sozusagen nicht aus Versehen den Wald vor lauter Bäumen nicht mehr sieht und sagt, jetzt vergesse ich aber auch noch
verschiedene andere Edge Cases oder Rationalisier die Weg. Wäre ja zu komplex, weil wenn diese Komplexität wichtig ist und notwendig ist für einen einen Funktionalität, dann muss man die natürlich auch mit reinnehmen. So würd ich das jetzt zusammenfassen. Ja, das find ich ja. Hast du sehr gut auf den Punkt gebracht, unnötig, nicht unnötig komplex so. Vielen Dank dafür. Ich würd sagen, wir haben es doch, es ist ja n relativ kleines Prinzip, aber wo man
sehr lange drüber reden kann. Ich würd aber jetzt sagen, dass wir es ausführlich besprochen haben, deswegen würd ich jetzt die Folge an der Stelle beenden, ist dann heut mal ne etwas kürzere Folge, wenn das für dich in Ordnung ist. So, ansonsten machen wir noch 30 Minuten off topic jetzt, da
fällt uns schon was ein. Alle noch mal dran denken zögert nicht einfach mal die ersten Ideen niederzuschreiben und auch wenn das Ganze noch nicht optimiert ist oder was auch immer, erste Idee einfach mal in Anführungsstrichen Blatt Papier bringen und dann gucken wie sich das Ganze noch weiterentwickelt, aber damit auf jeden Fall erst mal anfangen, weil das auch gerade am Anfang wenn man anfängt mit der Softwareentwicklung finde ich auch hilft.
Bevor man sich irgendwie keine Ahnung da total rein denkt und den Kopf zerfrisst einfach mal starten mit einer einfachen Lösung und dann kann sich das Ganze weiterentwickeln und das hilft für Starter, aber auch für Advanced Softwareentwickler und Entwicklerin. Auf jeden Fall, weil du ja denn in das Problem reinwächst sind die Aufgabenstellung und dann dir quasi on the Fly bei der Entwicklung dann die weiteren Lösungen oder Optimierungen einfallen. Aber du musst halt erstmal einen Fuß.
In die Tür kriegen oder sowieso? Ist doch so eine Richtung, oder? Das war auf jeden Fall das, was mir auch zum Beispiel früher nicht früher auch stark limitiert hat. Deswegen wollt ich das gern noch mal. Ja, als Tipp mit n sehr wichtiger Punkt. Ja, dann würde ich sagen, bleibt mir auch nichts anderes übrig, als diese wunderschöne Folge abzumoderieren. Also liebe zuhören, liebe Zuhörer, falls dir die Folge gefallen hat und du oder oder Feedback hast, auch sehr
wichtig. Unsere Podcast Mail findest du in den Shownotes. Meld dich sehr gerne bei uns, lass uns Feedback zukommen, allgemein zum Podcast zu diesem Thema wie du das Kiss Prinzip betrachtest, ob du es cool oder eher nicht so cool findest, vielleicht hast du auch Vorschläge für andere Themen, wir sind da echt offen, kommen Austausch mit uns oder schaut den anderen Plattformen von uns vorbei, die Links dazu findest du auch in den Shownotes
empfiehlt gerne den Podcast weiter, wenn er dir gefällt, das hilft uns auch und würde uns super freuen. Du findest auch einen Link zu einer spendenseite, falls du dir denkst, hey Mensch Leute, ihr macht das richtig cool. Ich würde euch gerne unterstützen, dann schon mal jetzt vielen vielen Dank dafür. Ansonsten Liebe geht raus. Genau, vielen Dank fürs Zuhören. Ich würde sagen, in diesem Sinne der Folge Keep it simple und bis zum nächsten Mal deine Coding Buddies gemeinsam besser. Was?