Schaffe schaffe Software baue – das Geheimnis guter Software Architektur.

Transkription

Björn Schmitz: Hallo Michael, Prosit Neujahr!

Michael Kabdebo: Prosit Neujahr, Björn! Hallo!

Björn Schmitz: Du erinnerst dich vielleicht noch an den interessanten Podcast über Domain-Driven Design von unseren Kollegen bei der consistec. Da ging es auch um Softwarearchitektur und wir fanden, dass das auch noch mal ein interessantes Thema wäre, um das weiter zu vertiefen.

Michael Kabdebo: Genau, richtig! Domain-Driven Design war schon recht spezifisch und wir hatten uns dann gedacht, das Thema Softwarearchitektur so im Allgemeinen, das müssten wir noch mit dazu bringen und ein bisschen mehr beleuchten was das eigentlich ist. Ich würde sagen, wir stellen uns erstmal vor, vielleicht willst du anfangen, Björn?

Björn Schmitz: Ich heiße Björn Schmitz, bin Softwareentwickler und Teilprojektleiter bei der consistec. Ich bin jetzt seit ungefähr 15 Jahren im Bereich der Softwareentwicklung unterwegs, habe auch in der Vergangenheit mit Softwarearchitektur immer mal wieder zu tun gehabt. Und das ist eigentlich ein ganz interessantes Thema. Vielleicht noch was zu deiner Person, Michael?

Michael Kabdebo: Mein Name ist Michael Kabdebo, ich bin seit etwa sieben Jahren bei der consistec, seit 13 Jahren bin ich Softwareentwickler, schwerpunktmäßig im Java-Umfeld unterwegs. Und als Softwareentwickler ist man immer betroffen von Softwarearchitekturen und da reden wir jetzt mal drüber.

Björn Schmitz: Mir wurde in der Vergangenheit gesagt, dass Softwarearchitektur so ein bisschen unnötig ist und dass das ganze Feld zu teuer ist und dass man das auch eigentlich gar nicht braucht oder auch einfach nicht der Sinn dahinter klar ist, warum man das überhaupt braucht. Was ist denn in deinen Augen Softwarearchitektur, Michael?

Michael Kabdebo: Gleich zu Anfang diese Frage, also Software ohne Softwarearchitektur kann es nicht geben. Alles hat irgendwie eine Architektur, ob das ein Gebäude ist, ob das ein, ja, bleiben wir beim Beispiel Gebäude. Ich kann natürlich ohne Architekt ein Gebäude bauen, das geht, daraus ergibt sich eine bestimmte Architektur. Ob diese Architektur dann aber auch gut ist und ob sie den eigentlichen Urzweck des Gebäudes dann auch erfüllt, das ist dann sehr fragwürdig.

Björn Schmitz: Oder vielleicht, um es auf den Punkt zu bringen, wenn man sich gar keine Softwarearchitektur anschaut, ist das Projekt eigentlich schon zu Tode verdammt.

Michael Kabdebo: Ja, es kann sein, dass ich ziemlich krass am Ziel vorbeifliege.

Björn Schmitz: Denn man muss auch betrachten, dass Softwarearchitektur die Basis ist von einer neuen Softwarelösung. Und wenn die nicht betrieben wird, dann entsteht am Ende eine ganz merkwürdige Lösung, die vielleicht nicht marktgerecht ist.

Michael Kabdebo: Die Softwarearchitektur ist praktisch das Fundament der Software. Und wenn das Fundament schon nicht in Ordnung ist, das kennen wir auch vom Bauen her, dann stürzt mir irgendwann vielleicht sogar das ganze Gebäude zusammen oder trägt nur die Hälfte. Also es arbeitet nicht so, wie ich es bräuchte. Arbeitet irgendwie, aber entweder nicht effizient oder - ich wiederhole mich jetzt nochmal - am Ziel vorbei.

Björn Schmitz: Oder das Gebäude stürzt am Ende einfach ein.

Michael Kabdebo: Eben, genau, richtig! Weil es nicht das trägt, was es hätte tragen sollen. Weil ich mir vorher keine Gedanken gemacht habe.

Björn Schmitz: Vielleicht erstmal für die Zuhörer: Lass uns einfach mal vielleicht ein plastisches Beispiel finden. Wie wäre es vielleicht mit einem Internet-Webshop für Silvesterbedarf?

