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?