Latest / Coding Buddies | Tech & Dev-Mindset / #145 Neues Jahr, saubere Architektur – spar dir 100 Stunden Refactoring

Transcript

#145 Neues Jahr, saubere Architektur – spar dir 100 Stunden Refactoring · Coding Buddies | Tech & Dev-Mindset

0:00
Also ich hab mich immer vorne hingestellt, hatte so 5 Jacken
0:03
an und hab dann meine Architektur erklärt, indem ich
0:05
immer so eine Jacke mehr ausgezogen hab als.
0:07
Mies geschwitzt bis dahin. Coding Buddies Dein Podcast rund
0:12
um Softwareentwicklung und aktueller Tech News herzlich
0:16
Willkommen. Halli Hallo und herzlich
0:30
Willkommen zur neuen Folge des Coding Buddies Podcast.
0:33
Ein neues Jahr ist gestartet, es geht wieder los.
0:36
Wir sind natürlich wieder dabei und am Start, wir werden dich
0:39
dieses Jahr wieder begleiten und deswegen erstmal Fabi herzlich
0:44
willkommen im neuen Jahr und zur neuen Folge was geht ab.
0:47
Keep coding Tino, keep coding fabi.
0:51
Das ist nicht Diät, das ist nicht nur die Neujahrsfolge ne,
0:54
nicht nur eine neue Folge, sondern die Neujahrsfolge so
0:57
rum. Ja, richtig, richtig krass,
0:59
oder? Ja, also vor allem geil, dass es
1:02
so ne Punktlandung ist. Auch ne ja stimmt, das ist genau
1:05
der erste heute, ja es ist es geht los, quasi das ja gerade
1:10
los, es geht los, ja wie ist es dir so ergangen, bist du gut
1:16
reingerutscht ja ja ich würd sagen ich würd jetzt mal nicht
1:19
meckern ja wir halten gar nicht verkatert aus ja wir halten
1:23
krass wir halten jetzt live fest ja.
1:26
Auditiv, dass wir nicht verkatert sind.
1:29
Ja, hast du dir auch 5 Kopfschmerztabletten vorher
1:32
reingeworfen? Klar und ne tatsächlich ne,
1:39
tatsächlich bin ich ganz fit, das ist ganz cool, ich hab auch
1:42
richtig Bock auf die Folge, aber ich würd gern mal noch mal so n
1:44
ganz klassisches Thema weil es ist passt halt so perfekt das
1:48
ist so der 1.1. Ne müssen da jetzt einfach ganz
1:51
kurz drüber reden, auch wenn es zu klischeehaft ist.
1:53
Neujahrsvorsätze ne. Hast du welche?
1:58
Ja, du weißt ja, wie das bei Neuers Vorsitz noch mal ist.
2:00
Weißt du, man denkt sich so, oh, ich nehme mir dies vor, ich
2:02
nehme mir das vor und dann hinterher guckst du drauf und
2:04
denkst dir so scheiße habe ich ja gar nicht gemacht, deswegen
2:07
habe ich mir jetzt einmal vorgenommen, dass ich mir sage,
2:09
ich möchte, ich habe mir wirklich vorgenommen, dieses
2:12
Jahr Software zu entwickeln, weil ich glaube, ich schaffe es.
2:17
Okay krass krass. Also einfach mal ein bisschen
2:19
Software entwickeln, so, ja. Ja, ich denke never change a
2:22
running. Ist das möglich, dass du
2:24
schaffst? Ja cool, cool, ja, ich denke ja,
2:26
da bin ich guter Dinge, also notgedrungen wirst du es einfach
2:29
erreichen, allein durch den Job denke ich okay bei mir ist es
2:35
also ich habe wirklich einen Vorsatz, falls es dich
2:37
interessiert und zwar habe ich so für mich ein bisschen
2:41
entschieden, ein Vorsatz für dieses Jahr ist genau ja genau,
2:45
endlich jetzt der muss. Wenn alle quasi aufhören wollen,
2:52
dann denk ich mir, ich fang einfach mal an.
2:54
Ja nee Real talk, ich hab mir vorgenommen dieses Jahr einfach
2:58
n bisschen weniger zu planen. OK.
3:02
Insofern, dass ich einfach Bock hab, n bisschen spontaner und
3:06
flexibler zu werden in meiner Freizeit, weil das war letztes
3:11
Jahr krass, also da war alles so ziemlich durchgetaktet.
3:13
Ja, dieses Wochenende, das nächstes Wochenende, das jetzt
3:16
wieder das. Und so die letzten freien
3:19
Wochenenden wurden dann auch noch verplant und ich dacht mir,
3:21
ey, lass doch mal so n bisschen spontaner werden, einfach mal
3:26
immer mehr so Platzhalter haben, weißt du wo du sagst, nee an dem
3:29
Wochenende plan ich jetzt erstmal nichts direkt wenn ich
3:32
so ein 2 Tage vorher das entscheide OK dann hab ich ja
3:34
spontan Bock drauf aber ich hab halt keinen Bock wieder in die
3:37
Situation zu kommen zu sagen so Oh ey weißt du was jetzt 5
3:41
Wochenende nicht zu Hause nur unterwegs?
3:44
Das kann halt auch schon stressig werden, weißt du, und
3:47
da dachte ich mir, das probier ich mal.
3:48
Ich werd in ungefähr 12 Monaten berichten, wie es funktioniert
3:51
hat. Ich bin gespannt in 12 Monaten,
3:54
aber das witzige ist ich hab mir ich hab mir was ähnliches.
3:57
Ich, ich will nicht sagen vor, also schon vorgenommen, aber
3:59
irgendwie zählt das für mich gedanklich nicht als
4:02
neujahrsvorsatz, weil ich mir das eigentlich letztes Jahr
4:04
schon vorgenommen hab, weil. Es ist einfach n zweiter Versuch
4:09
quasi. Na ja, also nicht.
4:10
Also ich hab es mir letztes Jahr für dieses Jahr vorgenommen,
4:12
aber es zählt nicht als Neujahrsvorsatz, weil ich den
4:16
schon viel früher gefasst hab für das ja jetzt weißt du.
4:19
Ja, aber so sind nicht die Regeln.
4:21
So sind nicht die Regeln. Also es ist jetzt entweder n
4:23
neujahrsvorsatz oder du machst es nicht, da musst du dich
4:27
entscheiden, das Ding ist einfach, also das letzte Jahr
4:31
war super voll wie du auch meintest das.
4:34
War ging bei also war bei mir genau das gleiche und.
4:38
Am Ende des Jahres war es aber n bisschen schöner.
4:40
So weißt du n bisschen entspannter, da hat sich es dann
4:42
gelichtet. Das blöde ist halt, dass ich mir
4:45
das schon öfter auch trotzdem vorgenommen hab, dass ich mir
4:47
zumindest sage, Ey, der Sommer soll jetzt nicht mal nicht so
4:50
voll geballert sein. Und das sind doch gerade die
4:53
Monate, die immer total voll geballert sind.
4:55
Genau und spätestens am. Mai.
4:57
Genau. Und.
4:57
Spätestens im Mai guckst du wieder in deinen Kalender und
5:00
denkst dir so, boah. Vielleicht nächstes Jahr.
5:03
Wir können ja. Weißt du, wenn dann irgendjemand
5:05
fragt, hast du irgendwie Zeit, dann kannst du immer so im Mai
5:08
sagen, Jo klar, auf jeden Fall, wie wär es mit Oktober?
5:12
Ja. Sieht schlecht aus, vielleicht
5:14
Oktober, frühestens. Ja ja, ich wünsch dir auf jeden
5:17
Fall viel Erfolg damit, dass das klappt bei uns beiden, das ist
5:21
ja sehr ähnlich, aber hier natürlich die Anmerkung, das
5:24
Ganze betrifft natürlich nicht das Projekt Coding Buddies, da
5:27
werden wir weiter Vollgas geben, wir haben ja auch ne Menge vor
5:30
dieses Jahr und auch. Schon wieder keine Zeit.
5:32
Da nee, das mal ausgeklammert. Wir haben ja ne Menge vor und
5:38
schon so Ideen, was wir dieses Jahr alles so.
5:41
Anstellen können, sag ich mal. Das wird auf jeden Fall geil.
5:43
Ich hab Bock auf das Jahr und deswegen würd ich sagen, lass
5:46
uns auch einfach mal direkt in die 1.
5:48
Folge des Jahres Reinstarten passt nämlich auch ganz gut, wir
5:51
haben ja heute wieder so n etwas grundlegendes Thema, was
5:55
vielleicht auch so n bisschen einleitend sein können für
5:58
weitere Folgen. Ja, aber ich würd gerne mit dir,
6:02
du hast das ja vorgeschlagenes Thema und ich find es mega cool,
6:05
dass wir da jetzt einfach mal so ganz basic mäßig drüber
6:09
quatschen so allgemein. Ja, also wir hatten
6:13
beziehungsweise ne, es gibt ja so verschiedene
6:16
Softwarearchitekturen und wir hatten ja auch schon über BDD
6:19
gesprochen, also behavior driven Design und domain driven Design,
6:25
was ja so n bisschen sag ich jetzt mal gut zusammen spielt
6:29
und ja auch irgendwie auch auch mit mit Softwarearchitekturen
6:34
gut vereinbar ist, sozusagen. Und deswegen haben wir uns jetzt
6:38
gesagt, OK, lass uns noch mal n bisschen über
6:39
Softwarearchitekturen sprechen, und zwar allgemein über
6:42
Softwarearchitekturen beziehungsweise
6:44
Softwarearchitektur und aber dann halt zum Beispiel auch,
6:48
weil das auch n Wunsch war so hexagonale Architektur ne wird
6:52
dann aber ne einzelne Folge. Ja, also heute mal.
6:55
Fokus. Auf generell
6:57
softwarearchitektur. Was ist das zum Beispiel?
7:01
Beziehungsweise wo? Warum nutzt man das eigentlich?
7:04
Warum sollte man sich darüber Gedanken machen, ist das
7:06
vielleicht auch irgendwie was für Einsteiger, sollte man da
7:10
schon n bisschen Plan von haben oder sagt man dann zum Beispiel
7:13
nee, brauchst du gar nicht am Anfang all so ne Fragen, dass
7:17
man das klärt und einfach logischerweise wie immer auch
7:21
guckt OK was sind unsere Erfahrungen, was läuft da gut,
7:25
was läuft nicht so gut zum Beispiel oder beziehungsweise
7:28
warum. Braucht man das?
7:30
Was sind denn die Vorteile davon?
7:33
Ja, ist natürlich jetzt der ein oder andere, der so richtig Fan
7:37
von Softwarearchitekturen ist oder sich sehr viel damit
7:40
beschäftigt. Denkt sich natürlich gerade so,
7:42
wie kann er es wagen das Ganze in Frage zu stellen, ob man das
7:46
überhaupt braucht, wie kannst du nur, aber ich finde das ist ne
7:50
sehr sehr valide Frage. Weil man ja einfach mal
7:54
begründen oder beziehungsweise mal auseinanderklamüsern sollte.
7:58
Warum beschäftigen sich Leute so intensiv mit diesem Thema, was
8:02
ist der Grund dahinter und das mal zu beleuchten ist ja auch
8:04
gerade wenn ich am Anfang der Softwareentwicklung stehe n
8:08
super spannender Punkt und deswegen find ich es cool, wenn
8:10
wir damit auch so n bisschen einsteigen, Mhm.
8:15
Hast du vielleicht ne Analogie? Also ich ich, die ich jetzt
8:18
gerade so im Kopf hab ist vielleicht nicht die Schönste,
8:20
deswegen hoffe ich jetzt einfach, dass du vielleicht ne
8:22
Coolere hast, die einfach mal so n bisschen zeigt.
8:27
Warum macht man sich beim Cohen darüber Gedanken?
8:32
Also ne richtige Analogie. Also ich finde die absolute No
8:35
brainer Analogie zu der ganzen Geschichte ist so n Gebäude ne
8:39
also wenn du jetzt sagst du baust irgendwie n Haus oder so,
8:42
dann fängst du ja bei na ja. Fängst ja jetzt auch nicht an
8:45
und sagst OK ich bau einfach mal n paar Mauern, leg irgendwo n
8:48
paar Leitungen hin und am Ende denkst du dir so irgendwie wollt
8:51
ich das Badezimmer da haben, aber komischerweise kann ich das
8:54
da gar nicht hinpacken weil ich hab gar keinen Wasseranschluss
8:56
in diesem Zimmer, dann denkt man sich halt irgendwie auch so, er
9:01
ist irgendwie n bisschen blöd ne also man plant ja im Endeffekt
9:04
vorher was man gerne haben möchte und baut es meistens dann
9:09
auch so, dass man irgendwie in der Lage ist auch zu sagen.
9:12
Ich kann vielleicht auch noch was anbauen oder weiß nicht,
9:15
wenn irgendwie mal irgendwo n Schaden ist, dann kann ich den
9:19
vielleicht auch relativ gut warten oder was auch immer ne
9:22
und beziehungsweise reparieren und das ist ja ne Sache.
9:26
Das ist finde ich eigentlich relativ logisch, dass man so
9:30
über bestimmte Dinge denkt, also selbst wenn du selbst irgendwie
9:33
mal was bastelst oder so ne, dann denkst du dir im Zweifel
9:37
auch nicht, na ja. Ich mach es mal so, dass ich das
9:41
zum Beispiel weiß nicht, dass ich damit gar nichts mehr
9:43
anfangen kann. Das ist jetzt so und ich kann
9:45
das nicht mehr verändern oder so ne, egal was so ne, mir geht es
9:50
jedenfalls so ne und genau das ist ja eigentlich auch bei
9:53
Software oder sollte bei Software der Fall sein, dass man
9:56
sich überlegt, OK wenn ich da irgendwie mir ne Software baue,
9:59
dann muss ich ja auch irgendwie in der Lage sein nachträglich
10:02
noch was hinzuzufügen oder sagen wir mal etwas.
10:08
Zu verändern, ohne dass jetzt gleich das ganze
10:10
Kartenhauseinander in sich zusammenfällt.
10:14
Genau und vor allen Dingen auch warten zu können, ne oder
10:16
reparieren zu können wie du meintest.
10:18
Ne, also dass ich halt auch einplane, dass mal etwas kaputt
10:22
geht oder verändert werden muss und es so eingeplant ist.
10:26
Jetzt beispielsweise auch beim Haus zum Beispiel die Elektrik,
10:29
ne, dass ich da halt auch irgendwie noch im Nachhinein
10:31
rankomme oder es erweitern kann, ne?
10:35
Das nicht wie du meinst, alles kreuz und quer geht, sondern
10:38
keine Ahnung ist. Auch sag ich mal ganz trivial
10:40
gesagt n Sicherungskasten gibt wo ich auch mal n bisschen
10:43
Zugriff hab. Ja und das find ich ist n cooles
10:48
Beispiel, gerade weil wir ja von Softwarearchitektur sprechen und
10:56
der gleiche Begriff ja auch bei bei Häusern verwendet wird ne
11:00
also dass du sagst es gibt n Architekten der das plant.
11:04
Ein Konzept erstellt, wie das Ganze umgesetzt werden soll, da
11:07
natürlich die Kundenwünsche, die ja ne riesenrolle spielen, auch
11:11
bei der Softwareentwicklung logischerweise berücksichtigt
11:15
sind. Ja, also wo soll das Button,
11:17
wieviel Räume soll es geben, wie soll die Aufteilung sein, gibt
11:21
es vielleicht auch Extrawünsche, die jetzt nicht in die Norm
11:24
passen, was ja auch n wichtiger Aspekt ist?
11:26
Ne weil jedes Projekt ist ja irgendwie unique ja und
11:30
einzigartig, genauso wie die Häuser ja irgendwie immer denn.
11:34
Ab einem gewissen Punkt sag ich mal so Eigenheiten haben die
11:39
dann nur dieses Haus betreffen. Genauso ist es ja bei der
11:42
Softwareentwicklung auch und deswegen ist das Halt einfach n
11:45
sehr klassisches n gutes Beispiel, weil du halt genau
11:49
dieses Pendant hast. Ne es gibt n Architekten für
11:51
Häuser und es gibt n Architekten die Rolle gibt es ja oft
11:54
softwarearchitekt ja in Projekten oder in Teams.
11:59
Die sich halt genau mit diesem Thema dann beschäftigen, damit
12:01
nicht wir als Entwickler oder sag ich mal diverse Handwerker
12:06
einfach ihr Ding durchziehen und am Ende es irgendwie nicht
12:09
zusammenpasst. Also ja, auf jeden Fall ich.
12:12
Ich würd tatsächlich aber zumindest sagen, dass also ich
12:15
persönlich bin zum Beispiel nicht so n Fan von geteilten
12:19
Rollen in Sachen Softwareentwickler oder
12:23
Entwicklerin und Software Architektin oder Software
12:25
Architekt. Weil ich finde, irgendwie jeder
12:28
sollte sich schon irgendwie Gedanken darüber machen, wie
12:30
Software designt werden sollte, aber das fällt jetzt noch mal
12:33
auf n anderen Acker, aber ich glaube das siehst.
12:36
Du ja, das ist ja quasi wie wie n Team aufgebaut ist.
12:38
Ja, aber ich sag mal so, im traditionellen Sinne ist es ja
12:41
oft so, dass du schon Leute hast, die sich da mehr mit
12:44
beschäftigen, sag ich mal. Ja.
12:46
Also so im traditionellen, in der traditionellen
12:49
Softwareentwicklung hast du ja, oder?
12:53
Sagen wir mal so, es ist vielleicht nicht unbedingt ne
12:55
100% Rolle, aber es sind so Sachen, die Leute anstreben.
12:58
Ja, also ganz oft hört man ja ja, ich möchte mehr so in die
13:02
Architekturrichtung gehen und ich möchte irgendwie Senior
13:05
softwarearchitekt werden, so was jetzt dahinter steht oder
13:09
beziehungsweise was man im Team am Ende wirklich ist, steht ja
13:12
auf einem anderen Blatt, ne, aber im Prinzip hast du, so sag
13:15
ich mal rollen oder oder Bereiche, um die man sich
13:21
kümmert. Ob du jetzt quasi ne Rolle hast
13:23
und dich um mehrere Bereiche kümmerst oder nicht.
13:25
Aber du hast ja diese architektenbereich sag ich mal
13:28
genauso wie denn auch beim Hausbau, um jetzt die Analogie
13:30
einfach noch mal aufzugreifen. Versteh ich, versteh ich.
13:33
Genau das ist nämlich genauso der Grund zu sagen, OK, es
13:37
müssen strukturelle Entscheidungen getroffen werden
13:40
mit langfristiger Auswirkung. Ja, also in dem Moment, wenn ich
13:44
dieses Haus plane, dann soll es ja hoffentlich eine Auswirkung
13:47
für die Ewigkeit sagen. Meine Planung soll ja Bestand
13:50
haben, sozusagen und nicht morgen wieder über Bord geworfen
13:53
werden. So ist es auch bei der
13:54
Softwareentwicklung, dass du sagst, wir treffen grundlegende
13:58
Architektur Entscheidungen und danach wird entwickelt, so wird
14:01
die Software aufgebaut, dann kannst du natürlich einen
14:05
Schritt weiter gehen und ich finde, dass es geht dann auch
14:07
schon wieder mehr noch in das, was du gerade meintest.
14:11
Das Ganze muss man aber so n bisschen auch von Design
14:14
trennen. Ja also du hast so ne
14:16
grundlegende Architektur wo eigentlich so wirklich die
14:20
Basics drin sind, da können gehen wir ja später.
14:22
Sicherlich geh ich jetzt mal von außen noch genauer drauf ein und
14:25
da übergelagert oder beziehungsweise nicht
14:28
übergelagert sondern feingranularer kommst du
14:30
irgendwann zu designentscheidung und da sollte sich auch jeder
14:33
Entwickler zu 100% Gedanken drüber machen.
14:36
Ja. Ja, auf jeden.
14:37
Fall ne, also da kommst du nicht mehr drumherum.
14:39
Wenn du sagst, hey hier, das ist Architektur da ich bin
14:42
Entwickler. Ja ja das hat mit mir nichts zu
14:43
tun, kann man bis zum gewissen Grad vielleicht so Hardline
14:46
durchziehen und sich davon freimachen, aber bei so
14:49
Designentscheidung nicht mehr. Ja, das stimmt.
14:51
Und weil wenn du dann noch. Und bei der Implementierung
14:54
schon gar nicht. Ich wollt Grad sagen, wenn du
14:55
noch n Schritt weitergehst in die Implementierung, dann na ja
14:59
bin ich raus. Genau nein, aber ich find es
15:03
gut, dass du zum Beispiel sagst. Also Architektur sind quasi,
15:06
also hat auch was für, also für langfristige oder Entscheidung
15:10
für langfristige Auswirkungen, wenn man sich überlegt, weil man
15:15
könnte jetzt relativ schnell auf den Gedanken kommen und sagen,
15:17
ja gut, aber man Software ist schnelllebig, da muss man ja
15:20
auch vielleicht mal wieder was ändern können und so und genau
15:22
das ist halt der Punkt, du designst ja zum Beispiel deine
15:25
Architektur, je nachdem wie was sozusagen dein.
15:29
Zugrundeliegendes System machen soll.
15:31
Und wenn du zum Beispiel weißt, Deine Software ist relativ
15:35
schnelllebig, da kommen neue Sachen hinzu, alte Sachen gehen
15:39
vielleicht wieder weg oder verändern sich, wie auch immer,
15:41
da musst du das halt dementsprechend, also nicht
15:43
Design, sondern deine Architektur dahingehend so
15:46
wählen. Ne und das ist ja wie zum
15:50
Beispiel wenn du jetzt, wenn wir noch mal bei diesem Gebäude
15:52
bauen, Analogie sind. Du überlegst dir ja zum Beispiel
15:57
auch OK, ich brauch irgendwie vielleicht NNN Wohnhaus oder n
16:00
Leuchtturm so, da sind 2 komplett grundlegende
16:02
unterschiedliche Architekturen. Ja von einem Gebäude, aber das
16:08
eine ist halt. Für einen bestimmten Zweck
16:10
gedacht und das andere für n anderen Zweck.
16:12
Also du sagst jetzt im im in den seltensten Fällen ja gut, dann
16:16
wohne ich jetzt mal in einem Leuchtturm so, das ist
16:18
normalerweise kein Wohngebäude, ne und das sind halt, das ist
16:21
halt genau das Ding, genauso wie zum Beispiel n Wohngebäude sehr
16:24
unwahrscheinlich auf einmal an der Küste steht und man jetzt
16:27
auf einmal sagen müsste, ja wir brauchen jetzt aber keine Ahnung
16:31
n hohen Punkt wo wir irgendwie leuchten ne also das sind halt.
16:36
Anders kannst aber klassische Anforderungen, wenn du n Haus
16:38
baust. Ja, aber andersrum kannst du ja
16:40
genauso sagen. Ey, ich hab jetzt n Haus, das
16:43
ist hat jetzt zum Beispiel ne gewisse Energiequelle und ich
16:46
möchte diese Energiequelle umbauen, das ist halt
16:48
prinzipiell kein Problem mehr. Du kannst zum Beispiel sagen OK
16:50
ich ich leg irgendwie ne andere Zuleitung, irgendwie ist der
16:53
Grundstock schon geschaffen und ich kann jetzt aber anstatt was
16:57
weiß ich Gas oder Öl kann ich jetzt ne Wärmepumpe zum Beispiel
17:00
irgendwie anschließen ne Mhm das sind halt so Dinge wo man sagt
17:04
OK klar. Der Grundstock muss für den
17:07
entsprechenden Zweck da sein. Aber es ist natürlich natürlich
17:12
sinnvoll, auch dann zu sagen, OK, ich Design ist aber so oder
17:16
wähle meine Architektur so, dass ich eben auch bestimmte
17:20
Veränderungen zulassen kann. Ne, diese Erweiterbarkeit
17:25
beispielsweise. Ja.
17:27
Ja, das sind halt wichtige Eigenschaften.
17:29
Im Prinzip greift da an der Stelle auch vieles zusammen, was
17:33
wir auch im Podcast besprochen haben, wir hatten ja so
17:35
verschiedene Prinzipien der Softwareentwicklung.
17:40
Ja, also Kiss hatten wir gemacht, 3 hatten wir gemacht,
17:44
Jakni solid, ich glaub ja doch die hatten wir auf jeden Fall
17:47
abgedeckt, dann haben wir ja auch, weil wir ja gesagt haben,
17:50
OK, nächste Stufe ist Design, ja, wir besprechen ja auch
17:53
aktuell Design pattern. Die jetzt wieder für den
17:56
Entwickler dann sehr interessant sind, die alles irgendwie
18:00
ineinandergreifen und genau diese Eigenschaften die du
18:03
nennst ja fördern sollen ja zum Beispiel Erweiterbarkeit ja,
18:08
Skalierbarkeit ja kann ich zum Beispiel sagen, ich brauch mehr
18:12
Wohnraum um die Analogie noch mal aufzugreifen, bin ich in der
18:15
Lage es zu erweitern um zu ändern, ja zu warten was wir
18:19
auch meinten, ne dass wenn was kaputt geht.
18:22
Genau, und da gibt es jetzt so verschiedene.
18:24
Gibt es gibt so viele Ansätze, wie man das Ganze machen kann,
18:28
um einfach mal n Paar zu nennen. Wir hatten ja mal ne Folge
18:31
Monolithen versus Microservices zum Beispiel.
18:34
Genau das sind schon 2 Architektur, Architektur
18:37
Entscheidungen die du da hast. Ne setz dich auf n Monolithen
18:41
oder setz dich auf Microservices auf viele kleine Bestandteile.
18:45
Ein Beispiel hat man ja so gegenübergestellt.
18:48
Du hast hexagonale Architektur vorhin genannt, das war n
18:51
Wunsch, den werden wir auch umsetzen, also diejenigen, die
18:54
das jetzt hören und sich gewünscht haben, ja wir werden
18:56
ne Folge zu hexagonaler Architektur machen, weil es auch
18:59
n super cooles Thema ist. Wär jetzt auch so n Beispiel was
19:03
auch viel besprochen wird ja serverless Event driven eine
19:09
klassische Schichtenarchitektur auch ja was du auch viel in der
19:13
technischen Informatik zum Beispiel hast.
19:16
Das sind so so wirklich spannende Sachen und zeigt, es
19:19
gibt sehr, sehr viele Konzepte, die alles vor und Nachteile
19:22
haben, aber sich halt genau mit diesen Grundfragen, die wir
19:25
jetzt so angeteasert haben und schon angesprochen haben, immer
19:28
auseinandersetzen, um diese Eigenschaften quasi zu erfüllen
19:32
oder bestmöglich zu ermöglichen. Ja, das ist ja genau der Punkt
19:36
ne, je nachdem was du für n. Ne Gebäude baust gibt es
19:41
vielleicht dann als also ne, diese Gebäudeanalogie gibt es
19:45
dann in der Softwarearchitektur verschiedene Architekturansätze,
19:48
mit denen man halt arbeiten kann und.
19:50
Genau. Da passt halt das eine.
19:52
Passt mal besser als das andere oder ist halt einfach sinnvoller
19:56
und es ist ja nicht so, als würde man sagen, jetzt
19:59
beispielsweise, diese Architektur ist auf jeden Fall
20:00
besser als ne andere, sondern es ist halt eben genau der Punkt,
20:04
dass man sagt, du musst gucken in welcher.
20:08
In, in, in welcher Region du sozusagen unterwegs bist und was
20:11
für dich passt. Ne, das ist genau finde ich dann
20:13
im Endeffekt die Kunst bei der softwarearchitektur dir zu
20:16
überlegen, was ist denn überhaupt sinnvoll?
20:18
Ne, wenn du jetzt so als kleines Beispiel, du willst irgendwie ne
20:22
Webanwendung oder sowas bauen, ne, da macht es halt einfach
20:26
allein schon Sinn ne ich mein das ist jetzt.
20:28
Ich will jetzt nicht direkt, also wir wollen jetzt nicht
20:30
direkt auf eine bestimmte Architektur oder so eingehen,
20:32
aber es ist ja zumindest irgendwie sinnvoll zu sagen, OK,
20:35
pass auf, wir trennen etwas, ne wir modularisieren überhaupt
20:39
irgendwie bestimmte Punkte und packen nicht alles irgendwie in
20:41
einen Riesen. Wie heißt das Ball of Matt
20:46
sozusagen? Also so dieses Antipatter, weißt
20:48
du, wo einfach alles zusammengepresst wird in einem
20:51
Moorloch sozusagen, sondern du hast irgendwie n frontend, du
20:53
hast n Backend, du hast ne eigene Datenbank, die
20:56
kommunizieren dann irgendwie zum Beispiel über ne Rest API, du
21:00
hast möglicherweise noch Cloud Services, die du anbinden
21:03
kannst. Ne, und das sind alles im
21:07
Endeffekt Dinge, die man sich auf jeden Fall überlegen sollte,
21:12
so. Jetzt nur als kleines Beispiel
21:14
ne, wir wollen ja in anderen Folgen noch mal n bisschen
21:15
genauer darauf eingehen, aber da kannst du dich halt zum Beispiel
21:19
auch Fragen. OK, soll mein Frontend und mein
21:20
Backend irgendwie n riesen Monolith sein oder sollen es
21:22
eher kleine Microservices sein? Ne so und dann kommt es halt n
21:26
bisschen auf den den Anwendungsfall am Ende drauf an,
21:30
ne auch noch mal Stichwort zum Beispiel.
21:34
Domain driven design was für Domänen hast du denn, dass du
21:38
zum Beispiel sagst, OK, du hast einzelne Fachlichkeiten, die du
21:41
zum Beispiel in die entsprechenden Microservices
21:42
packst, oder? Genau.
21:46
Und das was halt einfach klar sein muss an der Stelle ist ja,
21:51
dass wie du meinst, dass das ein Abwägen ist.
21:54
Es gibt nicht die perfekte Lösung.
21:57
Es ist nicht so, dass ich quasi ne Art Fragebogen hab.
22:00
Was möchte ich machen, was möchte ich verwenden.
22:04
So und so und so OK, diese Architektur ist es, du könntest
22:08
jetzt quasi anhand von sag ich mal Wahrscheinlichkeiten gute
22:12
Empfehlung rausgeben, das geht auf jeden Fall ne was sich
22:15
erstens bewährt hat ganz ganz wichtiger Punkt ne wie setzen,
22:19
was haben andere eingesetzt und was hat gut funktioniert das
22:22
sind auch Erfahrungen die man selbst sammelt.
22:25
Denn einen Punkt darf man auch nicht unterschätzen.
22:27
Es muss auch irgendwo zum Team passen.
22:31
Das heißt jetzt nicht, dass sich jetzt Teammitglieder irgendwie
22:34
dagegen sträuben sollten oder so, sondern es ist nicht, also
22:38
nicht für jedes Projekt funktioniert der gleiche Ansatz
22:41
mit den gleichen Leuten so, das war jetzt vielleicht n
22:43
komplizierter Satz, aber so ist es am Ende ja, also du musst
22:47
halt gucken, womit kommen die Leute gut klar und was matcht zu
22:50
unserem Projekt noch zusätzlich, sozusagen ne.
22:53
Weil ganz oft hatten wir ja auch in der Community sowas wie, ja,
22:57
wir haben uns jetzt entschieden, unser neues Projekt so und so
23:01
umzusetzen. Läuft gut, läuft nicht gut so,
23:05
läuft so lala, also gibt es ja alle möglichen Outcomes daraus
23:09
ne und da sieht man das kann halt n sehr ähnliches Projekt
23:12
sein, aber mal läuft es gut, mal nicht ja also das das das muss
23:15
man halt irgendwie ja validieren für sich selbst auch und ich
23:20
finde es ist auch wichtig. Zu erkennen, dass ne Architektur
23:24
nicht in Stein gemeißelt ist. Ja, das ist natürlich n riesen
23:27
Refacting. Das ist n kompletter
23:28
Strukturbruch. Wenn ich jetzt sage, ich änder
23:30
meine grundlegende Architektur, aber wenn das Projekt da quasi
23:35
danach schreit, dass das passieren soll, dann muss man
23:37
den Weg auch gehen und man kann den Weg auch gehen, das ist halt
23:40
nicht in Stein gemeißelt am Anfang und genauso finde ich es
23:45
halt auch wichtig wie du meintest so Skalierbarkeit,
23:49
Wartbarkeit. Das sind alles schöne
23:52
Eigenschaften, aber es ist n trade off.
23:55
Ich kann nicht alles maxen sozusagen ne, dass ich sage ich
23:58
hab jetzt alles optimal und ich bin einfach perfekt unterwegs,
24:02
es ist ja eher so, wenn ich zum Beispiel in die eine Richtung
24:06
gehe, dass die andere n bisschen weniger gut ausfällt zum
24:10
Beispiel. Ja.
24:12
Ja. Also da mögen jetzt vielleicht
24:15
der ein oder andere aufschreien und sagen, ja, nee, nee, nee, so
24:17
ist das nicht. OK, ja gut, das ist wie gesagt
24:19
Einzelfallentscheidung, aber nehmen wir mal irgendwie n
24:22
triviales Beispiel, wenn ich sage, ich möchte unfassbar gut
24:26
skalieren können, ja kann es halt einfach sein, dass zum
24:29
Beispiel meine Main tainability schlechter wird, beispielsweise
24:34
ja. Wird ja auch komplexer dadurch
24:35
ne. Genau also ne.
24:37
Also man muss halt immer gucken, das kann nicht in alle
24:40
Richtungen gleich. Ausgedehnt werden sozusagen,
24:44
sondern es ist halt so ne ne Eigenschaft wird mal n bisschen
24:47
besser sein und n bisschen schlechter und das muss aufs
24:49
Projekt matchen. Aber ich find es gut, dass du
24:52
sagst, weil im Endeffekt ist es ja auch genau die Frage, die man
24:55
sich stellen muss. Welche Punkte sind denn zum
24:56
Beispiel wirklich relevant für die entsprechende Anwendung, die
24:59
du machst? Ne, weil es bringt ja nichts,
25:01
wenn du keine Ahnung versuchst, ne absolute Outperformance zu
25:05
bringen. Wenn Performance aber an der
25:07
Stelle völlig egal ist. Ne, also angenommen du sagst du
25:11
machst irgendwie weiß nicht du hast ne Anwendung was
25:13
irgendwelche Modelle simuliert die was weiß ich immer nachts
25:17
laufen und da eh keiner arbeitet und dann ist es völlig egal ob
25:21
du zum Beispiel ob dein deine Performance sagt ey ich brauch
25:25
ne Stunde für das Modell um das zu simulieren zum Beispiel oder
25:28
3. Wenn aber quasi 8 Stunden eh
25:31
nichts passiert so mal als Beispiel ne dann.
25:34
Ist es, dann ist es egal ne irgendwo an einem gewissen Punkt
25:37
wird es vielleicht wieder wichtig, weil wenn du dann
25:39
irgendwann keine Ahnung 100 Stunden brauchst ist blöd, aber
25:43
nur um sich das kurz vorzustellen, ne, da ist es
25:46
wichtig wirklich zu definieren, was sind denn unsere wichtigen
25:49
Punkte? Ja ich find das ist manchmal ist
25:52
es nicht unbedingt, also es klingt so einfach und so trivial
25:57
und logisch, dass man sagt, Na klar überlegt man sich was
26:00
wichtig ist für mein System und klar mach ich das dann und.
26:04
Komischerweise ist aber genau das nicht immer der Fall, dass
26:07
man sich dann denkt, Moment, aber Mhm, wieso ist das jetzt so
26:10
gemacht worden? Also beispielsweise guck mal,
26:12
wir hatten jetzt unser letztes letzten Programmierwettbewerb,
26:14
ne der war ja Ende letzten Jahres jetzt und da hatten wir
26:19
zum Beispiel auch angefangen, uns tatsächlich gar nicht so
26:22
genau überlegt, weil wir dachten es ist n kleines Projekt, es ist
26:24
so n ne 4 gewinnt kriegt man schon irgendwie hin.
26:28
Und trotzdem haben wir am Ende gemerkt, Na ja, pass auf, alles,
26:30
was wir hier sozusagen zeitlich steuern, macht viel mehr Sinn,
26:33
es zum Beispiel Eventbasiert zu steuern, ne, also bestimmte
26:37
Sachen, die irgendwie stattfinden, und das haben wir
26:42
uns im Vorfeld nicht genau überlegt und man hätte es aber
26:45
machen sollen rückblickend ne, es wär schon besser gewesen für
26:48
uns, wenn wir das einmal so n bisschen konzeptionell überlegt
26:52
hätten und gesagt hätten, OK und dazu muss man sagen, es ist ja
26:55
nur wirklich nur ne Kleinigkeit gewesen.
26:58
Aber, und das ist auch find ich wieder n übelstwichtiger.es, das
27:03
muss man ja auch lernen. Weißt du also, es ist ja nicht
27:05
so, ich find immer, gerade wenn man sich denkt so, ja jetzt fang
27:09
ich hier an Softwarearchitektur, das ist aber nicht perfekt, es
27:13
muss nicht immer alles sofort perfekt sein, ich glaub der
27:16
wichtigste Schritt ist anzufangen damit ne und halt aus
27:20
bestimmten Dingen zu lernen, auf jeden Fall, aber das ist halt
27:22
der der der Knackpunkt den ich eigentlich meine.
27:27
Man sollte sich überlegen, was wichtig ist, weil wie du meinst,
27:29
man kann nicht alles maxen. Ja, ja, aber ich find das, das
27:34
ist n gutes Beispiel mit unserem for connect Turnier, weil immer
27:38
wenn man das Gefühl hat so ah na ja hier brauchst du das nicht so
27:41
machen, hier brauchst du ja nicht so Gedanken machen, das
27:43
ist n kleines Projekt, das ist immer schon so ne Warnung, dass
27:47
man es wieder maßlos unterschätzt und am Ende es
27:50
einem doch auf die Füße fällt. Weißt du, man denkt so kleines
27:53
Projekt ja gut, aber dann hat man sich in der Community
27:56
entschieden, ey lass doch noch n Feature hier einbauen und da wär
27:59
doch cool wenn das im Spiel so und so wäre, dann ne dann
28:02
erweiterst du und erweiterst du und merkst so ey wir bauen hier
28:05
aber auf keinem guten Fundament auf, wir bauen gerade dieses
28:09
Hauskreuze und quer und hoffen, dass am Ende sag ich mal es
28:14
regendichte so die Tür zugeht. Nee, keine Ahnung, aber.
28:17
Das war einfach wieder n Paradebeispiel, dass selbst
28:20
kleine Projekte nach sowas schreien, dass man sich da
28:22
Gedanken drüber macht. Ja und das ist auch wieder n
28:25
Learning für uns wie du meintest zu sagen, egal wie klein das
28:30
Projekt ist. Lass doch am Anfang mal kurz da
28:32
drüber nachdenken, weil 10 Minuten hätten vielleicht
28:34
gereicht. Ja und uns ne Menge Arbeit im
28:37
Nachhinein. Erspart also auch hier, man
28:40
lernt nie aus. Weißt du was ich aber auch immer
28:42
gut finde, also mein das hab ich auf jeden Fall auch schon n paar
28:44
mal erlebt. Du hast ja bestimmte
28:46
Entscheidungen, die du triffst. Du sagst, ey OK, wir haben
28:49
jetzt, das ist wichtig für uns, für unser System, das sollten
28:52
wir machen, das heißt, wir sollten unser System auf jeden
28:54
Fall darauf auslegen, dass es zum Beispiel diese
28:57
entsprechenden Punkte berücksichtigt oder halt
28:59
beherrscht, so OK, kein Problem, machen wir so, und dann macht
29:05
man das so und hat halt eben diese Entscheidung getroffen, ne
29:07
und denkt sich so, super Sache was ich so geil finde ist und
29:12
das ist halt einfach immer dieser Klassiker.
29:14
Das möchte ich jetzt mal so in Raum stellen.
29:17
Man wird diese Entscheidung treffen und diese Entscheidung
29:19
werden, ich sag jetzt auch mal unter Umständen richtig sein,
29:23
angenommen, die sind mal richtig in diesem Moment oder auch
29:26
darüber hinaus, es wird trotzdem irgendwann wieder der Punkt
29:29
kommen oder irgendjemand kommen und sagen, warum macht man das
29:34
denn so, warum habt ihr das denn so gemacht, das ist doch echt
29:37
Quatsch das so zu machen, warum habt ihr es jetzt nicht
29:38
andersrum gemacht? 130%, dass das passiert,
29:43
irgendwer kommt ja cool, das ist halt auch immer die Frage,
29:48
wieviel Einblick hat er auf die aktuellen Ergebnisse, sozusagen
29:51
ne oder die aktuellen Erkenntnisse, die man damals
29:54
nicht hatte, das vergessen auch Leute immer sehr gerne, ne, also
29:58
sowas entwickelt sich über die Zeit und ne Architektur kann
30:01
sich über die Zeit halt auch als richtig oder falsch oder nicht
30:05
optimal sag ich mal herausstellen und muss angepasst
30:09
werden. Ja, ein Bauplan muss auch mal
30:12
überarbeitet werden und so weiter ich find es, es ist n
30:17
witziger Punkt. Wir hatten ja auch die Folge so
30:19
über toxisches Verhalten und das kickt da halt auch rein, wenn
30:22
Leute sich so die Hände reimen denken, Oh ja jetzt kann ich
30:26
das, jetzt kann ich sie bloßstellen so nach dem Motto
30:29
aber ich denke wenn jeder ehrlich zu sich selbst ist, wird
30:32
er an diesem Punkt gekommen sein und sich zurück erinnern können.
30:36
Ja gut, war nicht die richtige Entscheidung.
30:38
In dem Moment war es aber gut und hat den Projekt gefördert,
30:40
also das Projekt gefördert. So ne die Entwicklung und das
30:45
ist halt. Ja, gehört dazu ja, dass man
30:49
Sachen auch mal überdenken muss und hinterfragen muss und dann
30:51
auch im Nachhinein ändern muss. Ja, wichtig ist, sich im Vorfeld
30:55
einfach mal Gedanken zu machen und das hilft halt zum Beispiel
30:58
auch solche Architekturentscheidungen dann
31:00
auch unter Umständen zu dokumentieren.
31:01
Ne, also gerade wenn du jetzt zum Beispiel sagst, OK, wir
31:04
haben das und das. Wir haben uns da und dafür
31:07
entschieden, zum Beispiel. Wir haben gesagt, EY, wir machen
31:10
Microservices, weil wir wirklich viele verschiedene kleine
31:16
Fachlichkeiten haben, die einzeln abgebildet werden
31:18
können, die miteinander, sag ich mal, kommunizieren müssen, aber
31:21
eigentlich sehr autark sind, weil sie nicht wirklich viel
31:24
miteinander zu tun haben, mal so als Beispiel so, dann kann man
31:28
das ja aufschreiben und sagen, genau aus diesen Gründen haben
31:31
wir jetzt zum Beispiel die und die Architektur gewählt, so ne
31:33
sehr kleines Beispiel, aber. Das macht halt Sinn, weil dann
31:37
kannst du dich zumindest immer noch hin, weil es wird genauso
31:40
der Punkt kommen, dass irgendjemand sagt, aber wieso
31:43
wurde das nicht so gemacht und die Leute, die sich dafür
31:46
entschieden haben, je nach Argumentation sag ich jetzt mal
31:50
von der anderen Person könnten sich muss ja nicht mal böse
31:52
gemeint sein, könnten sich aber fragen, ja, hast du recht, warum
31:55
eigentlich ne also wie oft hab ich schon auch erlebt, dass man
31:59
an den Punkt kommt mit. Jetzt nicht
32:02
softwarearchitektonisch ne, sondern wirklich um wenn es
32:05
jetzt um Implementierung geht, dass man an n Punkt kommt, wo
32:08
man vielleicht irgendwann mal dran gearbeitet hat und sich für
32:10
irgendwas entschieden hat und irgendjemand dazu kommt und sagt
32:13
wieso hast du es so gemacht? Ich hätt ne Idee wollen wir es
32:16
nicht vielleicht so machen? Denkst dir so ey das ist
32:18
eigentlich ne ganz geile Idee, es klingt irgendwie klingt
32:20
lässig so das zu machen ne und dann überlegt man das baut es
32:25
vielleicht um kommt an einem Punkt wo man sich dann wieder
32:27
denkt weißt du was? Ich weiß wieder, warum nicht
32:30
gemacht. Ja, ich weiß wieder, warum wir
32:32
es so gemacht haben. Also und das ist bei
32:34
Softwarearchitektur unter Umständen auch so und deswegen
32:36
ist es halt nicht verkehrt dann auch zu sagen, wenn man sich für
32:39
etwas entschieden hat, OK halt es fest Dokumentierst irgendwo,
32:42
schreibst mal nieder und wenn es nur fürs Team ist.
32:44
Wenn es nur für den nächsten ist der ne gute Idee hat oder
32:48
vielleicht auch n bisschen drauf lauert wie du meintest.
32:53
Ja, absolut. Was sind denn so?
32:58
Wenn ich jetzt so drüber nachdenke ne und ich versetz
33:00
mich so in mein altes ich zurück, der jetzt anfängt sich
33:03
damit auseinanderzusetzen. Ne wenn ich so an meine Zeit
33:09
zurückdenke, wo es damit losging, weiß ich noch, dass ich
33:12
so gewisse Architekturen vielleicht gelernt hatte, ne
33:15
oder davon gehört hatte und dann.
33:19
Im Prinzip dachte neues Projekt alles klar, ich bau jetzt so
33:22
diese Struktur auf, ich will jetzt genauso meine Software
33:24
entwickeln, das ist ja total gegensätzlich zu dem, was wir
33:28
jetzt gesagt hatten, so, man muss das entscheiden,
33:30
projektweise und so weiter trotzdem neigt man ja dazu so n
33:35
bisschen over Engineering zu betreiben oder dass man
33:38
vielleicht für n Projekt für n Projekt, wo es überhaupt nicht
33:40
notwendig ist, komplexe Architekturen aufbaut und das
33:44
finde ich ist halt auch einfach so ne so ne übungssache, ja.
33:48
Und Erfahrungssache. Ich glaub Erfahrung und Übung
33:50
spielt da natürlich zusammen, aber muss jetzt mal einzeln
33:53
genannt werden, weil es gibt diesen Moment, wo du dann
33:56
irgendwann besser entscheiden kannst.
33:58
Also ich habe geübt diese Architekturen umzusetzen, ich
34:01
kann das und die Erfahrung kommt irgendwann dazu zu sagen, wann
34:04
macht es Sinn also oder ist das jetzt gerade einfach over the
34:08
top, ist das over Engineering wie wie, wie, wie sind denn da
34:12
deine Erfahrungen so das würde mich mal interessieren, weil ich
34:14
weiß halt wie gesagt damals noch.
34:16
Ja, so, jetzt so wird es gemacht.
34:18
Genauso wie ich das bei den Design Pattern ja schon gesagt
34:21
hatte. Ich hab neues Design pattern in
34:23
in der Uni gelernt und es war einfach erstmal überall und
34:26
genauso war es eigentlich auch so mit so Basic Architekturen.
34:30
Ja, ich weiß, ich. Also ich glaube, bei mir war es
34:33
eher ich überleg gerade. Also ich hab mir glaub ich immer
34:38
eher so gedacht, also irgendwie bei Design Pattern war es bei
34:42
mir auch so bei Software Architekturen dacht ich mir
34:45
immer so. Boah, keine Ahnung, lass einfach
34:49
mal irgendwie überlegen wie es sein könnte, am besten ohne da
34:52
überhaupt nen ne richtige ich sag mal Architektur mit Namen
34:59
hinter zu sehen. Weißt du also ich glaube es gibt
35:01
so verschiedene Herangehensweisen, es gibt so
35:03
Leute die so sich die sich erstmal freimachen von den
35:06
Architekturen und einfach erstmal überlegen was wär
35:08
irgendwie sinnvoll, wie könnte man es aufbauen und versuchen
35:11
dann so zu gucken OK wo sind wir eigentlich gelandet, ist das
35:13
jetzt eher das oder dies oder ähnliches?
35:15
Also sozusagen so n wie nennt man das Bottom vielleicht oder
35:18
so n top Down Ansatz, wo man sich dann so denkt, so Na ja,
35:21
pass auf, wir nehmen, es klingt für mich wie hexagonale
35:24
Architektur, das sollten wir dann nehmen und jetzt gucken wir
35:27
uns mal an wieso das sinnvoll ist.
35:28
Weißt du also in die andere Richtung zu gehen deswegen, also
35:33
bei mir war es ungefähr mal so, dass ich erst mal angefangen hab
35:35
mir was zu überlegen und dann aber nie am Ende gesagt hab, ah
35:38
und das ist die Architektur zum Beispiel soweit hab ich gar
35:42
nicht gedacht. So, deswegen kann ich mich da
35:45
nicht ganz so reinversetzen. Aber bei wenn du jetzt dieses
35:47
Beispiel von Design Pattern nimmst, kann ich auf jeden Fall
35:50
verstehen, dass man dann, wenn du sagst, du hast irgendeine
35:53
Kleinigkeit, ne und versuchst irgendwie ne Architektur drüber
35:57
zu ziehen, das ist schon, also dass dass man da schon schnell
36:00
in over Engineering kommen kann und das finde ich ist immer so,
36:05
wenn wenn man da reinkommt hat man das Problem, ich will ne
36:08
Kleinigkeit anfangen. Und man plant und plant und
36:11
plant und plant. Und irgendwie passiert dann am
36:13
Ende gar nichts so. Ja, das ja, dass man es einfach
36:18
zerdenkt das ganze ne, aber um n Beispiel zu geben, ich hatte
36:21
damals es war so einer meiner ersten hiwi Jobs neben des
36:24
Studiums und Hab an so einem Projekt mitgearbeitet wo so ne
36:28
Art na ja es war von der Architektur halt so diese
36:31
typische Zwiebelschale ne also gibt es ja auch so, dass du
36:35
sagst ich hab so verschiedene Layers ne und die Kommunikation
36:38
geht quasi. Also das Wissen geht immer nur
36:41
nach innen, sozusagen. Ja, das deswegen sagt man ja ne
36:45
Zwiebel, ne, ich kann jetzt immer eine Schale weiter
36:47
abmachen, komm halt immer tiefer, sozusagen bis zum Kern
36:51
und das dachte ich mir so damals OK warte mal.
36:54
Ich hab bis jetzt nur so einzelne Funktionen entwickelt
36:56
als Übung im Studio und ihr fangt jetzt an hier in wirklich.
37:00
Also für mich war das ne Riesen Software damals ja.
37:03
Ne große Software zu bauen und ihr habt so n Konzept dahinter
37:07
und ihr könnt mir das an Bildchen zeigen.
37:09
Voll geil mach ich jetzt immer so ne und ja aber die klasse
37:13
darf niemals wissen über die andere haben und immer nur nach
37:16
innen so weißt du und so das meinte ich halt mit so
37:19
angesteckt und sich gedacht so muss ich jetzt immer Software
37:22
entwickeln, aber dass das natürlich nicht immer die
37:24
richtige Lösung ist ja oder überholt ist, das war mir damals
37:28
egal, das war so ich ich ich hab das jetzt gelernt, ich muss das
37:31
machen so weißt du. Aber das sind, natürlich, muss
37:35
man sagen, sind es ja trotzdem architekturentscheidung gewesen,
37:39
die das Team damals getroffen hat.
37:41
Ne, sich zum Beispiel über den Datenfluss Gedanken zu machen,
37:45
ja, von wonach wo fließen meine Daten, wer hat überhaupt Zugriff
37:49
da drauf, wer hat überhaupt wissen über dem, was quasi auf
37:52
der nächsten Ebene passiert. Das Gleiche ist ja auch zum
37:55
Beispiel bei so Schichten Architektur was wir meinten ne.
37:59
Wenn du jetzt gerade auch mal so in die Netzwerktechnologie gehst
38:01
oder so und du hast so verschiedene Schichten, die dann
38:03
aufgebaut sind, und das sind, das sind ja alles Sachen, die
38:07
hat man damals gelernt, aber so richtig ja, also man konnte es
38:12
nicht so richtig differenzieren, weißt du, sondern du hattest so
38:15
die Übung, hast du denn da angefangen sowas zu machen, aber
38:18
das ist das, was ich meinte mit der Erfahrung, dass du dich
38:20
irgendwann dann fragst, so muss ich das jetzt so machen, oder
38:24
mach ich das nur, weil das jetzt gerade so mein mein
38:26
Werkzeugkoffer ist, der das hergibt?
38:28
Hast du dich dann in der Uni mal hingestellt und gesagt, so
38:31
Leute, bevor ich euch jetzt meine Übungsaufgabe zeige, das
38:34
ist jetzt hier meine Architektur, diese klasse hat
38:37
eine Static Funktion, bitteschön.
38:42
Ja, ich hab. Ich bin ja immer so Fan von
38:44
weißt du, da sind wir beide immer so von Analogie ne und
38:47
Veranschaulichung. Also ich hab mich immer vorne
38:50
hingestellt, hatte so 5 Jacken an und hab dann meine
38:53
Architektur erklärt indem ich immer so ne Jacke mehr
38:55
ausgezogen hab, mies geschwitzt bis dahin ja das wär doch mal n
39:01
joke. Ja, aber ich meine aber an sich
39:05
würde ich ja trotzdem sagen, OK, es ist ja aber völlig in
39:07
Ordnung, wenn du das so gemacht hast.
39:10
Weil du ja dadurch einfach auch Erfahrung gesammelt hast und
39:13
gelernt hast, oder? Also ich meine, im Endeffekt
39:17
hilft es ja mehr, sich darüber Gedanken zu machen und zu
39:20
versuchen, etwas zu tun, um dann am Ende vielleicht zu merken,
39:24
OK, so kann ich es besser machen oder das bringt mir irgendwie
39:27
überhaupt nichts. Also ich find.
39:32
Und ich glaub. Das hab ich jetzt auch schon n
39:33
paar mal gesagt, aber es bringt ja irgendwie nichts mit der
39:36
Herangehensweise. Zu starten, dass man sich sagt,
39:41
OK, ich muss jetzt mal das und das machen und es muss jetzt
39:45
perfekt werden, also bei allen möglichen, also bei allen
39:47
Themen, die wir hier irgendwie auch im Podcast schon besprochen
39:49
haben, ob es jetzt über wirklich ein bestimmtes Software Design
39:54
Pattern geht, über Softwarearchitektur oder ne
39:57
agile Arbeitsweise, oftmals wird ja darüber gemeckert und gesagt,
40:01
das funktioniert aber so und so nicht, weil man, weiß ich nicht,
40:04
also oftmals, wenn man. Paar Leuten darüber redet,
40:08
kommen solche Argumente dann auch von Leuten, die gesagt
40:10
haben, ich hab es einmal ausprobiert, hat nicht geklappt
40:12
ne so und da denk ich mir so OK, aber gerade auch wenn du jetzt
40:16
bestimmte Architekturen nutzt oder jemand sagt Na ja, aber so
40:19
würd ich es nicht machen, ja warum denn hab ich mal
40:21
ausprobiert, geht nicht so weißt du da hilft es einfach viel mehr
40:26
sich auch frühzeitig, vielleicht auch wenn es ne gewisse Art von
40:29
over Engineering erstmal ist. Das trotzdem auszuprobieren und
40:33
dann seine Erfahrungen damit zu sammeln, um dann zu sehen, OK,
40:35
das geht, geht nicht oder geht dafür gut und dafür nicht gut.
40:38
Weißt du, das ist n super wichtiger Punkt und deswegen
40:41
hatte ich auch das Beispiel jetzt so mal n bisschen gebracht
40:43
zum ermutigen, gerade für Leute, die da jetzt quasi erst
40:46
anfangen, erst anfangen damit sich zu beschäftigen mit dem
40:49
Thema ne man muss es ausprobieren, man muss selbst
40:53
spüren was vor und Nachteile sind.
40:56
Sich als Theoretiker hinzustellen und aus dem Buch
40:58
die vor und Nachteile zu lesen und dann zu sagen, ja, nee, so
41:01
ist nicht, und so weiß ich nicht, ob das der richtige Weg
41:04
ist, ne, weil wie gesagt, das ist immer sehr individuell am
41:08
Ende und man muss halt einfach die Erfahrung sammeln und sich
41:11
dann auch ehrlich hinstellen am Ende und sagen, das war gut, das
41:15
war ziemlich herausfordernd für uns im Projekt und wie könnte
41:19
man nächstes mal vielleicht ne bessere Entscheidung treffen da.
41:22
Ist ja, das ist ja n wichtiger Punkt, dann am Ende auch daraus
41:26
zu lernen. Definitiv.
41:28
Ich meine, wenn du gerade ganz am Anfang bist in der
41:31
Softwareentwicklung, also wirklich relativ, das hatte ich
41:34
ja am Anfang jetzt auch von der Folge so n bisschen
41:37
angesprochen. Man muss nicht immer direkt in
41:40
Architekturen denken, ne, also gerade wie gesagt, wenn du
41:44
startest ne und liebe zora lieber zora, wenn du jetzt sagst
41:47
ey ja ich bin relativ am Anfang, wann, wann, wann wird denn sowas
41:51
wichtig? Ich würde so als groben Daumen,
41:57
als grobe Daumenregel sagen, wenn du anfängst, mit Frameworks
42:00
zu arbeiten, dann könnte es langsam interessant werden, über
42:03
Softwarearchitektur nachzudenken.
42:06
Ja, ja oder ja, genau das passiert ja meistens im Zuge von
42:11
den ersten größeren Projekten, ne, deswegen verwenden wir ja
42:14
auch Frameworks, ja. Wenn ich sage, ich hab jetzt zum
42:18
Beispiel etwas, das würde ich sehr gerne längerfristig nutzen,
42:21
oder das ist umfangreicher als bisher.
42:24
Meine kleinen Funktionen, die ich geschrieben hab, und das ist
42:27
nicht abwertend gemeint, ne zum Beispiel wenn ich so ja jetzt
42:30
war ja zum Beispiel auch wieder Advent of Code, ne, das sind ja
42:33
so kleine Funktionen, da fang ich ja nicht an und sag mir so
42:36
jetzt mal erstmal ne Architektur für dieses Problem was ich hab
42:38
für Tag 1 oder so, das macht natürlich gar keinen Sinn ja
42:41
oder Code wars was wir ja auch auf Twitch öfter mal machen.
42:45
Absolut. Aber wenn ich dann anfange zu
42:47
sagen, ich hab jetzt n für mich ernstes Projekt, egal wie groß
42:50
das ist, aber das ist jetzt so n Projekt was ne Lebensdauer hat
42:54
sozusagen, dann ist das n guter Zeitpunkt sich da mal Gedanken
42:59
drüber zu machen und dann immer n bisschen mehr sozusagen.
43:03
Definitiv. Also ich hatte find ich
43:05
eigentlich auch ganz fand ich immer ganz spannend so in dem
43:08
Projekt, das war so richtig so von Grund auf angefangen ne also
43:11
von 0 ja und? Da haben wir uns auch so im.
43:17
Ich würd jetzt nicht unbedingt sagen, es war ne absolute
43:19
Architekturplanung, aber ich find es gehört da so n bisschen
43:21
mit rein einfach im Team auf bestimmte Sachen geeinigt.
43:25
Wir haben überlegt OK ist denn beispielsweise diese Software,
43:29
wie lange wird sollte sie denn überdauern?
43:32
Ne es bringt zum Beispiel nichts, das hatte ich auch mal
43:35
von so einem ich ich nenn es mal nachbarprojekt mal gehört da
43:39
ging es um n Projekt was echt lange.
43:43
Also wirklich ne lange Laufzeit haben sollte ne und dann wurde
43:49
aber für dieses Projekt einfach so, dass das neu, also so 1 der
43:52
neuesten Frameworks gewählt ne wo man sich so denkt so OK,
43:54
warum nimmst du jetzt zum Beispiel n Framework irgendein
43:58
ich sag jetzt mal irgendein Java Script Framework was wo jedes
44:03
Jahr so hunderte aus dem Boden sprießen und aber dafür 200
44:06
wieder sterben und weg vom Fenster sind ne und da muss man
44:11
sich zum Beispiel das sind. Dinge, über die man sich auch
44:14
schon Gedanken machen sollte in seiner Architektur.
44:16
Was nehm ich denn für Technologien zugrunde liegend,
44:19
für das, was ich bauen möchte, für den Horizont, für die diese
44:23
Anwendung ausgelegt ist? Ne, weil sich zum Beispiel auch
44:26
manche Leute dann überlegen, so, warum wird da jetzt zum Beispiel
44:28
irgend ne Java Version verwendet für das und das Projekt, das ist
44:32
ja übelst altbacken und überhaupt nicht mehr so envogue
44:35
ne, aber es macht halt manchmal Sinn sowas zu tun, einfach nur
44:38
weil du dir denkst, OK, das ist halt, es sind bestimmte.
44:43
Frameworks oder bestimmte Sprachen, die halt einfach
44:47
irgendwie gezeigt haben. Damit kannst du arbeiten und
44:51
damit kannst du in Zukunft auch arbeiten und es wird auf jeden
44:54
Fall noch soweit quasi am Start sein alles und und es wird auch
44:58
noch Leute geben, die das dann irgendwie maintainen können
45:02
vielleicht oder so ne, also das sind so bestimmte Dinge und das
45:04
hatte ich auch in diesem einen Projekt mal fand ich ganz
45:06
interessant, dass man sich einfach überlegt hat, was nehmen
45:08
wir für Frameworks wie wie soll dieses Projekt eigentlich.
45:12
Wofür ist es eigentlich gedacht? Was für ne Sprache nutzen wir,
45:16
woraus sich dann natürlich auch irgendwie wieder so n Framework
45:18
teilweise sag ich mal rauskristallisiert oder oder
45:21
Framework sag ich mal. Also die die Auswahl der
45:25
Frameware eingeschränkt genau solche Dinge und das war
45:29
irgendwie cool, weil du ja auch am Anfang meintest so klar, die
45:32
Rolle Architekt gibt es. Aber trotzdem war es halt so,
45:37
von der meint es ja traditionell.
45:39
Es war n bisschen moderner und da ging es halt einfach darum,
45:42
dass wir so im Team so wir waren alle ein großer Architekt und
45:46
haben uns da so, also halt quasi geeinigt, auch worauf wir im
45:50
Team Lust hatten, weil du ja auch meintest, es muss zum Team
45:53
passen, ne und es war ne coole Erfahrung einfach wirklich mal
45:56
so auf einer grünen Wiese anzufangen, so n Projekt
45:58
aufzusetzen und dann diese ganzen Entscheidungen
46:02
mitzumachen. Es hat echt Spaß gemacht, kann
46:04
ich empfehlen. Ja, und das ist halt auch ne
46:07
coole Herangehensweise. Ja, dass man sagt, OK, wir, die
46:10
Architektur fängt erstmal sag ich mal so Brainstorming auf dem
46:14
Papier an, was brauchen wir für Eigenschaften, daraus resultiert
46:19
irgendwo, denn geeignete Frameworks und daraus die
46:22
Sprache, die dann am Ende entwickelt wird, das wär ja
46:25
grundsätzlich so, der würde ich sagen gute Weg.
46:28
Man kann natürlich auch sagen, nee, wir filtern jetzt die
46:32
Frameworks anhand von Sprachen. Auch wieder Limitiere ist dann
46:36
halt immer n Trade off. Ne bin ich bereit zum Beispiel
46:38
in einer Sprache, die ich nicht oft gecoded hab dieses Projekt
46:41
umzusetzen und da wieder reinzuwachsen.
46:43
Das wird mich natürlich am Anfang Zeit kosten, weil ich
46:45
einfach nicht so geübt bin, dann da drin ne das ist das sind halt
46:50
alles so fragen die man denn wie du meintest es muss zum Team
46:52
passen die man denn entscheiden muss aber ja genau also anhand
46:57
von meinen Anforderungen ergibt sich meistens schon welche
46:59
Frameworks oder Sprachen dann gut geeignet sind dafür und dann
47:02
kann ich das halt als ersten. Stein sozusagen, den ich vom
47:05
Haus jetzt setze nehmen und darauf aufbauen, das sind halt
47:11
ist ne coole Herangehensweise, auch noch mal so, wie kann es
47:13
denn gut gelingen, find ich cool, dass du das mal so als
47:15
Beispiel gebracht hast. Ja, ansonsten würd ich sagen,
47:20
ich hab jetzt auch gar nicht mehr so viel dazu, wir haben es
47:23
auf jeden Fall cool besprochen, find ich hat mir wieder mega
47:25
Spaß gemacht. Ich fand es auch cool, dass du
47:29
Domain driven Design dann noch mal reingebracht hast, weil das
47:32
auch jetzt zum Beispiel da ja wenn ich jetzt auf dem Papier
47:35
anfange, auch sehr hilfreich ist, um mir wirklich zu
47:37
überlegen, was habe ich denn für Domains so, ja, also wo soll
47:41
denn die Reise hingehen und nicht nur den technischen Blick
47:44
da drauf zu haben, sondern das ganze fachlich sich zu
47:48
überlegen, was löse ich denn mit meiner, mit meinem Projekt, mit
47:51
meiner Software, was sind meine Ziele so am am Ende.
47:56
Ja, auf jeden Fall. Das ist halt das.
47:58
Genau der. Punkt.
47:59
Wie. Gesagt, einfach ausprobieren,
48:01
machen und dann kommt man auch irgendwann ans Ziel und wird
48:03
halt besser darin. Ich hatte auch einmal genau das
48:08
wir ich glaube in so ne Art. Monolith.
48:10
Aufgebaut haben und dann am Ende aber irgendwie so
48:14
Microservicemäßig dann umgebaut hatten.
48:17
Ne, ist ja auch möglich, also. Learning kann man immer daraus
48:22
ziehen und das ist das Wichtigste.
48:23
Am Ende anfangen, ausprobieren und dann genau diese Learnings
48:26
mitnehmen und nicht sagen, ah Scheiße, ich krieg es nicht
48:28
direkt perfekt hin, deswegen würde ich sagen Tino, Danke fürs
48:33
Gespräch über Softwarearchitektur bitte bitte
48:36
ich glaube. Reicht der Jahresstart?
48:38
Reicht jetzt auch das neue Jahr? Erstmal zumindest.
48:41
Wir hören uns nächstes Jahr wieder genau ja, also in dem
48:47
Sinne wünsche ich allen. Noch einen, wie sagt man n
48:52
tollen Start ins neue Jahr. Frohes neues Jahr kann man noch
48:55
sagen oder ist noch o. K.
48:57
Geht noch, geht auf jeden Fall immer noch.
48:59
Eine Woche, falls es jetzt n bisschen später dran ist.
49:02
Aber um das Ganze jetzt abzuschließen, Liebe zuhören,
49:04
lieber zuhören. Wenn du sagst, ey, das ist war
49:07
wieder ne coole Folge, macht Spaß, ich freu mich auch schon
49:09
auf einzelne Architekturen die besprochen werden.
49:14
Lass uns da auf jeden Fall gerne zu Ohren kommen, was dich da
49:18
brennt interessieren würde, dann können wir das vielleicht auch n
49:21
bisschen einpriorisieren also schreib uns auf jeden Fall gerne
49:24
auf der Podcast Mail oder auf Social Media oder auf dem
49:27
Discord, komm auf jeden Fall auf den Discord, falls du da noch
49:29
nicht bist. Coole Community ist dort, Grüße
49:33
geht auf jeden Fall raus und wenn du sagst das ist n cooler
49:36
Podcast, den kenn ich schon länger, hab ich aber noch nicht
49:39
bewertet ne dann wird es heute Zeit, mach das einfach mal.
49:44
Und dann jahresvorsatz Coding Buddies Podcast.
49:47
Bewerten, das wird uns auf jeden.
49:50
Fall Mega wird uns auf jeden Fall mega freuen und wenn es
49:53
darüber hinausgehen sollte, gibt es auch einen kleinen
49:56
Unterstützungs spenden Link. In den Shownotes guckt da gerne
49:58
mal rein, ansonsten fröhliches Auskartern oder auch nicht, je
50:03
nachdem und Tino Mach's gut, Liebe zu liebe Zuhörer, bis zur
50:08
nächsten Folge Deine Coding Buddies gemeinsam besser.