Michael Kabdebo: Ja, ist ein schönes aktuelles Beispiel jetzt gerade, wir hatten jetzt Silvester. Ein Webshop, der Feuerwerkskörper und Böller verkauft.

Björn Schmitz: Vielleicht auch Luftschlangen.

Michael Kabdebo: Luftschlangen, Sekt, alles was man so braucht fürs neue Jahr zu kommen.

Björn Schmitz: Wenn wir uns dieses Beispiel mit dem Shop anschauen, der hat natürlich dann diverse fachliche Anforderungen, aber auch vielleicht nichtfachliche Anforderungen, wie der Shop am Ende zu funktionieren hat. Und darüber lassen sich dann auch so Qualitätsmerkmale ableiten, was dieser Shop denn alles am Ende vorweisen muss, damit er richtig funktioniert.

Michael Kabdebo: Kann man auch abgrenzen, so fachliche Anforderungen bedeutet letztendlich, dass ich in der Lage bin Feuerwerkskörper zu kaufen, zu bezahlen, mir senden zu lassen. Und dann so die nichtfunktionalen wären dann eher so, dass der Shop relativ performant läuft, dass ich nicht bei jedem Klick erst mal so zehn Sekunden warten muss, sondern dass ich gewisse Antwortzeiten zum Beispiel einhalte, eine gewisse Ergonomie vielleicht auch berücksichtige. Jetzt ohne viel vorwegzunehmen, die Qualitätsmerkmale, Björn, du hast grad damit angefangen.

Björn Schmitz: Als erstes vielleicht mal die Verfügbarkeit, also wie verfügbar ist der Shop zu jeder Zeit? Oder auch die Sicherheit dieses Shops? Das heißt, wie geschützt ist er gegen Hackerangriffe beispielsweise? Grad bei dem Webshop natürlich auch so, wie ist die Bedienbarkeit des Shops, aber auch wie ergonomisch ist das Ganze? Also …

Michael Kabdebo: … dass der Kunde damit zurechtkommt.

Björn Schmitz: Genau!

Michael Kabdebo: Würde mir jetzt noch einfallen, also Performance, Skalierbarkeit wäre mit Sicherheit wichtig. Es bringt ja nichts, wenn der Shop jetzt irgendwie nach jedem Klick 20 Sekunden braucht, um irgendwie darauf zu reagieren. Skalierbarkeit kann ich mir beim Webshop auch vorstellen. Wir haben nur ein gewisses Zeitfenster, wo wir Dinge verkaufen, also wir haben viele Zugriffszahlen, dass ich da mal eben auch ein paar Surfer mehr dazu nehmen kann, die die Bestellung verarbeiten, das hohe Bestellaufkommen verarbeitet.

Björn Schmitz: Was auch noch vielleicht ein Thema wäre, wäre die Testbarkeit, also wie gut ist die Software dann testbar? Oder auch vielleicht die Integrierbarkeit, also wie gut lässt sich die Software in bestehende Systemlandschaften integrieren? Oder auch wenn ich das betrachte, wenn die Software schon fertig ist, wie gut ist die Erweiterbarkeit der Software, also wie gut kann man die dann ändern auch noch am Ende?

Michael Kabdebo: Also auch Wartung letztendlich.

Björn Schmitz: Genau! Wir sind jetzt diverse Qualitätsattribute durchgegangen. Jetzt stellt sich natürlich die Frage: Wenn ich jetzt alle Qualitätsattribute erfüllen möchte, wird das richtig teuer am Ende. Ist es überhaupt möglich, alle diese Qualitätsattribute zu erfüllen?

Michael Kabdebo: Möglich ist es auf jeden Fall, aber wie du schon sagst, das kann sehr aufwendig werden. Softwarearchitektur ist auch jetzt kein Mittel zum Zweck, es soll eigentlich dienen, dass ich eine gute, effiziente, qualitativ hochwertige Software schreibe. Also wie mit allem im Leben, kann ich es auch hier übertreiben. Ich muss schon meine Schwerpunkte setzen als Softwarearchitekt oder vielleicht auch irgendwo als Kunde. Also was davon ist mir jetzt wirklich wichtig? Ich muss nicht alles davon jetzt berücksichtigen, unbedingt. Oder ich sag mal bis zur absoluten Perfektion treiben, mit Sicherheit nicht. Ich soll das aber schon im Auge haben. Weil auch dann habe ich eine gewisse Kontrolle über meine Software im Gesamten. Ich weiß dann auch um meine Schwächen. Was okay ist, Software darf durchaus Schwächen haben. Gut ist, wenn ich halt weiß wo. Das kann ich am besten auch rausfinden, wenn ich meine Softwarearchitektur eben im Blick habe. Also eben diese einzelnen Punkte, die wir jetzt gerade besprochen haben.

