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. 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.