Latest / Coding Buddies | Tech & Dev-Mindset / Simpler Code == Besserer Code? Das KISS Prinzip

Transcript

Simpler Code == Besserer Code? Das KISS Prinzip · Coding Buddies | Tech & Dev-Mindset

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