Björn Schmitz: Interessanter Punkt, Michael. Ich bin da ein bisschen anderer Meinung. Ich denke, man kann einfach nicht alle Qualitätsattribute erfüllen. Dafür sind es zu viele und zum Teil schließen die sich dann auch entsprechend aus. Wenn ich jetzt zum Beispiel schaue Richtung Wartbarkeit und Performance, es kann sein, wenn ich jetzt einen Webshop habe, der besonders performant laufen muss, kann das bedeuten, dass ich die Software vielleicht nicht mehr so wartbar ist am Ende. Einfach weil ich den Shop so stark ausgerichtet habe Richtung Performance. Ich finde deswegen, muss man es immer abwägen, welche Qualitätsziele einem besonders wichtig sind und sich dann immer entsprechend dieser Punkte auch ausrichten. Am besten ist es da, wenn man eine Top 3 oder vielleicht sogar noch eine Top 5 an Qualitätsattributen hat und alle Entscheidungen, die man trifft, auch nach diesen Qualitätsattributen ausrichtet. Man muss vielleicht auch ein bisschen betrachten, Softwarearchitektur bedeutet auch immer, dass man so einen Kompromiss hat aus Qualitätsattributen, Kosten und Funktionalität. Das ist ein bisschen wie generell beim Projektmanagement, da gibt es ja auch dieses magische Dreieck aus Kosten, Zeit und Umfang beziehungsweise Qualität, und da muss man immer so ein bisschen entscheiden, was einem am Ende wirklich wichtig ist.

Michael Kabdebo: Das ist auf jeden Fall richtig. Man hat diverse Grenzen, in denen man sich bewegt. Geld ist das eine. Natürlich kann ich ein Softwareprojekt jetzt nicht unendlich teuer machen. Also Software muss sich auch irgendwann automatisieren, es bringt ja nichts, wenn ich jetzt einen Webshop baue, der sich die nächsten zehn Jahre Umsatz wegfrisst. Da hat keiner was davon tatsächlich. Das ist eben dieser Spagat, dann diese Merkmale festzusetzen, was ist wichtig. Können wir gern nochmal unser Fallbeispiel nehmen. Also grad bei so einem Webshop, zum Beispiel: Verfügbarkeit wäre durchaus sehr, sehr wichtig. Es bringt ja nichts, wenn die halbe Zeit mein Webshop nicht erreichbar ist. Oder ein Stück weit auch dann die Benutzbarkeit der Software. Es bringt auch nichts, wenn ich einen Webshop zur Verfügung stelle, den einfach keiner bedienen kann. Da bestellt keiner bei mir, sondern man geht zur Konkurrenz, ich bin nicht der einzige Webshop. Das wären mal so zwei Punkt, die mir einfallen würden. Auch, dass ich die gesetzlichen Regelungen einhalte. Ich kann jetzt natürlich anfangen, früher Böller zu verkaufen, weil ich da keinen Datums-Check drin habe, oder ich kann auch Sekt an Minderjährige verkaufen, also an unter 16-Jährige, weil ich keine Prüfung eingebaut habe, weil mir die Prüfung einfach zu teuer war.

Björn Schmitz: Mhm (bejahend). Grad so eine Sicherheitsprüfung. Danach bekomme ich weiß Gott wie viele Anzeigen, Anklagen, die dann weiß Gott wie viel Geld verschlingen für Bußgelder und Anwaltskosten et cetera.

Michael Kabdebo: Gut! Wir haben jetzt schon eine ganze Menge Merkmale gefunden, Qualitätsmerkmale gefunden. Ich würde jetzt mal behaupten, einige davon kann man jetzt drüber sprechen, wie wichtig sie sind oder wie unwichtig sie sind. Was würdest du, Björn, sagen, so die wichtigsten Qualitätsmerkmale einer Softwarearchitektur aus deiner Sicht?

