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