#3 – Clean Coding

* Musik * Def Möcke, der Podcast von Def Insider. Ich muss mal so ein bisschen denken, wie im Mittelalter dieser Handwerksköden und auch so, dass quasi als einer als Selbstdechnition aufgefasst haben, so in die Richtung gibt es fast heute coding. Ich finde das radio-russisch, ich müsste halt nicht richtig so. * Musik * Hallo und schön, dass ihr nach einer etwas längeren Pause wieder reinhört beim Def-Metal-Podcast. Ich bin Stefan Augsten, Chefredaptor bei Def Insider. In der heutigen Folge geht es um ein Thema, das eigenständige Entwicklerinnen und Entwickler in kleinen Projekten gerne einmal unter den Tisch fallen lassen, das gerade im unternehmerischen Kontext aber ziemlich wichtig ist, Flinkoding, also sauberes Programmieren. Als Studio-Gast konnte ich heute Professor Dr. Stefan Bente gewinnen, der Software-Technik und Software-Architektur an der technischen Hochschule Köln lehrt. Er berät außerdem Unternehmen in hinsichtlich Konzepterstellung, Methoden, Beratung und Projektbegleitung. Und mit Blick auf den YouTube-Kanal-Arke-Leb ist da auch kein unbeschriebenes Blatt in Sachen Multimedia. Hallo, Stefan. Hallo. Jetzt kurz noch zu den Hintergründen der heutigen Folge. In den vergangenen 25 Jahren hat sich die Software-Entwicklung stark gewandelt. Unternehmen bekommen das aktuell häufiger zu spüren, beispielsweise wenn sie Software-Monoliten aufbrechen wollen oder wenn die Wellerpaar, die mit einem bestimmten Stück Software betraut waren, plötzlich das Unternehmen verlassen. Unaufgeräumter, schlecht dokumentierter und somit komplexer Code ist also keine Seltenheit, wohl den der seine Entwicklungsteams schon vor Jahren in Klincode-In-Geshoot hat. Stefan, in unserem Briefing-Gespräch zum Podcast hast du ja schon durchblicken lassen, das Klincode-In-Kan isoliert es für sich, stehen des Thema ist. Was steckt für dich hinter dem Begriff Klincode und warum hältst du ihn für unerwässlich? Ja, Klincode finde ich, muss man in Zusammenhangs sehen mit Architekloprinzipien, wie zum Beispiel die Solidprinzipien, sowas wie Single-Risponzipability-Prinzipel, Interface-Devasion-Prinzipel oder auch Klostprinzipel sind Dinge, die zusammen mit Klincode dafür sorgen, das sagen wir mal eine saubere Architektur schon auf der Code eben da anfängt. Und das ist eigentlich der Schlüssel dazu, dass man im Team nicht eine technische Schuld aufbaut, die man dann im Grunde genommen, wenn es so lange so geht, nicht mehr abbauen kann. Du sprachst gerade die Solidprinzipien an, die ja beispielsweise darauf abzielen unnötige Abhängigkeiten zu vermeiden oder eine Erweiterbarkeit ohne Modifikationen zu gewährleisten. All das sind ja Themen, die mit der Wahrbarkeit letztlich einhergehen und damit auch für eine gewisse Langebigkeit der Software sorgen. Wenn ich jetzt im Team arbeite und muss das Ganze quasi ausrollen auf das ganze Team, welchen Einfluss haben dann diese Klincodeprinzipien auf die Zusammenarbeit? Der hätte schaffenden gewissen Rahmen, auf denen man sich einig, so ein Qualitätsrahmen. Einerseits ist es ja so, du musst halt schon dafür sorgen, dass du gewisse Kompetenzdifferenzen im Team ausgleichst, dass du so eine Art Charter hast auf die du dich einigst im Team und da sind solche allgemeinen akzeptierten Standards wie Klincode oder dieses Solidprinzipels oder was man vielleicht auch noch dazu nehmen könnte, so gewisse Architekturmodelle wie z.B. Ornienarchitektur oder so eine hexagonale Architektur oder von mir aus auch eine bestimmte Form von Layeredarchitektur. Das sind einfach sehr hilfreiche Werkzeuge, damit im Team nicht alle irgendwie in eine andere Richtung laufen, weil das führt dann dazu, dass dann jedes Team mich nur noch seinen eigenen Code Silohaft warten kann. Und damit kriegst du so eine Code-Ownership, die du eigentlich in der modernen Entwicklung so nicht mehr haben willst. Das Ideal ist, dass alle alles angucken können, verstehen können, den Code lesen können. Und wenn du eine dliche Standards im Team hast, dann wird die Verständigung darüber in welche Richtung man läuft, leichter. Und es ist auch leichter zu sagen, wenn jetzt mal einen Entwickler eine Entwicklerung ausfällt, dann kann halt eine andere oder eine andere einspringen. Okay, welche Möglichkeiten habe ich denn jetzt entweder wenn ich einen Startup bin mit wenigen Entwicklern oder auch als Unternehmen mit vielen Entwicklern, alle dort auf einen Stand zu bringen, also wie lege ich fest welche Prinzipien gelten, wo hinterleg ich das damit jeder sich das auch noch mal anschauen kann, weil ich brauche also eine Art zentrale Know-How-Platform, wo ich das dann definiere. Also es ist direkte sehr vielschichtige Frage, ich würde mal sagen, das hat damit zu tun, dass ein moderner Architekt purbegriff eben beim Code beginnt. Das war nicht immer so, kann man vielleicht auch nochmal vertiefen gleich. Und das wiederum bedeutet, das ist eineseits eine Sache, die man gewisserweise bis zum gewissen Punkt messen kann, durch Mehltricken und auch erzwingen kann, durch gewisse Maßnahmen, durch gewisse Testautomatisierung, und man vielleicht auch gleich nochmal drauf kommen. Das heißt aber auch andereseits, dass ich eine Kultur brauche, eine Diskussionskultur, eine Qualitätskultur im Team, und die fängt halt damit an, dass ich überhaupt über guten Code diskutiere und guten Code zum Thema mache. Das kann ich machen, indem ich Per-Programming mache, das kann ich machen, indem ich Code-Berbius mache, dass ich vielleicht im Team mal schwerpunktmäßig, freitags Nachmittags-Sessionsmache, bei denen ich einfach mal ein Thema vertiefe und diskutiere. Und das sind alles so Dinge, die ich in der Praxis kennengelernt habe, und die ich dann eben auch bei mir in die Lehre mit den Studierenden auch versuchen einzubringen. Vielen Dank. Ich fand ein Schlagwort, das du gerade gesagt hast, das ist heute, glaube ich, auch fast unerlässlich, wenn man über Software-Entwicklung, Agile, in dem Falle jetzt Greencoating spricht, das ist der kulturelle Aspekt, also ich brauche eine gewisse Kultur, die ich verankere und auch im Unternehmen nicht nur in meinen Mitarbeitern, in den Köpfen verankere, um einer Ausgangsbasis zu sein. Wie können den Teams konstant zur Anwendung von Greencoat praktik motiviert werden? Insbesondere, wenn ich jetzt eine Deadline im Auge habe, bis dahin muss ein Stück Software stehen, was selbst im Agilienkontext immer noch der Fall ist, oder auch im DevOpskontext immer noch der Fall ist. Wie kann ich dafür sorgen, dass diese Prinzipien weiter eingehalten werden? Da sind wir dann direkt dabei, wie Agile bin ich eigentlich als Organisation, als Firma, als Team, wobei das Team alleine eigentlich nicht Agil sein kann, das kann nur so Agil sein, wie auch das Droma rum Agile ist. Also sprich, wenn du einen Umfeld hast, was die Autonomie des Teams nicht respektiert, wenn das Team ein Kommit mit abgeblendet sagt, ich kann ein gewisses Feature mit einem gewissen Qualitätsstandard umsetzen, bis dahin und in dem Umfang. Und wenn das dann akzeptiert wird von der Führung von der Leitung und man sich dann zusammen auf so eine Robnet verständigt, dann habe ich eine Chance insgesamt, als Organisation Agil zu arbeiten, wenn das Licht der Fall ist, wenn dann so reingegreht, sagt das muss aber schneller gehen, das muss aber früher fertig sein, das muss aber umfassen, da fährt ich sein, dann bist du eigentlich insgesamt nicht Agil und dann bist du bei diesem klassischen Banan Software-Paradigma, wo dann was ausgeliefert wird, was am Ende beim Kunden zu Ende reifen, hoffentlich. Hoffentlich. Oder besser gesagt, hoffentlich sind wir von dem Thema ein bisschen weg. Na ja, also um das zu löschen, da anzuschließen, also im Prinzip versuchst du ja, wenn du Agil gute Software umsetzt, mit so einer Definition auf dann zu arbeiten, wo du als Team festlegst, was ist denn deine Vorstellung davon, dass Software fertig ist. Und wenn du es schaffst, also wenn du eine Leitung hast, die Qualitätsbewusstsein und Gefühl für technische Schuld auch lebt, dann kannst du in so einer Definition auf dann zum Beispiel auch einschreiben. Wir wollen nicht nur die Software irgendwie fertig kriegen, sondern wir wollen sie auch getestet haben. Wir wollen sie auch so geschrieben haben, dass sie nachhaltig ist, dass wir sie auch in zwei Monaten, in zwei Jahren noch mal anfassen und warten und weiter entwickeln können. Und dann hast du sozusagen die Klammer zwischen diesem Agil-Prozessmodell und der Software-Qualität geschlagen. Klingcoating ist nicht für sich isoliert betrachtet und Agile hängt damit ganz eng zusammen. Das war ja schon in der Uhr Definition von Robert Sesse Martin so als 2008, 2007, 2008, glaube ich, sein Buch Klingcoat geschrieben hat. Aber trotzdem sollten wir vielleicht noch mal keinem wie genau interagieren, denn Klingcoat Prinzipien mit Agilität, mit Agilienentwicklungsmethoden und Prozessen. Also es ist ein bisschen so das Hände-Eiding, hab ich immer das Gefühl, war es weiter zu erster. Und wie bedingt das eine das andere? Ob das eine das andere bedingt, weiß ich nicht. Also ich glaube, du kannst Agil sein und schlechte Software schreiben und so kannst gute Software auch nicht Agil schreiben. Also ich würde sagen, bedingt und sie sich nicht unbedingt gegenseitig, aber sie helfen sich halt gegenseitig. Weil ich hab die Erfahrung gemacht, dass ich was nicht voran ist, liegt, ob jetzt Bob Martin so eine Figur ist, die jeder gut findet und mag und akzeptiert. Also wenn du mit Klingcoat um die Ecke kommst, stellt halt niemand in Frage. Jeder erlebe ich das bei den Firmen, mit denen ich rede, noch erlebe ich das bei den Studierenden. Wenn ich denen, also wenn da der alte Bente sagt, "je macht das mal so und so", dann hat das in anderen Stellen wird, als wenn ein Anke Bob das sagt, das muss man schon sagen, das ist schon hilfreich. Und das alleine ist ein Riesenvorteil und das Buch ist halt, das Buch ist eigentlich, wenn ich jetzt sage, das ist gar nicht so toll geschrieben, dann mache ich mir feinde, es ist, es ist eigentlich so eine Sammlung von Kochrezepten, das meint nicht damit, es ist schon toll geschrieben und dann kannst du auch toll lesen. Es ist halt, es ist halt umwerfen Praxis nahe, du fängst anzulesen und du sagst auf der dritten Seite schon ja, ja genau, klar. So muss man es eigentlich machen. Es ist jetzt nicht so ein Konzept-Spannungsbogen, der sich spannend über 200 Seiten, sondern es ist wirklich ein, ein anderer Reihung von sehr, sehr Praxis nahe geschriebenen Berichten teilkapetteln. Und jeder sieht den Sinn eigentlich umritte bei ein. Das ist der Vorteil. Tatsächlich hatte ich mit Blick auf deinen YouTube-Fanag gesehen, dass du das auch zu den vier Büchern zählt, die man in Frankstehen haben, so umritte man es. Ja, finde ich, ich hoffe, es ist ja. Jetzt sind da schon ein bisschen bei der, bei der Lehre des Ganzen, bei dem, wie man das vermittelt. Du sagtest ja, wo vermittelt das auch dein Stierenden und hier wäre eben die Frage, wie machen das Unternehmen? Du fängst ja bei vielen Studierenden von der Pika auf an. Unternehmen haben vielleicht Entwicklerinnen und Entwickler, die schon länger dabei sind, sich darüber noch gar nicht so wirklich Gedanken gemacht haben, weil sie so in ihrem Arbeitsalltag gefangen sind. Welche Strategie empfiehltst du, wenn es um die Aus- und Weiterbildung von Developern geht, in Bezug auf Klincoating? Ich glaube, der Schlüssel dazu ist, so eine Art Klincoating-Kalchere herzustellen, wenn du den nicht hast. Also du brauchst eine Kultur im Unternehmen, wo es Spaß macht, über Code zu sprechen, Code zu schreiben. Schön, in Code zu zeigen, so eine St-Titik von Code zu entwickeln. Wenn du mal in der Software-Entwicklung, ich würde mal sagen, so 20 Jahre zurückgehe, 15 Jahre vielleicht, dann war das ganz anders. Also meine, ich bin jetzt 58, meine Sozialisierung als Software-Architekt hat wesentlich in so einer Zeit stattgefunden, wo man auf das Code eigentlich runtergeguckt hat und gesagt, das wird auch gesourst. Das machen eigentlich die Leute in Indien und das brauchen wir ja nicht mehr zu machen und auch vielleicht nicht mehr zu können. Das war, glaube ich, eine arrogante Felsicht und die hat sich aber auch nach meiner Beobachtung absolut korrigiert in der Industrie. Vielleicht ist das mit dieser ganzen Digitalisierungstiskussion, um das wir als Gesellschaft Gefahr laufen abgehängt zu werden. Vielleicht ist es damit einhergegangen. Mittlerweile sehe ich einen deutlichen In-Sourcing-Trend bei Code. Also es ist eher so ein Mischmodell, was viele Firmen fahren, dass ich schon in Out-Sourcing machen, Nierschoring oder Off-Schoring, aber eben auch Coating-Expertise im eigenen Haus haben und auch eben gerade das nicht mehr als so eine untergeordnete Tätigkeit wahrnehmen, sondern etwas, was man mit großem Stolz und Hingearbe betreibt. Ich muss mal ein bisschen denken, so wie im Mittelalter diese Handwerksgelden, die dann auch so quasi als eine Art Selbstdefinition aufgefasst haben. So in die Richtung geht mir das fast beim Code. Und ich finde das gerade johus, ich finde das total gut und richtig so. Ja, tatsächlich hat man in dem vergangenen Jahr gemerkt, dass Unternehmen verstehen, dass ohne Software man nicht mehr weiterkommt. Aber das ist natürlich auch getrieben durch IoT Apps, die wir überall im Alltag nutzen. Und es ist so mittlerweile fast schon in der DNA-File unternehmen, dass man ohne Software gar nicht mehr weit kommt. Allerdings stelle ich mir das mit der STT-Diskodes und Centerfold zu präsentieren, schon ein bisschen schwierig vor, weil es vielleicht dann auch nicht jeder versteht. Und das Problem hast du ja heute auch noch. Dass manche Fachkräfte immer noch nicht verstehen, wie wichtig die Software für ihn in Arbeitsalltag ist. Ja, das mit dieser STT-Diskodes und des Duberedens, das betrifft eigentlich eher die Entwickler-Community selber, dass man also in dem Team, die es tatsächlich tun, dann so eine Lust an der Diskussion, an der Außenanersetzung, damit schafft. Und dann gibt es natürlich die Führungsebene und die Latungsebene, die auf die Zahlen guckt. Und das ist ja auch eine absolut berechtigte Perspektive. Und da kann man dann meiner Erfahrung nach sehr gut mit diesem schon gefahrenen Griff der technischen Schuld arbeiten. Also, wenn man dann sagt, ich schaube nicht auf Qualität des Coats, ich lasse zu, dass zu viel technische Schuld aufgebaut wird, dann werde ich als Team irgendwann langsam, weil ich einfach bei jedem neuen Feature immer wieder durch so ein Dicke ich erst mal mit der Marrete durchgehen muss und aufräumen. Und das sieht eigentlich auch jemand, der jetzt nicht im Code-ing ausgebildet ist, ist für den Versmahlene Erfahrung. Also, technische Schuld kann man als Konzept auch Führungskräften ziemlich gut vermitteln. Und dann bist du eigentlich da dann direkt bei dem anderen Aspekt, wie man mit, du hast ja gefragt, wie machen Unternehmen das, wie würden die das verankern? Also, ich würde sagen, Kultur ist das eine, Diskussionskultur und das andere wäre dann der Aspekt. Ich würde auch, und da habe ich jetzt die Architekten brille auf, ich würde auch dafür sorgen, dass das in die Qualitätsgateways die Delivery Pipeline eingebaut wird. Und das machen auch viele Architekten. Es gibt sehr, mittlerweile sehr schöne Möglichkeiten, wie man automatisiert, auch solche Qualitätsaspekte testen kann, zumindest einige davon. In B-Fern propagierst du denn selber vor diesem Hintergrund ein Schiff-Ding-Left-Ansatz? Also, es ist ja so in den DevOps-Pipelines, wenn jetzt Security oder Testing im weitesten Sinne verankert wird, dann wird mittlerweile gesagt, geht möglichst weit im Software-Lebens-Zügel oder im Software-Lebens-Zügel. In Zügel aus nach links hat sich diese Denke bei dir und vielleicht auch bei deinen Studierenden auch schon ein bisschen festgesetzt. Ich propagier das total und ich zwing ehrlich gesagt, meine Studierenden auch dazu, dass sie genau das tun müssen. Ich bin mit den, ich bin im Bachelor bei den im 3. und 4. Semester dran, mit Softwaretechnik 1 und 2. Softwaretechnik 1 machen wir mehr so Anforderungsermittlungen ein bisschen modellieren und dann so Elementares-Coding, so Persistenzmodelle, weil umsetzen mit Java und JPA und Softwaretechnik 2, ich sehe sehr stark auf Clean-Code, Solid Principles, Architekpur, Modelle, Rest APIs, also saubere Schnittstellen, das ist wesentliches Thema. Und gerade in ST2 im 4. Semester kriegen die eine Aufgabe, die in 5 Meilensteinen langsam wächst und am Ende 2-3.000 Zeilen Code pro Studierenden umfasst. Also durchaus für etwas, was ich als Pactiker mache, schon ziemlich groß. Das haben die so groß auch nicht annähernd vorher gemacht. Und ich zwinge sie dazu, dass sie gegen Unit-Tests implementieren. Die dann eben grün werden müssen. Diese Tests sind zum Teil zum größeren Teil fachlicher Natur, also für gewisse Features sehen, die sind aber auch, oder fast ganz aufs größere Teil. Ist zum anderen Teil, sind sie tatsächlich Architekpur-Tests. Also ich teste, was ich testen kann, teste ich mit Ark Unit und anderen selbstgeschriebenen Tests ab, ob sie zum Beispiel gewisse Kommissionen einhalten. Und wenn sie das nicht tun, dann besteht sie den Meilenstein nicht. Und dann ist das genauso schlimm, oder vielleicht noch schlimmer als wenn ein Team eine Delivery macht und die geht nicht durch. Weil der Test anschlägt. Also dieses Gefühl dafür, dass Software halt gut sein muss, das bringe ich sehr stark in diese Lehrveranstaltung rein. Ich hatte mir tatsächlich auch was Notiertrichtungen, wie kann ich das Ganze noch technisch sicherstellen? Und hatte dort mir die Frage notiert, gibt es bestimmte Tools, die dann ja Erfahrung, auch besonders effektiv sind, um Klingcoding zu fördern. Was jetzt Arch Unit erwähnt, gibt es darüber hinaus noch andere Beziehungsweise, welche kannst du dort empfehlen? Checkstyle ist auch noch ganz gut. Dann, jetzt kann ich gerade auf den Namen nicht, ich meine das ist PMR oder so, das wird dann aber im Bild eingesetzt. Das können wir in den Show notes noch mal reintun. Ich habe jetzt da, da habe ich gerade nicht sattelfest. Diese Checkstyle, also PMR, wenn das der Name ist, ist so ähnlich wie Checkstyle. Und damit kann man eher so die Low Levelsachen dann gucken, also das, was ich einzahl, also kurze Methoden zum Beispiel. Oder dass die variablen Namen nicht zu kurz sind und solche eher so einfachen basalen Sachen. Und mit Arch Unit kannst du halt hervorragend so etwas weitergehende Konventionen abtesten. Also ganz grandios ist, um das am weitesten gehende Malzendenen ist Zückefreiheit. Also Zücke sind aus meiner Erfahrung oder aus meiner Sicht quasi der entscheidende Indikator dafür, dass in deiner Software was schiefläuft. Weil du dann quasi so im Grunde genommen einen Spakettikot kreiert hast, so ein Big Ball of Matt, der sich gegenseitig referenziert. Und wenn du auf Vorträge von sowasche Karol-Alegliediental guckst, die ja ganz viel über die Konferenzen geht und über Software Qualität und Architekot, weil ich jetzt spricht, dann ist das auch immer so das erste, was sie analysiert bei ihren Projekten. Und das kannst du halt das versuche ich eben auch mit den Studierenden zu machen und gebe ihn dann Werkzeuge und Methoden an die Hand, wie sie den Zückel auflösen können. Und dann spüren sie den Schmerz, dann müssen sie nicht relativ, weil sie haben halt schon zwei Eterationen gemacht. Haben jede Menge Zeug, jede Menge technische Schuld aufgehäuft und ich zwinge sie dann zu sagen, ihr müsst jetzt aufräumen. Und da muss ich auch einiges an Bad Wipes aushalten und die mit den, die in die Studie müssen dann eben auch vielleicht mal eine Nachtschicht einschieben. Aber das, ich erlebe das als sehr heilsam und kriege das auch als Feedback gespiegelt, das das als sehr heilsam erliebt wird. Ja, das Thema technische Schulden-Technik-Sderb-Taste, jetzt mehrfach schon erwähnt ist ein wichtiges Schlagwort im Zusammenhang mit der Code Qualität. Und ich glaube, du hast es auch schon erwähnt, dass das Refactoring eben dieses Code etwas ist, was für dich auch zentral damit zusammenhängt. Also das, wo du sagst, man sollte aktiv seinen Code prüfen überarbeiten, um dafür einen Geschütt zu entwickeln. Ja, genau. Das kann ich in der Lehre leider nicht ganz so machen, wie ich es unternehmen, machen würde. Und unternehmen ist es ja so, dass du wirklich gezogen bist oder dich selber zwingen solltest erst mal eine vernünftige Testabdeckung zu liefern. Und dann kannst du erst, wenn du quasi einen Feature wirklich abgedeckt hast mit Tests, kannst du sagen, jetzt schreib ich es um und mache es besser. Das kann ich jetzt in der Lehre so nicht umsetzen, weil ich habe nicht die Kapazität, die eine Code von Hand zu kontrollieren. Das heißt, ich bin darauf angewiesen, dass ich automatisiert testen kann. Ich würde gerne mal als leer Aspekt auch mit reinbringen, dass die Studierenden selber Test schreiben. Das ist eigentlich ein ganz elementarer Teil des Software-Entwicklung. Das kriege ich aber, ich habe im Moment noch keinen Weg, wie ich testen, automatisiert testen kann, ob sie automatisiert testen. Wenn ich das Problem gelöst habe, dann kriege ich dann, können wir auch das in der Lehre machen. Aber im Unternehmen würde ich das sagen, da habe ich ja andere Mittel, da kann ich ja sagen, so, ihr habt eine Testabdeckung von, was weiß ich, hier nur 50% tut, da bitte mal was dran. Das ist auch ein Teil, oder definieren auf dann. Und wenn ihr dann Refektorien macht, dann, ja, so macht man es halt, du baust die Test, du schreibst die Test und dann machst es besser. Jetzt in meinem unternehmerischen Kontext trotz allem fehlt dort manchmal auch die Zeit. Man macht vielleicht Sachen schneller, als sie eigentlich sollten. In dem entsprechend gilt es auch, Deutsch Strategien zu entwerfen. Welche Strategie-Techniken empfiehlt es, du denn, wenn es jetzt um die Refaktorierung von Legacy Code geht? Wie gehe ich am besten damit um? Ja, das ist wirklich eine der schwersten Fragen, glaube ich, überhaupt, wie man mit Legacy Code umgeht. Ich mache mal so ein bisschen Zettelkasten. Also es gibt natürlich diese Good Boys-Gout-Rule, ne? Also desto in den Haltung angewünscht, egal, wo du im Code vorbei kommst, du lässt es mindestens so gut zurück, wie du es vorgefunden hast. Und wenn du auch nur eine Ziele verbessern kannst, so irgendwas offensichtlich nicht okay ist, dann macht das. Und dann machst du nicht das ganze Problem blöst, aber ein bisschen was. Also sozusagen ein Stück Papier vom Boden aufgehoben. Das hilft dir aber natürlich nicht, wenn du ein großes Stück Legacy Code hast. Legacy Migration ist schwierig. Da müsste man eigentlich mit dem etwas größeren Besteck dran gehen und sage mich, versuche mal zu schauen, habe ich eigentlich die Domäne durchdrucken. Da könnte ich mit Domäne-Duffen Design an dran gehen, das hat schöne, geht jetzt bei unserer Thema ein bisschen raus. Das hat schöne Ansätze, um die Domäne zu verstehen und versuche dann so ein bisschen opportunistisch dran zu gehen, die Teile zur Refaktorien, die ganz gut funktionieren oder die leicht zu isolieren sind. Ansonsten, wenn du halt das zu lange schleifen lässt, dann ist das Kind im Grunde genommen schon ein bisschen im Boden gefallen. Da gibt es auch einen ganz anderen Ansatz, sind auch ganz interessant finde, vielleicht auch als Gegenbild noch mal, wenn du sehr stark mit Microsoft Services arbeitest und konsequent kleines Services baust, dann weiß ich das eine gefürme, auch so einen Ansatz fahren zu sagen, ich lebe damit, dass technische Schuld passiert, was nicht heißt, dass ich jetzt rumschlampen soll, aber ich weiß, es ist unvermeidlich. Und ich baue die Services so klein, dass ich sie dann nach vier Jahren, fünf Jahren spätestens wegwerfe und neun Schreibe. Also das ist dann dann faszisch, software hat das auf als ein Gut, was nicht mehr immer während funktioniert, sondern was ein Halbbarkeitsdatum hat. Was ich auch ein interessantes Konzept finde durchaus? Ja, damit kann man durchaus arbeiten. Tatsächlich ist es so, wenn ich jetzt in einem gewissen Legacy Code, sage ich jetzt wieder verhaftet bin, dann tue ich mich natürlich schwer, dann vielleicht die alten Sachen umzuschmeißen, vielleicht noch mal von der Pika auf neu zu beginnen. Wobei auch dort einige Unternehmen, glaube ich, nicht rumkommen angesichts der aktuellen Entwicklung, die man so sieht. Ja, total. Also das ist halt das Paradek meines Software Entwicklung früher, war halt innerend monolitisch und daran kranken halt ohnehin viele Softwarelandschaften. Also ich bin relativ viel mit Unternehmen im Versicherungsbereich, im Dialog und da hast du halt die Grundsituation, sehr komplexe Prozesse, die sich über die ganze Landschaft hinbewegten, eine Geschäft, was eigentlich seit mehreren 100 Jahren existiert. Bei den Unternehmen, die jetzt hier in Deutschland heute am Markt sind, hast du Software, den ersten großen Digitalisierungsschub in den 60er, 70er Jahren des letzten Jahrhunderts, hatte teilweise sind noch Legacy Softwareen da. Man, also viele sind nicht mehr ganz so alt, aber einige showen durchaus, aber viele nicht mehr. Trotzdem hast du halt innerend dieses Problem, dass irgendwie immer alles mit allem zusammenhängt. Und der Schlüssel dazu ist tatsächlich es irgendwie kleiner zu schneiden und irgendwie zu entkoppeln und mal kannst du eine Migration machen und malen musst du schlichtwegwerfen und Neuschreiben. Mhm. Also es sagt sich so leicht, dann hast du irgendwie eine Kern Software, also das Schadenmanagementsystem, bei einer Versicherung schmeißt du nicht mehr eben so weg. Das ist einfach, was dich als IT ein paar Jahre wirklich komplett beschäftigt. Auf jeden Fall. Wie beeinflusst denn Klingcoat, die Softwarearchitektur und die jeweils angewendeten Designmuster? Ja, sehr schön, schöne Frage. Ich finde da hat sich die Architektur auch wirklich gewandelt und zum guten gewandelt, wie eben schon angerissen. Also ich komme noch aus einer Schule, wo der Architekt, so derjenige war, der dann die UML-Modelle gemacht hat, die dann in einem Dokument von 100 Seiten Länge niedergelegt wurden und das kriegte dann so einen einen goldrand sozusagen, also nicht physisch, sondern so mental und wurde dann dahin gelegt mit großer Geste und wurde dann aber nie gelesen. Und das hat oft einen Sinn, nicht gut funktioniert. Also der Ansatz, dass man so die Architektur in den Code reinholt und dass die Architektur im guten Code beginnt, ist super. Und vielleicht um nochmal am Wüchtheft des Thema Klingcoat zu kommen, da sind natürlich auch ganz viele Aspekte drin, die schon unmittelbar ganz viel dazu beitragen können, dass Code gut ist. Leider kann ich die schlecht automatisiert testen. Ich weiß denfalls nicht wie, wenn jemand das weiß, dann und hier in der Kommentarfunktion ist, dann ist er gespannt auf die Antworten. Ich mache mal zwei Beispiele, das eine ist so. Die Forderung, dass ich das gleiche, semantische Niveau, das gleiche Level von auf Details in einer Methode halte. Also nicht einmal auf sehr hohem Niveau einfach mit Toten auf hohe Macher und dann gehe ich plötzlich in so eine ganz detaillierte Aufschlüsselung, dass ich irgendwas, was weiß ich, irgendwas Druck ausgabe, Formatierungen rausgebe. Das ist schon mal etwas, was den Code unheimlich gut strukturiert und lesbar macht. Und das zweite, was mir so umedweilend kommt, ist so dieses Stepdown-Rohl. Die geht davon aus, dass ich wie eine Treppe runter steige, kann ich eine Klasse lesen. Also ich lese die Methoden von oben nach unten runter und es wird immer sozusagen einen Stufe detaillitter. Und das sind so zwei kleine, durch das für sich genommen kleine Regeln, die auch zu Klingcoater zu gehören und die Code einfach gut strukturiert und lesbar machen. Und weil Code ist, hat auch zum großen Tag Kommunikation und wenn ich lesbar und Code habe, dann habe ich verständlichen Code und dann bleibt der Code auch lebendiger. Dann kann ich ihn nochmal weitergeben, man jemand anders. Ich habe in den vergangenen Podcast immer so ein bisschen die Zukunftsfrage im Blick gehabt. Und wir haben jetzt beispielsweise schon über Microsoft Services geredet, was für viele ein Zukunftsmodell ist. Und jetzt gerade haben wir aber auch andere disruptive Techniken, die dazwischen kommen, beispielsweise KI, Chat GPD, OpenAI, Large Language Models, im weitesten Sinne. Wir hier in die Brecher schlagen, die auch Code produzieren können, mal schlechter mal besser, aber auch was seit einigen Jahren so vor sich hinreift angesichts des drohenden Fachkräftemangels, die Logcode und Logcode Programmi-Hung, wo ich Citizen Developer ansätze auch ein gewisses Problem. Wie stelle ich sicher, dass in solchen, in einem solchen Umfeld meine erstelle Software oder auch Software Teile den Codeprinzipien entsprechen kann? Hab ich mich so explizit nicht mit auseinandergesetzt, wie ich bei Logcode, Logcode ansetzen mit Klingcoaterbeiten würde. Wäre mal einen vertieften Blick wert. Meine Wahrnehmung ist, dass diese Ansätze in der Regel da an Platz haben, wo es kleinere abgegrenzte Einheiten sind, wo man dann vielleicht auch eher so diesen Wegwerf-Aspekt, das ist jetzt bisschen despektierlich, aber also flägt. Also das man sagt, man hängt es an der Stelle nicht ganz so hoch dieses Qualitätsthema. Und erlaubt dann lieber, oder führt dann lieber so was wie Code-Lebius ein oder so ein Per Programming, also dass man mit mehreren Augen drauf guckt. Aber es ist nicht zu sehr formalisiert, weil da nimmt ja gerade den Vorteil von so einem Logcode ansatz wieder weg. Aber das ist jetzt ein bisschen theoretisch gedacht, da habe ich jetzt keine praktischen Erfahrungen mit tatsächlich. Also was du, das andere, was du erwähnt hast, würde ich gerne darauf eingehen, also was ich als wirklich eine ganz große Disruption unserer Branche sehe, das ist tatsächlich Ladschlein-Wit-Models, sowas wie ChatGit-T als Code-Generator, aber auch sowas wie GitHub-Copilot und diese ganzen Ansätze, die da kommen. Das ist etwas, was mich auch total umtreibt, gerade in der, also meine Kollegen und Kolleginnen und mich in der Lehre, wie bilden wir zukünftig Studierende aus, wie die integrieren wir das in die Lehre und was müssen Studierende zukünftig können, um solche Tools als Werkzeuge zu benutzen. Also wir haben da, ob ich mich gerade im letzten Semester mit einem Masterprojekt sehr intensiv mit auseinandergesetzt, mit sehr schöner Gipnissen beschreiben, dann gerade Paper zu. Das ist ein, das wird glaube ich nochmal unsere ganze Software-Entwicklung sehr stark durcheinander wirbeln. Und im Moment sind solche Tools, solche KI noch nicht so 100% in der Lage auch, wir haben einmal alle Aspekte von sauberem Software Design zu anzuwenden, aber ich sehe das durchaus im Rahmen der Entwicklungs-Rotemap bei diesen Tools. Und dann müssen wir eben gucken, dass wir mehr sowas als Werkzeuge benutzen und ein waches Auge für Software-Kolität haben und eben entscheiden, wo wir die Schwelle um nochmal zu deinem Lock-Hot-Knock-Hot beispielsweise abzubieten. Also wo wir dann, sagen wir mal, wie viel Aufwand reinstecken wollen und müssen, dass wir also die Knappen-Rissaußen, die wir haben so verteilen, dass sie den maximalen Wutswert auch haben. Also nicht Qualitäten der Qualität wählen, sondern Qualität da, wo es sich wirklich langfristig auch lohnt. Ich fand schon, dass du schon angerissen hast, wie ich bei Lock-Hot die Qualität sicherstellen, nämlich ganz ohne, dann spricht dann in diesem Umfeld auch Pro-Coder, ohne Software-Invigre wird es nicht jenes, heißt die braucht immer einen, der auch über den Code drüber schauen kann, notice du vielleicht was verbessern kann, was nicht vernünftig umgesetzt wurde. Und wo ich tatsächlich finde, dass die KI dann auch helfen kann, ist beim Verständnis von Code. Also wenn ich ihn auf rein kopieren kann und sagen kann, was macht der hier eigentlich, dann ist das natürlich auch in gewisser Hinsicht etwas, wo ich meine Hilfestellung holen kann, Code zu verstehen und Code besser lesen zu können, bevor ich mich da einmal durchfuchsen muss. Absolut, also die Erfahrung haben wir auch in dem Projekt gemacht. Code kann prima erklärt werden vom ChatGPT, ChatGPT kann auch ganz gut Bugs finden. In dem Fall haben wir das so punktuell mal geprüft, ist aber auch das, was du allgemein hörst. Also es ist einfach ein wahnsinnig spannendes Werkzeug in der Software-Inviglung, was gerade so auch das Lernen, tatsächlich von neuen Sprachen total beschleunigt. Also wenn ich hingehe und ich habe jetzt für einen macheneigen Entwicklung für unser Praktikumstuhl und dann möchte ich einen CLI, so ein Commandland-Interface haben und habe dafür jetzt go gelernt, go und cobra. Und da habe ich mir von ChatGPT ein bisschen helfen lassen und dieser Zeitpunkt bis zum Sonnello-World-Programm läuft, was bei mir sonst immer so ein Tach dauert, ich bin da nicht der schnellste, das war auch 15 Minuten verkürzt und dann konnte ich anfangen, so darüber nachzudecken, wie Willis denn haben, wie möchte ich die Struktur haben, das war total hilfreich. Cool, wir haben oft jetzt über das Unternehmensum, wir gesprochen uns vorhin, das Wort "Metriken" verwendet und das ist ja etwas, was für ein Unternehmen, erstmal besonders wichtig ist. Früher war die wichtigste Software-Metrike, wie viel Line-Soft-Code hat er geschrieben. Das ist natürlich mittlerweile völlig obsolet, weil viele Line-Soft-Code bedeuten nicht, dass der Code gut ist, das Gegenteil kann mit unter der Fall sein. Wie kann man denn die Qualität von Code, deine Mangel nach objektiven Messen und welche Metriken sind, jetzt beim Clean-Coding, besonders aufschlussreich, gibt es da überhaupt welche? Ja, wie schon angerissen, ich bin nicht der große Metrikexperte, zwei Sachen fallen mir ein, die Anzahl der Zücke zu sagen, das kann ich leicht, relativ leicht messen und auch unterbinden, das würde ich schlicht unterbinden tatsächlich. Da werde ich, glaube ich, radikal und andere Metriken, die auch gut funktioniert, ist so züplomatische Komplexität, das kannst du auch mal messen. Das ist ein Indikator, ob irgendwas so ein bisschen in die falscher Richtung läuft, also so extreme Schachtlungen. Aber ich müsste jetzt nochmal reingucken, wie es genau funktioniert, aber das ist so die Richtung. Ich würde aber tatsächlich eher sagen, wir sollten uns einigen darauf, dass wir gewisse Regeln in, zum Beispiel A-Cune oder Verwandte-Frameworks packen und die in unsere Pipeline einbauen, sodass wir Code gar nicht einchecken können, der gewisse Qualitätsmaßstäbel nicht erfüllt. Das sind wir glaube ich besser unterwegs als mit Metriken, die ja so ein bisschen immer Xbox gucken, also ein bisschen dieses Fingerpointing machen. Das ist so mal schlecht, was du da gemacht hast. Also dann lieber dafür sorgen, dass es gar nicht erst schlecht eingechäckt wird, sondern dass es einfach einen gewissen Standard hat, wenn es in dem System landet. Das Übel an der Wurzelparken bzw. schon dort ansetzen ist natürlich immer gleich gesagt, wenn ich dann Legacy Code habe, aber nichtsdestotrotz was vorhin, glaube ich schon mal gesagt, das Kind ist in wohnen gefallen, wenn ich Metriken anwenden muss. Ja, bei Legacy Code weiß ich gar nicht, ob sich das noch so lohnt. Dann würde ich eher sagen, gut, du musst ja eben Refektorien machen, dann machst du das bei dem neuen Code. Und das Stichwort Left-Shift hast du ja eben auch schon mal anfangen gesagt, das ist ja in anderen Bereichen der IT auch total in und das finde ich auch wirklich sinnvoll. Also es da machen, wo es gerade entsteht und darauf guckt, so früh wie möglich gucken, dann kriegt man es am schnellsten auch korrigiert. Wunderbar, vielen Dank Stefan für deine Einblicke, erstens in deine Lehrarbeit und was du dort eigentlich schon den Studierenden vermitteltst, aber auch im Du bist Berater, den man entsprechend wie Unternehmen das Ganze umsetzen können. Es hat mich sehr gefreut, deine Ausführungen zu dem Thema zu hören und ich hoffe es hat dir auch Spaß gemacht. Ja, vielen Dank, hat sehr viel Spaß gemacht. Du hast gesagt, du hast vielleicht noch den einen oder einen oder anderen kleinen Hinweis für die Show Notes. Darüber würde ich mich auch sehr freuen, weil wir dann den zuhauren und zuhauren entsprechend Informationen bereitstellen können. Gerne auch dein YouTube-Kanal mit verlenken, wenn du das magst. Und was mir noch durch den Kopf gegangen ist, war, dass du gesagt hast, du weißt nicht, ob es eine Feedback-Funktion gibt. Weitlich weiß, dass Plattformen sich so weit gestreut, dass ich gar nicht alle Feedbacks im Blick behalten könnte. Also ich glaube das nicht, aber alle zuhauren und zuhauren dürfen gerne auf mich zukommen und zu dir findet man sich ja auch im Draht direkt. Ja, genau, man findet mich und dann werde ich zurecht gedist, weil der Name des Tools nicht eingefallen ist und ich nehme aber auch alle Art von Feedback auch zu den offenen Fragen hin. Also wer irgendwie Ideen hat, wie man noch ein bisschen intelligenter und cooler automatisieren kann, da bin ich immer total dankbar für. Wunderbar, also dieser Aufruf geht an euch, meldet euch gerne zurück und ich liebe das dann gerne weiter oder halt direkt an den Steffern. Vielen vielen Dank. Danke auch. Nur von meiner anderen. Schöntag noch, tschüss. Ja.