Björn Schmitz: Das kommt immer drauf an. Also jede Lösung ist auch immer ein bisschen anders oder es kommt auch darauf an, wie der Markt da so drauf ist. Man kann also gar nicht so pauschalisieren, welche Qualitätsmerkmale jetzt die wichtigsten wären. Wenn wir jetzt aber vielleicht auf das Beispiel unseres Webshops schauen, wäre vielleicht die Bedienbarkeit und die Ergonomie ganz vorne mit dabei. Also es ist wichtig, dass der Kunde sich dann in dem Webshop gut zurechtfindet und schnell zu seinem Ergebnis kommt. Weil wenn er das nicht schafft, dann springt er eher ab und schaut vielleicht bei der Konkurrenz nach. Und das wollen wir natürlich nicht. Vielleicht wäre auch noch die Verfügbarkeit wichtig, weil der Shop soll natürlich dann vor Silvester immer verfügbar sein, weil da der meiste Umsatz generiert wird. Wie siehst du denn das, Michael, was wären so deine Top 3?

Michael Kabdebo: Auf jeden Fall weit oben sehe ich das Thema Sicherheit. Aus der Vergangenheit kennen wir auch so Daten-Leaks oder dass Leute persönliche Daten abgreifen, ob das Zahldaten sind oder Stammdaten, um damit irgendwelche Schindluder zu treiben. Also auch da sind viele böse Sachen einfach passiert, also würde für mich ganz weit oben stehen. Verfügbarkeit auf jeden Fall. Es macht keinen Sinn einen Webshop zu betreiben, der die meiste Zeit einfach offline ist aus Gründen. Performance spielt für mich auch immer eine ganz wichtige Rolle. Wir alle haben den Anspruch als Anwender, dass Software schnell reagiert, dass auch Aufträge schnell geschehen. Also ich will zum Beispiel, wenn ich im Webshop bestelle, nicht immer 20 Sekunden warten, wenn irgendein Klick passiert. Wenn das passiert, dann schaue ich mich dann bei der Konkurrenz eher um. Ich habe aber auch keine Lust, drei Tage zu warten, bis meine Bestellbestätigung per E-Mail angekommen ist. Alles das sollte man schon berücksichtigen.

Björn Schmitz: Es kommt natürlich immer darauf an, auf was man am Ende dann auch Wert legen möchte. Das kann natürlich von Lösung zu Lösung unterschiedlich sein.

Michael Kabdebo: Auf jeden Fall, genau!

Björn Schmitz: Jetzt haben wir uns am Beispiel des Shops diverse Merkmale benannt und sind uns einig, dass es ganz wichtig ist diese am Anfang zu definieren, und dass die von Software zu Software auch unterschiedlich sein können. Ich denke, wir sind uns einig, dass man sie einfach immer benennen muss, bevor man überhaupt mit einer Lösung beginnt.

Michael Kabdebo: Auf jeden Fall! Weil sonst hat man keine Chance, eine gute Softwarearchitektur hinzubekommen.

Björn Schmitz: Oder auch generell eine Lösung am Ende auf die Beine zu stellen.

Michael Kabdebo: Sich vorher Gedanken machen, bevor man in die Umsetzung geht, ist wichtig.

Björn Schmitz: Michael, du hast jetzt über den Softwarearchitekten geredet, also die Person, die auch sich um das Ganze kümmert, also um die Softwarearchitektur. Was muss denn so ein Softwarearchitekt in deinen Augen können oder was sind dem seine Aufgaben?

Michael Kabdebo: Er muss einen gewissen Weitblick haben, was Technologien angeht, sowohl alte wie auch vor allem neue, um sie eben dann entsprechend einsetzen zu können, um auch über Sinn und Unsinn diskutieren zu können. Machen wir das jetzt mit irgendeiner gehypten Technologie oder macht das einfach keinen Sinn für uns? Oder welches Muster verwende ich, welches Muster muss ich vielleicht sogar entwickeln als Softwarearchitekt, damit es passt? Das sind jetzt mal so ein paar Schlagwörter, die ich jetzt da mal geben kann zum Thema, was muss ein Softwarearchitekt alles können. Aber ich nehme mal an, du hast noch ein paar Ergänzungen, Björn.

Björn Schmitz: Nein, das passt soweit doch schon. Aber ich habe da auch so ein bisschen eine andere Meinung dazu. Ich finde, wenn es einen Softwarearchitekten gibt als solche Rolle, dann sollte der vielleicht auch mehr so das Team unterstützen, also die die Lösung dann auch entwickeln. Also nicht, dass jetzt der Softwarearchitekt für sich alleine irgendwelche Modelle modelliert und die Entwickler am Ende das nur noch abprogrammieren müssen. Das sollte schon eine gemeinsame Aufgabe so ein bisschen sein, wo der Architekt dann gegebenenfalls mit seinem Wissen auch einfach da ergänzen kann.

Michael Kabdebo: Gebe ich dir auf jeden Fall recht. Vor allem muss der Softwarearchitekt auch wissen, was sein Team kann. Wie du hast es schon angesprochen, es bringt jetzt nichts, ein Softwaremodell auf die Beine zu stellen, was das Team, das es umsetzen soll, gar nicht umsetzen kann. Es mag von mir aus sein, ich habe jetzt meinetwegen so ein Java-Entwicklungsteam und es würde sich aber anbieten, das jetzt alles super in Python zu machen. Wenn ich keinen habe, der Python kann, dann muss ich diesen Kompromiss finden, das Ganze irgendwie doch dann versuchen mit Java-Mitteln zu bewerkstelligen. Da gebe ich auf jeden Fall recht. Also der Softwarearchitekt kann jetzt nicht allein in seinem Kämmerlein sitzen und da super Modelle machen und die am Ende des Tages dann jedem präsentieren. Also er muss auch schon das Team berücksichtigen, nicht nur die Kundenwünsche und die nichtfunktionalen Anforderungen.

Björn Schmitz: Auch natürlich auch das Feedback vom Team dann einholen. Generell gibt’s in der Softwarearchitektur auch immer, also man definiert und prüft das am Ende auch immer wieder so als Schleife. Deswegen ist das auch relativ lebendig der ganze Prozess, weil sich das ständig ändert. Es kann sein, dass das Modell, das man vielleicht auch vorher definiert hat, dass sich dann herausstellt, dass das nicht so richtig funktioniert. Dann muss man es einfach nochmal neu machen oder ein bisschen dran feilen, dass es am Ende doch funktioniert.

Michael Kabdebo: Es können sich auch Fehler einschleichen tatsächlich, …

Björn Schmitz: Natürlich!

Michael Kabdebo: … wenn ich das dann als Entwickler bemerke und dann muss ich dann mit meinem Softwarearchitekten oder den Softwarearchitekten sprechen, sie darauf aufmerksam machen: Pass auf! Das funktioniert aus den und den Gründen nicht.

Björn Schmitz: Michael, es gibt ja diverse Stimmen, die sagen, dass man vielleicht in einem Softwareentwicklungsteam auch einfach keinen Softwarearchitekten braucht. Was denkst denn du darüber?

Michael Kabdebo: Ich habe schon gesagt, Software ohne Softwarearchitektur gibt’s nicht, kann es nicht geben. Und so sehe ich es eigentlich auch mit den Softwarearchitekten. Vielleicht muss der Softwarearchitekt nicht unbedingt eine feste Person sein, das kann auch ein Team sein. Man kann sich auch vorstellen, dass der Softwareentwickler oder die Softwareentwickler als Team Softwarearchitektur definieren. Wichtig ist es, dass man sich dessen bewusst ist, dass man Softwarearchitektur einfach auf dem Schirm hat. Also nicht, dass Softwarearchitektur einfach während der Entwicklung unkontrolliert entsteht, sondern dass man vorher drüber spricht und vorher definiert, was die Softwarearchitektur zu sein hat, wie die auszusehen hat.

Björn Schmitz: Was vielleicht auch noch wichtig ist, es kommt vielleicht auch ein bisschen drauf an, wie die Teamgrößen sind oder wie die Organisation aufgebaut ist. Wenn ich jetzt viele verschiedene Projekte gleichzeitig habe, die miteinander agieren, dann kann es natürlich auch Sinn machen, dass man verschiedene Architekten dann auch durchaus beschäftigt, die sich untereinander auch abstimmen und dass damit so ein Gesamtbild auch entsteht für die Lösung. Und dass da auch nicht verschiedene Lösungen dann entstehen, die gar nicht miteinander arbeiten können.

Michael Kabdebo: Ja, gebe ich dir auf jeden Fall recht. Also je komplexer, je größer Software wird und je mehr Software vielleicht auch aufeinandertrifft, auch unterschiedliche Systeme, wenn man sagt, man muss da irgendwas verknüpfen, dann müssen Softwarearchitekten miteinander sprechen. Auf jeden Fall muss man es auf dem Schirm haben. Es kann durchaus Sinn machen, die Rolle des Architekten irgendwann einzuführen. Da finde ich auch, dass das oftmals verpasst wird. Also Software wächst ja ständig, und irgendwann wird Software komplexer, komplexer, komplexer und irgendwann verpasst man so den Punkt, wo man vielleicht dann doch sagen muss, jetzt bräuchte man die Rolle des Architekten von einer einzelnen Person oder eines Teams, die das in die Hand nimmt, um auch eine gewisse Verantwortbarkeit herzustellen, dass jemand verantwortlich ist für Architektur, sich dessen auch bewusst ist und dementsprechend agiert.

Björn Schmitz: Es muss ja nicht eine einzelne Person auch sein, es kann auch das Team sein, aber das Team muss sich einfach bewusst sein, dass es auch diese Verantwortung zu tragen hat.

Michael Kabdebo: Gut, wenn man sich den Softwarearchitekt einfach mal so als einzelne Person sich vorstellt, was muss denn der mitbringen? Kann jetzt jeder Softwareentwickler auch gleichzeitig Architekt sein beziehungsweise …?

Björn Schmitz: Es kommt ein bisschen drauf an. Ein Softwarearchitekt sollte auch entsprechend viel Erfahrung mitbringen und sollte vielleicht auch schon diverse Dinge mal gesehen haben und auch wissen, wie ein Gesamtsystem auch funktioniert am Ende, und wissen, welche Muster und welche Werkzeuge muss man zusammenbringen, damit am Ende auch eine funktionierende Software entstehen kann.

Michael Kabdebo: Der Softwarearchitekt, der muss sehr vorausschauend arbeiten. Also der muss auf dem Stand der Technik sein, wissen, was gibt’s so für neue Technologien am Markt, die man eventuell einsetzen kann, weil wir entwickeln ja neue Software. Muss so ein ziemlicher Allrounder sein.

Björn Schmitz: Vor allen Dingen muss er auch wissen, wie man weiter agiert, wenn vielleicht etwas nicht so funktioniert, wie man es sich ursprünglich vorgestellt hat. Dann auch noch vielleicht so einen Plan B in der Hinterhand haben. Michael, was haben wir denn jetzt heute alles so gelernt über Softwarearchitektur?

Michael Kabdebo: Auf jeden Fall hoffe ich, dass wir gelernt haben, dass Softwarearchitektur ein ganz, ganz wichtiger Aspekt in der Produktion von Software ist. Etwas, was man sich immer vor Augen halten muss zu jeder Zeit während man die Software entwickelt.

Björn Schmitz: Und dass es auch immer existiert.

Michael Kabdebo: Dass sie immer existiert und dass Softwarearchitektur ein erheblicher Kostenfaktor sein kann, vor allem, wenn man eine schlechte Architektur hat.

Björn Schmitz: Und wenn man sich nicht rechtzeitig Gedanken darüber macht.

Michael Kabdebo: Ja. Softwarearchitektur hilft mir vor allem, meine Ziele umzusetzen und zu erreichen. Eigentlich sind wir schon am Ende. Ich hoffe, wir konnten halbwegs zusammenfassen für den Hörer, was Softwarearchitektur bedeutet, was alles so dazugehört. Das Thema ist oftmals einfach unterschätzt. Ich hoffe, das ist auch so rübergekommen. Es hat Spaß gemacht mit dir darüber zu reden, Björn.

Björn Schmitz: Ja, hat mich auch gefreut.

Michael Kabdebo: Und bleibt dem Podcast gewogen und bis zum nächsten Mal. Tschüss!

Björn Schmitz: Bis zum nächsten Mal! Macht’s gut!

So, das war‘s für heute. Wir hoffen, es hat euch gefallen und dass wir einige Fragen zum Thema Architektur in der Softwareentwicklung klären konnten. Weiterführende Links zur aktuellen Folge findet ihr in den Shownotes. Und wenn ihr euch für die wunderbare Welt der Softwareentwicklung interessiert, freuen wir uns natürlich, wenn ihr uns abonniert. Unser nächster Entwickelter-Talk kommt am 3. Februar und steht für euch schon in den Startlöchern. Wir würden uns freuen, euch dazu wieder begrüßen zu dürfen. Bis zum nächsten Mal!