Transkript: Refactoring

Ja, hallo liebe Hörerinnen und Hörer.

Willkommen beim Python Podcast, Episode 37.

Wir wollen heute ein bisschen über Refactoring reden und natürlich ist wieder Jochen dabei.

Hi Jochen.

Jo, hallo auch Dominik.

Und wir haben heute Rolli da.

Hi Rolli.

Hi.

Kennt ihr vielleicht auch noch?

Grüße.

Ja, vielleicht erstmal ein bisschen News.

Ich weiß nicht, so viel neues Karte.

Haben wir News?

Ich weiß nicht genau.

Also am 6.

Nikolas, das ist noch nicht so lange her, zwei Tage oder so, gab es Python 13.1.

Ach, okay.

Das ist an mir vorbei gekommen, das habe ich gar nicht mitbekommen.

Habe ich bei mir jetzt überall eingebaut und stable.

Ich glaube, das war vorgestern oder so.

Oder gestern, ich bin gar nicht sicher.

Vielleicht gestern ist Django 4 released worden.

Ja, stimmt.

Ja, das ist auch eine ganz gute Neuigkeit.

Ja.

Es ist gar nicht so viel Neues dazu gekommen, ehrlich gesagt.

Aber es ist super viel weggefallen.

Also die Backwards-Inkompatibility List, oh mein Gott, die ist ungefähr fünfmal so lang wie die neuen Features.

Das ist echt krass.

Das ist super, ja.

So ein paar Sachen rausgeflogen, die man nicht mehr braucht oder die gefährlich sind oder so schon gar nicht so schlecht.

Ja.

Ja, ansonsten, weiß nicht genau.

Machen wir auch News in anderen für andere Sprachen?

Ja.

Ich glaube, hier PHP 8.1 das irgendwie released und da gibt es ein neues interessantes Feature mit dabei.

Und zwar Async Await.

So wie in Python halt auch.

Nur anders.

Also die Keywords, aber es ist ein bisschen anders.

Man kann das halt, man kann halt Async-Funktionen auch so callen ohne Await.

Was ganz interessant ist.

In JavaScript übrigens auch so.

Man muss halt nur, wenn man Await sagen will innerhalb von einer Funktion, irgendwie die Async definiert haben, aber man kann die auch einfach so aufrufen und ja, dann passiert irgendwie magisch das Richtige oder was Falsches oder was.

Aber man hat halt daher das, also was in Python tatsächlich ein bisschen nervig ist, ist man halt dieses Farbigkeitsproblem der Funktionen hat, dass man halt, wenn man irgendwo Async was machen möchte, dann.

Alles Async sein, Async, ja.

Man kann natürlich auch hingehen und sagen, okay, async.io.run oder so, aber das ist natürlich.

Er muss dann erstmal den Event-Loop immer rausmitteln oder wenn man im Dupe da gerade ist, dann ist das auch immer ein bisschen doof

und so, ja.

Ja, also ich in Python ist es expliziter als in JavaScript und in PHP, aber es ist halt auch so ein bisschen unhandlicher zu benutzen vielleicht.

Aber naja, gut.

Ja.

Aber das ist vielleicht auch mal wählenswert, weil damit wird in PHP auch dann irgendwann das möglich, was ja jetzt in Python, jetzt, das kommt ja jetzt in Python ist das jetzt in den ganzen Frameworks halt irgendwie so, oder zumindest Django und das ist bei den anderen weiß ich gar nicht so genau.

Fast API halt auch, aber das war ja schon immer so angekommen, dass man halt irgendwie Asynchram machen kann und dann eben kann man halt solche Sachen machen wie auch File-Serving vom Applikationsserver aus oder halt auch Websocker ist relativ einfach und so und das geht dann halt.

Weil ich weiß gar nicht, wie das in PHP ist.

Da normalerweise eben Sachen PHP-File-Serven, das geht halt einfach nicht so richtig gut, weil üblicherweise hat man nach irgendwie einer Minute oder so werden die Prozesse gekillt bei den meisten Hostern.

Ja, da brauchst du mich jetzt gar nicht fraglich.

Null kommen wir gar nicht aus mit der Sprache.

Naja, aber genau, da geht es halt auf jeden Fall auch voran.

Also sowieso PHP in den letzten Versionen viel dazu gekommen und ja.

Ich kenne die mir noch vom Gegenschubsen und versuchen umzutreten.

Tja.

Kann man natürlich auch machen.

Ja, haben wir noch andere News?

Haben wir noch was?

War's nicht.

Was war denn in Dango 4 drin alles?

Schönes.

Wisst ihr das noch?

Ja, neuer, also Django Redis ist irgendwie.

Also Django Redis-Client wird reingekommen war.

Automatisch.

Das gab ja immer sonst Dango Redis Package und das kann man direkt als Default setzen oder

so, ne?

Ja, es ist jetzt halt drin, weil es gab irgendwie eine Umfrage, was verwendet ihr denn so für Caching und alle nehmen Redis.

Genau, Memcache war eingebaut im Ding und aber alle nehmen Redis, daher macht es irgendwie nicht so richtig viel Sinn, da das nicht eingebaut zu haben.

Und ja, deswegen ist das jetzt halt drin.

Ja, ansonsten, naja, was nicht.

Die haben weit die Set ist rausgeflogen, glaube ich, in der

Version oder so zu unserem Niveau.

Aber ich glaube, das war echt mehr ein Aufräum-Release gefühlt.

Was ja auch eine gute Sache ist und was auch sehr gut zu unserer Refactoring-Session anpasst.

Absolut.

Genau.

Das ist nämlich das Thema, glaube ich.

Genau, das Thema.

Ja, was ist denn das überhaupt, Refactoring?

Was sagt ihr denn, was das ist?

Also ich sag mal so, ich baute da oft meinen Code um, aber ist das schon Refactoring?

Also immer dann, wenn man halt ein bisschen später wieder drauf guckt, merkt man halt, oh, wie war ich doof oder ego, ist das dann aber hässlich oder schlecht, was ich denn vorher gemacht habe.

Mache ich das doch mal nochmal oder passe ein bisschen an oder machst du ganz von neu.

Was heißt Refactoring für euch?

Nimmt man nicht da extra Zeit für?

Gehört das in ein Sprint oder so?

Also ich würde jetzt mal sagen, so dem meinem Verständnis nach gehört das halt schon dazu, zu den, also wenn man sich der agilen Softwareentwicklung bedient als Prozessmethode, was auch immer wie man das nennen möchte, dann würde ich sagen, ich würde mal so Definitions of Done zum Beispiel bei Scrum.

Sagt, wann ist was fertig und dann würde aus meiner Sicht halt dazu gehören, normalerweise, dass man sagt, man hat das auch irgendwie mal refactured oder so.

Wie viel Prozent der Zeit würde in sowas wieder?

Ach, keine

Ahnung, das kommt drauf an.

So ein Tag?

Je nachdem, was man macht.

Nee, das kommt halt.

Und manchmal muss man es vielleicht auf das komplette System refactoren, weil.

Wer refactort das denn man selber?

Ein anderes Team?

Das eigene Team mit vier, fünf, sechs Augenprintsieben?

Nee, immer der, der fragt.

Okay, also bei uns bin ich jetzt immer ich.

Also ich bin, weil ich mag das irgendwie, Code umzubauen.

Ich weiß auch nicht, das ist doch so ein bisschen ein blödes Hobby.

Also es gibt ja Zen of Python, das ist ja eigentlich eher für andere Dinge da.

Da wollten wir auch nochmal eine Folge drüber machen.

Aber der erste Satz ist natürlich, beautiful is better than ugly.

Ja.

Und ich mag das irgendwie, wenn es hübsch ist.

Aber ist das ein guter Grund zum Reflektor, dass es halt nach und aussieht?

Es tut halt dasselbe.

Ist das das wartbarer?

Aus meiner Sicht eigentlich schon.

Aber da ist natürlich irgendwie quasi, ja, aber ich meine, man

kann unendlich viel Zeit damit zu verbringen, immer wieder dran rumzufeilen und dass es immer alles ein bisschen hübscher ist.

Es macht halt kein einziges Feature mehr.

Aber das ist auch vielleicht so ein bisschen, das hatten wir schon ein paar Mal erwähnt, so dieses, warum Programmierer irgendwie, Programmierer sein, irgendwie nicht so business-lassig ist.

Wie ist nochmal dieser Talk?

Da hatten wir schon mal drüber gesprochen.

Weiß ich gar nicht, welche meinst du.

Ja, ja, der weißt, du kennst auch noch, der hast du auch gesehen.

Der war auf der DjangoCon irgendwie ganz entspannt.

Ach, der, der erste, ne?

Der erste Talk auf der DjangoCon EU, ja, der, ja, weil man mag halt programmieren.

Bei Programm ist Fun oder sowas.

Und deswegen macht man das halt und ob es irgendwie am Schluss dabei was rauskommt oder nicht, ist eigentlich dann auch so ein bisschen egal.

Ich glaube, ganz wichtig ist halt wie in allen Bereichen, überall ist halt Pareto-Prinzip.

Also dass man einfach schauen muss, dass man, also 80% der Red-Sachen kriegst du halt einfach in 20% der Zeit refactort und die Details, die kosten halt richtig viel.

Die ganz wichtigen Details davon das erklären.

Ich weiß nicht.

Es kommt immer ganz drauf an, würde ich sagen.

Also ich meine, wenn man jetzt irgendwie an einer Software bastelt und da geht es jetzt gerade irgendwie um die, weiß ich nicht, Zahlungsschnittstelle oder Auftragsabwicklung, dann sollte man schon schauen, dass das vernünftig funktioniert und dass man da vielleicht auch eher einen Schritt weiter denkt, als einen Schritt zu kurz denkt.

Aber es gibt ja doch in jedem System Bereiche, weiß ich nicht, irgendeine Administrationsseite, die zweimal im Jahr aufgerufen wird oder so.

Und wenn die jetzt nicht ganz perfekt ist, jo, ich meine.

Also du sagst ja, dann der Business Use Case, das ist eigentlich, glaube ich, eine sehr gesunde Einstellung, wenn man sagt, es geht darum, ein Business Value.

Also zumindest aus der Business ist es eine sehr gesunde Einstellung, da hat man das an.

Aber ich würde nicht nur sagen, dass, also zum Beispiel, ich habe jetzt in einem Projekt, habe ich jetzt, ich habe ja vor einiger Zeit mir mal so ganz tolle Class-Based E-Mails für Django ausgedacht und habe jetzt in einem Projekt mal wirklich, weil ich Internationalisierung eingebaut habe, habe ich jetzt dann direkt alle E-Mails, weil ich da eh dran musste, weil ich die Templates halt anpassen musste und gucken muss, dass halt die Sprache reingegeben wird, etc.

etc.

Habe ich halt dann direkt gesagt, okay, ich refactor jetzt direkt alle E-Mails zu Class-Based.

Was ist natürlich viel, viel, also das war definitiv in den 20 Prozent, ja, und nicht in den 80%.

Aber trotzdem weiß ich jetzt halt, dass wenn ich irgendwas mit den E-Mails machen muss und vielleicht mal auch generell was anpassen, zum Beispiel nochmal irgendwie das Layout überarbeiten, was eh für irgendwann ansteht bei dem Projekt und sowas, habe ich halt danach einfach weniger Arbeit und das bot sich halt an.

Wenn ich die Dinger eger auseinandernehme, dann mache ich das halt einfach noch mit.

Gut, aber das ist jetzt auch wieder aus dem Effizienzgedanken heraus.

Das heißt, du machst Refactoring deswegen, weil du später Arbeitszeit, Wartungszeit oder neue Feature-Entwicklungszeit sparst.

Ja.

Okay, das wäre auch so ein Effizienzgedanken.

Also quasi extrem wichtig, dass man das dann tut.

Und es schont dann auch meine Nerven, wenn ich das dann nächstes Mal entspannter machen kann.

Ja, das finde ich auch.

Also ich finde so Faktoren aufgrund von, wir brauchen das vielleicht nochmal und wie das da so steht, das versteht ja keiner.

Dass es eine Spaghetti-Band irgendwie hat irgendwas gebaut, weil er noch gar nicht wusste, wie das ging, hat das dann alles hingeschrieben.

Das ging dann irgendwie, aber so richtig nutzbar und schön ist das alles nicht, dass es irgendwie so, wie man so kennt, so zusammengezimmert.

Ich finde auch ein ganz wichtiger Punkt, ist, dass halt, also die meiste Software, die funktioniert, wird ja konstant weiterentwickelt.

Es ist ja einfach so.

Frage ich mich auch ehrlich gesagt immer, warum, aber okay.

Und immer wenn neue Anforderungen dazu kommen, dann hat man die ja logischerweise vorher nicht bedacht, weil man ja nicht wusste, dass die kommt in den meisten Fällen, oder in vielen Fällen.

Und das heißt, man fängt dann an, in etwas, das nicht dafür gedacht ist, mehr Sachen reinzubauen.

Und das ist immer der Punkt, wo, glaube ich, intrinsisch einfach schon der Bedarf von einem gewissen Refactoring besteht.

Vielleicht nicht bei der ersten und zweiten Änderung, aber irgendwann ist dann, gibt die Struktur das einfach nicht mehr her.

Na, das ist halt genau die Frage, ne?

Wird was moderner, muss man das dann, diesen modernen Stil, dann auch refactoren?

Das ist aber eine Stilfrage, ja.

Das heißt, ich habe eine schönere Skulptur, die Skulptur hat eine andere Mode als vorher.

Und deswegen mache ich es jetzt auf die gleiche Art ein bisschen neuer, ein bisschen anders.

Es gibt ja jede Menge Dinge, die man neu machen kann.

Schönes Beispiel finde ich zum Beispiel Google, ja.

Google hat unheimlich viel Energie reingesteckt in das G-MAI-Programm or so.

Und eigentlich würde ich fast setzen, dass so quasi Feature Computer, so dem, was man sich so wünscht.

Man kann alles dann machen, was man mit so einem E-Mail-Clientlich so machen will.

Und die haben auch schon so viel Zeit drauf geschmissen, dass so viel Neues nicht kommt.

Was ich jetzt immer sehe, da kommen irgendwelche Änderungen am Style, an der Grafik, die irgendwas einfach nur anders machen, die mich dann zum Beispiel eher nerven, weil ich nicht brauche, die einfach nicht will zu haben wie früher oder so, weil ich veränderungsresistent bin oder so.

Und das ist aber dann mit Refactoring verbunden.

Warum macht man das?

Vielleicht, weil die Abteilung dann denkt, okay, wir haben jetzt noch vielen Sprint, weil wir wollen nicht aufgelöst werden, wir wollen irgendwas machen und dann refactern die da irgendwie rum.

Ist halt eigentlich schon fertig, die Software.

Und ja.

Naja, du hast halt dann normalerweise irgendwelche Metriken, die halt an irgendeiner Stelle nicht so gut aussehen und dann machst du halt was, um das zu verbessern.

Und manchmal wird das dann besser und manchmal wird das dann schlechter.

Und nur schlechter für manche Leute und dann bist du halt hast du vielleicht einfach Pech.

Ja, genau.

Aber naja, ist halt die Frage.

Also ich meine, ja, man könnte auch sagen, Software ist irgendwann fertig, also irgendwann ist halt der Wert, den neue Features bringen, halt unter den Kosten, wenn du das halt priorisiert hast, nach irgendwie, was es reinkommt, irgendwie minus Kosten ist zu entwickeln.

Irgendwann wird das halt negativ.

Und aus einer Business-Sicht müsstest du dann einfach aufhören zu entwickeln.

Aber ja, ja, stimmt.

Mit diesem Schritt tun sich viele schwer.

Ja, genau.

Und dann würde er sagen, okay, gehen wir jetzt jetzt fertig und machen jetzt was anderes.

Würde ich auch sagen, dass das wäre eigentlich, irgendwann ist halt durch.

Und dann, na klar, kann man irgendwann in zehn Jahren nochmal einen Designer draufsetzen und sagen, hey, wir machen das ein bisschen moderner, aber dann muss die API vielleicht im Hintergrund bleibt halt gleich.

Und was ich aber als Entwickler jetzt auch sehr super finde, ist tatsächlich Code schöner machen, weil man lernt immer was.

Also ich kann ja eigentlich nicht so viel mit den Sachen, die ich neu mache, die kann ich vorher eigentlich meistens nicht.

Also sonst sind die immer relativ schnell fertig und dann.

Aber wenn die neu sind, dann baue ich irgendwas Neu, dann muss ich mir ein Konzept überlegen.

Ich weiß gar nicht, wo ich hin will.

Und am Ende sehe ich halt immer, oh, was auf dem Weg dahin bist du irgendwelche Sackkassen gelaufen, irgendwelche Abkürzungen gegangen, die du eigentlich gar nicht gehen solltest und hast voll irgendwas vergessen und das muss man dann nach und nach irgendwie einbauen.

Aber das sorgfältig zu machen, das dauert halt viel mehr Zeit.

Du musst den ganzen Code kann man fast wieder neu schreiben und dann hat man am Ende was viel Schöneres da stehen.

Und ich weiß nicht, ist das Refactoring?

Und ja, einem halben Jahr später fand ich es wieder an und es ist wieder irgendwie so, ich bin gesagt, es hätte irgendwie schöner machen können.

Also ich hab, äh, ich kann das ja gleich mal direkt schon mal spoilern.

Ich habe so ein Buch gelesen, das nennt sich A Philosophy of Software Design von John Oosterhood oder so.

Keine Ahnung, ob ich den jetzt richtig ausgesprochen habe.

Das wurde mir empfohlen, irgendwie in einer Hacker-News-Diskussion und deswegen werde ich jetzt ganz viel daraus zitieren oder beziehungsweise Dinge sagen, die da drin stehen, weil ich davon jetzt noch eine Menge weiß und dann dubbe ich das wieder alles vergessen.

Vielleicht habe ich jetzt schon eine ganze Menge vergessen.

Aber da ist ein schöner Satz.

Am Anfang steht da sowas wie, ja, also Software schreiben ist ja eigentlich toll, weil es ist halt so eine der puresten, eine der reinsten kreativen Tätigkeiten.

Weil man halt nicht.

Weil man hat kaum Begrenzungen durch irgendwelche Dinge, sondern also alles, was man sich vorstellen kann, kann man im Grunde machen.

Deswegen ist es halt sehr rein.

Man ist nicht abhängig von irgendwelchen Dingen.

Und da ist was dran.

Ich weiß jetzt nicht, ob die meisten Leute das so sehen würden, aber das ist halt jetzt auch relativ weit auf der

Entwicklerseite schon.

Auf der Seite, das ist halt einen Wert, wenn das schön ist, sozusagen.

Wenn es schön ist und rein ist und keine Ahnung, dann ist das irgendwie eine wertvolle Geschichte.

Und die andere Seite wäre halt, ah, ist doch egal, Hauptsache es tut.

Also Hauptsache, die Features sind entwickelt und der Kunde ist glücklich.

Und ich habe möglichst wenig Zeit dran im Rechner gesessen an der blöden Kinder, so

dass ich keine andere Sachen machen kann.

Der Produkt Owner hat es abgenommen.

Ja, und nach mir diesen Flut irgend so ein bisschen, also nicht, aber eher so ein pragmatischer Ansatz.

Ich glaube, beide haben so eine gewisse Berechtigung.

Ja, total.

Gerade wenn ich jetzt meinen Nutzen maximiere, dann würde ich möglichst wenig Zeit am Rechner verbringen, weil ich ja damit mein Geld verdiene.

Also tu mir so, ich werde per Auftrag bezahlt oder sowas, ja.

Dann will ich möglichst wenig Zeit daran sitzen, weil ich möchte ja irgendwas andere Sachen machen.

Und was dann unten drunter, wie das aussieht, ob es hübsch und hässlich ist, ist einem dann völlig egal.

Hauptsächlich schnell damit fertig und haben das, könntest du abhaken, den Auftrag erfüllt.

Das sieht ja quasi der Manager eh nicht, weil der guckt ja eh nicht unter die Haube, guckt ja nur, was am Ende dabei rausfällt.

Du zahlst es halt beim nächsten, bei der nächsten Aufgabe.

Genau, aber das, was passiert, ist mir egal.

Und ob ich dann selber dann was Neues dran platschen muss, kann ja sein.

Also man merkt es tatsächlich aber erst, wenn man so Speed aufnimmt, das heißt, wenn man das ordentlich macht, dann kann man diese Erweiterung, die Skalierung immer schneller machen und das, was Delivern von neuen Sachen, wenn man es ordentlich gemacht hat, ist dann einfacher.

Oder man kann halt Copy-Pasten aus dem anderen Projekt, wenn man es ordentlich gemacht hat und kann es ganz einfach auf die neuen Sachen generalisieren.

Das sind halt aber so Sachen, die nicht ziehen, wenn man halt immer was anderes machen muss.

Ja, sagen wir mal so, also der, der, wenn man jetzt rein aus der Business und auch aus der, sagen wir mal so, agilen Methodologie-Sicht da drauf guckt, dann ist der, es muss halt irgendwie funktionieren und ob das Feature fertig ist oder nicht, ist halt das, was man von außen sieht und das ist halt das Relevante.

Das ist der deutlich dominantere, der deutlich dominantere Punkt, was halt dazu führt, dass der halt auch oft sehr stark betont wird in so kommerziellen Entwicklungen.

Ja, ja, also der Manager, der interessiert sich nur für das KPI-Feature fertig oder nicht, User-Story.

Das ist halt der Atomar gesehen, ne?

Also wenn man, wenn man jetzt sagt, im Endeffekt, jedes Feature ist, also wenn man sich das wie so, weiß ich nicht, eine Menge von Commits im Branch oder sowas vorstellt, jedes Feature ist ja irgendwie ein Teil auf dieser Strecke zum Produkt, das irgendwann fertig oder an einem irgendwann an einem Release-Punkt ist.

Und wenn man das halt sehr atomar sieht, dann ist es stimmt das natürlich.

Aber wenn man das halt übers große Ganze sieht, dann, insbesondere bei langlaufenden Projekten, die halt wirklich konstant weiterentwickelt werden, und wo vielleicht dann auch irgendwie ein Geschäftsprozess oder irgendwas, also wirklich dann Firmengeld drüber läuft, glaube ich, ist das halt viel zu kurz gedacht.

Also ich kann da, ich habe letztens mit ein paar Entwicklern gesprochen und die waren in ihrem Projekt halt so ein bisschen nicht wirklich schlimmer, es ging so ein bisschen fing an, Richtung Zombie-Scrumb zu werden.

Es waren relativ hohe Backquote.

Das Team ist sehr viel Sachen hinterhergelaufen.

Generell war so.

Eine Backquote, ganz kurz, ist eine Anzahl an Bugs pro 100 Zeilen-Code oder wie müsste man sagen?

Backquote ist quasi die Anzahl der Bugtickets an allen Tickets im Sprint.

Ah, okay.

Oder Bug-Storypoints auf die insgesamten Sprint-Storypoints gezogen, berechnet.

Und das Team war halt latent frustriert.

Der Product Owner hat so ein bisschen die Fähigkeit des Teams irgendwie angezweifelt, weil irgendwie da waren die Bugs und Sachen, die abgesprochen waren, haben dann plötzlich nicht mehr funktioniert.

Das war hinsgesamt so eine so eine latente Unmut auf allen Seiten irgendwie, das lief halt einfach nicht wirklich rund.

Und dann haben die halt angefangen, halt so ein paar größte Sachen einfach mal anzugehen.

Weil dann war halt gerade so der eine große, das eine große Release durch und dann haben wir okay, wir machen irgendwie Coverage rein.

Also wir zwingen Coverage in der Pipeline, also sprich, neuer Coden muss getestet sein, sonst kann ich nicht deployen, kann ich nicht, äh, committen schon, aber nicht deployen.

Dann einfach mal geschaut, dass man einfach so Streamlining, wie kriegen wir alle möglichen Variablen beim Prot-Deployment, das immer wieder mal auf die Nase fällt.

Wie kriegen wir das raus?

Und immer mehr solche Sachen halt, äh, haben die halt dann angegangen.

Und damit hat sich dann, also nicht nur, dass halt dann plötzlich die Bugquote enorm gefallen ist, das ist echt, also man glaubt nicht, was so ein simples Maß wie ich erzwinge, ich erzwinge Coverage in der Pipeline, das ist so trivial, aber es hat total geholfen und auch die anderen Sachen.

Und auf einmal hat sich dann, haben sie mir erzählt, einen ganz neuen Drive entwickelt.

Das ist echt faszinierend zu sehen gewesen.

Und ja, und da hätten ja auch, da hätten die selber nicht darüber nachgedacht, dass das wirklich so einen großen Effekt haben kann.

Aber auf einmal ist auch so diese ganze Litargie raus, wenn man plötzlich meint, hey cool, da geht was weiter, es klappt wieder, man hat plötzlich wieder auch Energie oder Muße, irgendwie Sachen anzupassen, zu refactoren, weil man halt eh das Gefühl hat, okay, es geht jetzt wieder nach oben, wir versuchen nicht irgendwie dieses Haus immer so lange zusammenzuzimmern, dass es bloß nicht auseinanderfällt, sondern man macht halt wieder was, was, ja, das Kreative, das Schöne halt.

Ich finde das so ein bisschen schwierig, weil, ähm, du hast auch was sehr Interessantes gesagt, also weil der, wenn es halt nur um diese User-Stories geht, ne, und dann möchtest du da irgendwas Schönes entwickeln, das funktioniert dann irgendwie und dann hast du langfristig Ziele, die du erreichen kannst, wenn du am Anfang von Anfang an auf gute Qualität achtest oder halt viele Tests schreibst oder ein bisschen TDD machst, also je nachdem das, was so deine Overall Quality so ein bisschen, also wenn man ein bisschen mehr nachdenkt, vielleicht am Anfang und ein bisschen mehr Know-how sich von Anfang an Team holt, ist das, glaube ich, auch was, was sich langfristig auszahlt, ja

, weil man sich irgendwie alles von vorne neu machen muss.

Aus Business ist es aber so ein bisschen komisch, weil die ist es eher so, die meckern immer die ganze Zeit rum, so, warum läuft das denn noch nicht und warum sind ja noch so viele Barks und das verstehe ich alles nicht, das muss alles fertig sein und so.

Dann aber später sind die dann gewohnt, dass sie genauso viel Zeit und Geld aufwenden müssen für Neueentwicklungen.

Und denkst du, ja, aber eigentlich ist das ja in zwei Tagen fertig, weil wir haben ja ordentlich am Anfang einen Refactor und schön gemacht.

Das heißt, wenn es richtig macht, könnte man die neuen Features alle direkt rausknallen, weil die super schnell gehen dann, aber das versteht dann keiner und das kann man auch nicht kommunizieren.

Und es ist auch eher gefährlich, das zu kommen, weil dann so eine Erwartungshaltung entsteht, dass das halt immer so wäre und dass es auch nicht irgendwie clever dann vielleicht, ne?

Für so ein ganzes Team.

Ich glaube, da ist es halt super essentiell, dass man halt einfach eine gute Vertrauensbasis mit dem Product Owner hat.

Tja.

Genau, oder überhaupt diese Kommunikation zwischen irgendwie, eben, ob das jetzt Product Owner ist, oder oft ist es ja so, der Produkt Owner ist ja noch so irgendwie quasi mehr oder weniger Teil des Teams, aber genau, Produkt Owner und also sagen wir Team irgendwie und dem Product Owner mit einem bezogen und halt irgendwie, im weitesten Sinne das Management oder so.

Wenn es gar kein Vertrauen ist, schlechtest.

Ja, genau, und auch ganz wichtig ist eigentlich, dass die Entwickler mit dem Kunden irgendwie eigentlich so viel zu tun haben oder mit dem Gedanken dieser User-Stories, dass sie halt da selber so committed drin sind, auch.

Weil wenn halt die immer nur irgendwie ihre Tickets wegschubsen, dann ist das dann irgendwann wurscht.

Das ist halt so eine genau so eine Komplikationssache.

Was der eigentliche Clou wäre, ein gutes Refactoring zu machen, von Anfang an das richtig zu tun, ist halt ein gutes Teamgespräch immer am Laufen zu halten, auch mit PO.

Und zwar nicht nur über Tickets und Leistungen und KPIs, sondern halt auch.

Aber tatsächlich, also ich meine, das ist halt auch das, also ein zu dem, zu ganzem Agile-Kram gibt es halt auch einen kleinen Absatz in dem Buch, wo da halt so gesagt hast, ja, okay, Agile voll gut, iterativ super, irgendwie, dass die Fachkompetenz nicht an den Reichen gekommen ist.

Also viele gute Sachen dabei, aber irgendwie, was nicht so toll ist, ist, dass diese ganzen Agile-Geschichten einen großen Wert auf diesen, was bringt es fürs Business-Punkt legen, was ja auch nicht unbedingt falsch ist, aber sozusagen sie tendieren dazu, das deutlich überzubetonen, weil es gibt halt auch diesen anderen Punkt.

Ist das denn jetzt gut Design zum Beispiel?

Ist das denn schön?

Ist das denn mit der geringstmöglichen Komplexität irgendwie gebaut worden?

Und da gibt es jedenfalls auch auf meiner Ansicht nach nichts in dem, zum Beispiel bei Scrum, was eine Rolle, die dafür zuständig wäre, das durchzusetzen.

Das heißt, dann nächstes Jahr noch Python.

Wenn das durch die Review beim Produktowner, der da aber nicht aus einer technischen Perspektive drauf guckt, sondern aus einer Business-Perspektive durchgeht, dann ist das ja gut.

Und das Team wird immer dazu gesagt, es ist dafür verantwortlich, dass halt das fertig sein muss, getestet sein muss.

Aber tatsächlich, es gibt niemanden, der dann sagen kann, okay, das lasse ich nicht live gehen, das geht so nicht, das ist Kacke.

Aber super Lust.

Bitte, red zu Ende.

Ja, und das gibt es halt nicht und das ist halt etwas, was so ein bisschen fehlt und was man, wo man sagen würde, okay, aus einer taktischen Perspektive ist das irgendwie, also es führt halt, das Buch sagt, es gibt halt Unterschied zwischen taktischer Softwareentwicklung und strategischer und taktisch macht das irgendwie Sinn, die Features rauszukriegen, ja, und man hat halt auch ein Problem, wenn man das nicht hinkriegt, weil dann wird einem ja möglicherweise auch der Hahn zugedreht irgendwann, wenn man auch Refactoring zu lange dauert.

Aber man muss halt die so strategische Perspektive auch berücksichtigen, weil ansonsten hat man halt irgendwann später ein Problem.

Und diese Dinger summieren sich halt auf und machen Sachen halt am Schluss sehr, sehr teuer.

Unerwarteterweise auch, ja.

Und ich würde jetzt sagen, so Refactoring ist halt auch so ein Ding, was halt im Grunde dafür da ist, die Komplexität von so einem Software-System halt zu reduzieren.

Das wäre so, würde ich denken, das wäre ein Ziel.

Wäre die Frage, was ist Komplexität?

Komplexität würde ich jetzt auch so mal definieren wie, also mit dem Buch wurde das ja pragmatisch definiert, als alles, was dazu führt, dass ein System schwerer zu ändern ist, beziehungsweise dazu führt, dass man es nicht so gut verstehen kann, ist Komplexität.

Also entweder Abhängigkeiten oder zu hohe Abstraktionsniveaus oder zu verschachtelt, falsch namen.

Also ich finde, das ist relativ nah an diesem Code-Review-Gedanken dran.

Ja, also kann ich den Code gut lesen?

Sind die Namen so, wie ich sie haben will?

Ist die Dokumentation schön?

Sind halt die Designs so implementiert, wie man es erwarten würde vielleicht?

Oder ist das irgendwas ganz anderes?

Oder sind die, macht das Sinn?

Noch ein bisschen Style?

Ist das so eine Frage?

Du hast irgendwie gesagt, du wolltest den Unterschied zwischen Design und Style an der Stelle vielleicht erklären, was ja

gemeint ist.

Design ist tatsächlich, damit ist tatsächlich das quasi, wie funktioniert das System gemeint, nicht so sehr, wie sieht's aus oder wie sieht der Code aus, das ist alles nicht so, sondern eher, wie funktionieren die Teile miteinander.

Also tatsächlich so Pattern.

Nee, also wie ist, also du hast ja, also ich meine, nimm mal sowas wie Design Patterns, da sieht man vielleicht, was da damit gemeint ist.

Das ist halt so, ja, das ist halt die Art, wie dein System designt ist.

Also da gibt es mittlerweile so ein paar logische Strukturen, an denen man sich orientieren kann für Lösungen von bestimmten Problemen.

Genau, aber man kann natürlich auch selber was machen, außer wenn man irgendwas tut, ich meine, es ist ja die Frage, ob man sich an diese Patterns hält oder nicht, oder die benutzt, aber man hat auf jeden Fall hinterher.

Interessant wäre, wenn man selber was baut, wo man keine Ahnung hat, dann immer mehr Ahnung davon bekommt und das dann refactort, ohne mal, dass man jetzt die Pattern kennt, ob jetzt die Lösung, die man hat, selber Richtung dieser Pattern konvergiert.

Ja, genau, Design Patterns ist genau das, worauf es dann halt irgendwie immer hinausläuft.

Genau.

Das ist eigentlich die Idee dabei, ja.

Ich wollte noch gerade eine Sache einwerfen zu der Sache mit der fehlenden All im Scrum.

Das ist auch eine Sache, über die ich jetzt in letzter Zeit relativ viel nachgedacht habe, weil wir ja auch ganz viele Scrum-Teams haben und im Endeffekt, es ist natürlich schon so, dass wenn du einen gut entwickler hast, dass der natürlich schon irgendwie darauf achten sollte, dass da jetzt irgendwie gute Arbeit abliefert.

Das ist ja schon irgendwie auch Teil des Jobs.

Aber diese Sache, dass man halt so eine Ebene höher denkt, dass man überlegt, okay, wann ist denn jetzt der Zeitpunkt gekommen, dass ich jetzt nicht das 18.

Feature noch da reinbauen kann, sondern dass ich es halt mal irgendwie besser reflectern muss, umstrukturieren muss.

Oder zu überlegen, wie setze ich denn jetzt die Sachen so um, dass es in einem Jahr auch noch funktioniert.

Das sind ja Sachen, die stehen ja nicht in der User-Story drin, die stehen nicht bei den Epics drin.

Der Product Owner hat davon keine Ahnung, weil er ja kein Techniker ist.

Der Scrum Master ist vielleicht Technik, aber vielleicht auch nicht.

Das heißt, er kann es auch nicht beurteilen.

Dann hast du ein Team, was ja meistens gemischt aus Seniors und Juniors ist.

Bei den Uniors kann man es eigentlich nicht erwarten, dass wenn jemand ganz frisch im Job ist, schon irgendwie drei Jahre im Voraus denkt.

Und es gibt tatsächlich auch super viele Artikel dazu im Internet, die genau versuchen, diese Idee des IT-Architekten aus dem klassischen Wasserfall irgendwie in dieses, ich habe jetzt nicht Gänsefüßchen gesagt, IT-Architekt, weil das irgendwie in dieses Scrum reinzubringen.

Und da gibt es halt auch wirklich lange Artikel und so dazu, wo halt wirklich dafür auch gesagt wird, dass man das braucht, wie du es gerade auch gesagt hast und dass es auf jeden Fall ein Muss.

Und dann gibt es Artikel, die sagen, nein, braucht man nicht weit und so weiter.

Und ich glaube, dass die Wahrheit liegt wie immer dazwischen und ich glaube, eine Sache, die im Scrum nicht vorgesehen ist, aber eine Lösung dafür könnte sein, halt jemand, der sich halt, sag ich mal, so als Lead-Entwickler im Team sieht.

Das ist im Scrum ja explizit eigentlich nicht gewünscht, weil er alle gleich sind und alle haben gleich die Verantwortung.

Aber ich glaube, so zumindest wieder.

Aber oben und die Teams ja auch immer nicht, ne?

Genau.

Aber ich glaube, wenn du jemanden hast, der sich dafür verantwortlich fühlt und der das, der das technische Know-how hat, und wie gesagt, wichtig auch, dass es, dass er erstens weiß, dass er diese Rolle hat und zweitens auch, dass er das machen kann, dann glaube ich, kann das diese Brücke schon ganz gut überspannen, also diese Brücke spannen.

Und wenn der PO dieser Person auch vertraut und wenn die Person sagt, nee, sorry, aber wir müssen uns ja das technische Ticket vorher machen, bevor wir das umsetzen, weil sonst wird sonst nichts, dann glaube ich, ist das so der Weg, den man da gut geht.

Aber ganz interessant, du hast gerade von klassischen Wasserfall-Software-Architekten gesprochen.

Den musst du vielleicht nochmal kurz erklären, weil den kennt vielleicht auch nicht jeder.

Also ich bin da jetzt auch kein Experte, ich bin auch mit agiler Entwicklung, naja, nicht aufgewachsen, aber schon die, wir haben nie wirklich nach klassisch Wasserfall gearbeitet.

Die Idee dahinter ist eigentlich, dass ein IT-Architekt, der im Agilen ist es ja, dass man iterativ und kleinteilig arbeitet und im Wasserfall ist die Idee, dass man am Anfang alle Informationen, die man hat, sammelt.

80% Planung und dann wird umgesetzt, oder?

Genau, und also darum auch Wasserfall, du fängst halt quasi oben an und danach geht das diese Stufen einfach immer runter und am Schluss kommt halt in Gänsefüßchen eine fertige Software raus.

Und da sind halt einfach ganz viele Probleme, weil, wie gesagt, Software ist nie fertig und Wasserfall macht doch keinen Sinn.

Und der IT-Architekt ist halt derjenige, der unter anderem halt dieses Lasten- und der Pflichtenheft schreibt initial.

Also spricht, der sich dann auch nicht.

Da ist der Entwickler dann aber auch.

Der quasi der Entwickler ist, ein IT-Architekt in dem Falle und

nicht zwingend.

Also ich glaube, es ist tatsächlich auch eine eigene Rolle gewesen oder ist es noch.

Also je größer die Firma, umso mehr Rollen hast du da logischerweise.

Aber ich glaube, die Idee ist wirklich, dass es jemand, der gar kein zwingender Entwickler sein muss, der aber trotzdem halt technisches Know-how hat und der versucht, alle Abhängigkeiten und Eventualitäten, die dieses System betrifft, also alles, was man an Setup, Surroundings und so weiter hat, alles bedenkt und das alles niederschreibt.

Ja, dann braucht der eigentlich relativ viel Ahnung vom eigentlichen Business, ja, und vom Kunden, ja, für alles, was.

Und halt auch technisch, also das ist das Wichtige, also dass man zum Beispiel sagt, weiß ich nicht, wenn ich jetzt irgendwas habe mit asynchronen Prozessen und Mailing, dass ich halt sicherstelle, dass irgendwo darüber nachgedacht ist, dass ich irgendeine Art von asynchronem Processing auch drin habe und nicht, dass das halt dann nachher irgendwann auffällt, ups, blöd, wie machen wir das denn jetzt?

Blödsinn.

Das ist ja blockiert leider den Prozess.

Ja, also genau, Software-Architektur ist natürlich auch so ein verwandtes Thema und ja, genau, aber ja, wer ist dafür zuständig?

Gibt es dann meistens, also Software-Architektur, also es kann sein, dass sie dann halt nicht in den Teams immer mit drin sind, sondern übergreifend, die gucken sich das dann halt mal an und machen dann irgendwie Vorschläge oder so.

Aber ja, es ist unterschiedlich, wie das gehandhabt wird, aber genau, also dass da irgendwie sich jemand darum kümmern müsste, mal so, ist eigentlich schon, glaube ich, relativ offensichtlich.

Ja, aber was, was, genau, was denkt ihr denn so, genau, was macht man denn, wenn man versucht, so ein Software-System einfacher zu machen?

Was könnte man denn da tun?

Müsste man das Refactoren?

Na gut, Refactoring ist jetzt sozusagen das, was man dann tut, aber wenn man, was wäre denn das Ziel von so einem Refacturing, wenn es darum geht, die Komplexität zu senken?

Also ich würde auch, ich würde tatsächlich von diesem Schönheitsansatz ausgehen.

Ja, das ist ein bisschen abstrakt.

Wahrscheinlich wisst ihr alle, was man damit meint, wenn ihr schon mal irgendwie ein bisschen gut geschrieben habt.

Kennt ihr was, was agil ist und was stinkt irgendwie oder was man denkt, oh, das ist aber hübsch.

Was wir da am Anfang irgendwie dann so um die On, ich habe das am Anfang nicht so richtig verstanden.

Ich werde, vielleicht geht es ja anderen Leuten auch so.

Immer wenn dann jemand drauf geguckt hat und meinte so, okay, vielleicht nicht so toll, dann hieß es immer so, ja, da muss man vielleicht mal so ein bisschen modularisieren oder so.

Modularisierung, ich weiß nicht, ob euch das schon mal so, genau, da gibt es ein ganz berühmtes Paper von 1972, glaube ich, ist das.

Jetzt habe ich den Titel vergessen.

Naja, David Calas, ja, genau.

Wo der zum ersten Mal diese Idee formuliert hat, dass wenn du jetzt ein komplexes System hast, wo viele Abhängigkeiten sind oder so, dann ist es vielleicht eine gute Idee, das System so zu teilen, dass man nur noch einzelne Teile quasi verstehen muss und nicht alles auf einmal.

Microservices.

Und ja, wie man das dann macht, ist eigentlich relativ egal.

Du kannst es mit Microservices machen, du kannst es aber auch mit Funktionen machen, mit Klassen, mit Modulen, Paketen, was auch immer.

Völlig egal.

Das ist letztlich nicht der wichtige Teil, sondern der wichtige Teil ist quasi, kannst du dein System so aufteilen, dass sich die Komplexität deines Gesamtsystems reduziert auf die Komplexität des komplexesten Moduls sozusagen.

Ja, das finde ich.

Idealfall.

Also weil zum Beispiel in Dango gelingt es mir nicht immer, dass man so die Sachen voneinander trennt, weil viele Sachen sind von User-Sap-Abhängig oder sowas, dass das nicht so einfach, dass irgendwie.

Das ist nicht so einfach, das ist auch richtig, ja.

Das ist genau das, ja, genau.

Ich wusste dann auch nicht so genau, was macht man denn dann da genau und so.

Alles sehr schwierig.

Ja, ist es tatsächlich auch sehr schwierig.

Finde ich immer noch schwierig.

Aber ja, also im Grunde ist das halt so die Idee, dass man das halt tatsächlich vielleicht irgendwie so hinbekommt.

Und ja, das ist im Grunde auch, im Grunde jetzt rausfinden, wie sind diese Module und was soll damit was reden und wie sind die Interfaces?

Das ist eigentlich im Grunde das, was Software-Architektur macht, beziehungsweise was man halt auch macht, wenn man jetzt Design macht irgendwie.

Also nochmal, Interface ist halt die Schnittstelle, quasi eine API, wo ein Modul mit einem anderen interagiert.

Und da muss man quasi definieren, welches Protokoll reden die miteinander und mit welchen Feldern und welchen Daten und Datentypen wollen

die denn haben.

Und im Grunde ist, also das ist jetzt wieder, aus mir spricht dieses Buch.

Geht es da, ist der interessante Teil gar nicht darum, wie man das jetzt technisch umsetzt oder so, sondern im Grunde ist die interessante Frage, naja, also die Abstraktion, also man hat halt Abstraktion.

Also ein Modul ist ja auch so eine Abstraktion und eine Abstraktion hat immer das Ziel, dass man etwas, also quasi nur einen bestimmten Aspekt von etwas tatsächlich wissen muss und die ganze Komplexität der Diagramente ist, ist halt versteckt.

Und deswegen hat man nur diese, hat man diese Abstraktion.

Und wenn die Abstraktion gut ist, dann muss man den Rest auch nicht wissen oder meistens nicht wissen.

Wenn die Abstraktion schlecht ist, dann liegt die halt und dann muss man Dach doch wissen und das ist dann schlecht.

Aber wenn man eine gute Abstraktion gefunden hat, dann braucht man sich sozusagen mental nur mit dieser Abstraktion beschäftigen und gar nicht wissen, wie das im Detail alles funktioniert.

Zum Beispiel Python.

Ja, es hat eine Sprache, die so ein relativ hohes Abstraktionslevel hat, vielleicht auch schon über viele Probleme.

Also das ist ja vielleicht auch der Grund, warum wir sowas benutzen und nicht mehr so alles in C schreiben oder so.

Ja, natürlich.

Also, obwohl C ist ja auch eine High-Level-Language schon, das im Gegensatz zu dem.

Wenn wir jetzt nicht mehr in Registern rumspringen wollen, wenn wir irgendwie einen Webserver schreiben, ist ja schon mal gar nicht so schlecht vielleicht.

C ist ja schon eine Hochsprache.

Ich habe tatsächlich ein ganz schönes Beispiel.

Ich hatte letztens, hatte ich eine sehr undankbare Aufgabe, ich sollte in einem Projekt, sollte ich bei, also quasi eine Sache, die sich durch das gesamte System gezogen hat, das hatte relativ viel mit Zeitberechnung zu tun, also wo irgendwie Tage und irgendwelche Uhrzeiten und Tage berechnet werden.

Und da sollte eine Sache, die vorher statisch war, also es gab halt im Endeffekt nur Tage, sollten diese Tage dann nach Regionen aufgeteilt werden.

Also jetzt beispielsweise halt Feiertage, die halt jetzt nicht nur irgendwie, es gibt nicht fixe Feiertage, sondern es gibt halt die Feiertage, je nachdem, wo halt jemand dann ist, also wie gesagtberechnungssystem.

Und das hatte halt wirklich querbeet eigentlich alle Bereiche des Systems betroffen.

Weil vorher war es halt einfach, du machst halt eine abstrahende Datenbank, ist an diesem Tag ein Feiertag fertig.

Danach musst du aber gefragt werden, naja gut, welche Leute betrachte ich denn gerade, ob jetzt Feiertage sind und wann wann haben die denn in dieser Region gewohnt und wann nicht mehr?

Und auf einmal wurde es halt, war es halt super kompliziert, eine Sache, die vorher halt wirklich trivial war, wie mit einem einzigen Select oder ORM, Abstraktion Select, halt super einfach abzufragen war.

Und dann habe ich halt auch lange darüber nachgedacht, wie ich das überhaupt hinbekomme, weil wie gesagt, ich habe nachher, glaube ich, an 300 Stellen im System irgendwas angepasst.

Und die Lösung war tatsächlich dann ganz, ganz blöd Abstraktion.

Also sprich, jetzt war halt ein Django-Projekt, ich habe dann einfach mir Custom Query Set und Manager-Methoden geschrieben, die das halt komplett wegkapseln, wo ich dann trotzdem einfach nur das Datum und vielleicht noch den Nutzer reingebe.

Und darunter liegt dann halt irgendwie ein Riesenapparat mit irgendwas, da halt alles dann passiert, um das halt zu bestimmen.

Aber von oben verwendet es sich fast genauso wie die triviale Datenbankabfrage.

Und damit habe ich es wirklich geschafft.

Also ich habe das ganze Ding umgebaut.

Ist ja auch irgendeine Art von Refactoring eigentlich, nur das ist halt das, in dem im Moment das Ticket war.

Und ich habe wirklich nur drei oder vier kleine Bugs gehabt, weil halt, wie gesagt, die ganze Komplexität an einer einzigen Stelle war und ich halt danach nur noch schauen, musste sich halt die Methoden austauschen.

Und das war, es hat mich selbst total überrascht, wie gut das funktioniert hat.

Also das hätte ich, hätte ich mir selbst nicht zugetraut, dass die Idee dann doch so gut trägt.

Ja.

Ja.

Ja, das ist super.

Wenn man so eine High-Level-API hat, die man gut bedienen kann, ist das schon echt was wert.

Ja, also genau, also und was sind gute Abstraktionen, also nach dem Buch, ist es halt so, ja, wenn Module tief sind, ist das gut.

Und wenn die API halt kleiner ist, ist das auch gut.

Also je kleiner die API und tiefer, je kleiner und tiefer, desto besser.

Genau, also du kannst mit einfachen Worten viel erreichen.

Das ist also

ein schönes.

Also als sozusagen ein Beispiel für das ist irgendwie eine schöne API, ist halt hier die Pile-API von Unix benutzt, das ist halt auch tatsächlich eine sehr schöne.

Also das ist ja im Grunde Unix ist nichts ist ja, wir hatten das letztes Mal in der letzten Episode, was wenn alles ein Dikt wäre.

Unix ist halt so, was wenn alles ein Pfeil wäre.

Das ist irgendwie die Antwort darauf.

Dann kommt halt, dann fällt halt Unix dabei raus.

Und die File-API ist halt tatsächlich, die ist halt sehr, also man kann nicht, es gibt nicht viele Operationen, die man machen kann.

Also was ist denn Open, Seek und Close?

Es gibt Open, Meet und Read.

Und das war es eigentlich schon fast, ja.

Also Close, weiß ich gar nicht, ob das ein eigener.

Ja, doch, wahrscheinlich.

Ja, aber stimmt.

Genau.

Und ja, es gibt noch I.O.

Control, aber.

Also wahrscheinlich Read and Write oder so, aber ja.

Was ist I.O.-Control?

Ja, ja, man kann jetzt noch Spezialoperationen machen.

Da wird es dann auch allem ehrlich hässlich.

Aber tatsächlich eigentlich so mit Pfeil aufmachen, irgendwie drin rumsieken, lesen, schreiben, kommt man halt schon sehr, sehr weit.

Und ja, das ist halt eine schöne Abstraktion.

Während zum Beispiel die Abstraktion, das ist so ein Negativbeispiel gewesen.

Halt so, wenn man jetzt in Java irgendwie Dinge lesen will aus einem Pfeil, dann macht man erstmal irgendwie so einen Input-Reader auf und dann macht man so einen Buffer-Input-Reader auf.

Wenn man das vergisst, hat man ein Problem, dann ist alles ganz langsam, man weiß nicht so genau, warum.

Und dann muss man die Dinger konfigurieren.

Und die Exposen halt ganz viele Sachen, die man halt setzen muss.

Und der Default-File ist halt, den man halt eigentlich immer hat, der ist halt nicht der, also wenn man es einfach nur so aufmacht, ein File, dann hat man halt keine gebufferte IO und das ist halt alles ganz schrecklich.

Und man muss halt sehr, sehr viel Detailwissen in der API schon, also man konfiguriert da schon sehr viel rum und also man hat halt, die API hat eine große Oberfläche und es ist schwer zu benutzen und eigentlich, was sie macht, ist relativ trivial.

Also es sieht super flach.

Also du hast eben Python with OpenFileName als FileFile.read.

Genau, oder ja, vor Line in File oder sowas.

Das ist halt irgendwie, und das macht halt auch per Default alles richtig.

Ja, wenn du das in Python machst, dann ist das halt direkt schnell und macht alles schon so, wie man das eigentlich normalerweise haben will.

Für die Fälle, in denen man das nicht so haben will, kann man das ja immer noch konfigurieren, dass das nicht, dass es sich anders verhält.

Aber genau, und das ist halt gutes versus schlechtes API-Design quasi.

Ja.

Und ja, aber die richtige API für ein Problem, das man hat oder die überhaupt die richtige Abstraktion zu finden, ist natürlich nicht so einfach.

Das ist halt richtig schwierig.

Vielleicht auch einer der Gründe für PHP, warum das immer so schlecht angesehen wird an so zwei Stellen und sich lange braucht, bis es ein bisschen besser wurde.

Also wie gesagt, ich habe immer noch keine Ahnung davon.

Aber ist, dass einer der Erfinder ja irgendwie gesagt hat am Anfang so, ja, eigentlich kenne ich mich Programmiersprachen eigentlich gar nicht aus und ich wollte eigentlich auch nie Sprache machen, aber hey, jetzt bin ich hier irgendwie und da wir müssen jetzt irgendwie das wieder retten und dann.

Ja, aber ich meine, es ist schon einen langen Weg gekommen, sozusagen, also mittlerweile ist das PHP gemacht.

Aber ja, vielleicht

einer der Gründe dafür, dass man sich über sowas noch keine Gedanken gemacht hat.

Während Guido ja, glaube ich, von Anfang an, glaube ich, sehr auf diesem Level war, dass er schon so ein bisschen wusste, warum er Sachen wie machen wollte.

Ja, ja, der hat da viel Absicht mit dabei, ja.

Ja, keine Ahnung.

Also ist

ja auch die Frage, ne?

Ist also eine neue Sprache, ein Refactoring von neuen Gedanken, die man über Computer hat?

Ja.

Naja, ja, aber ich meine, es ist halt, aber es ist wirklich schwer zu sagen.

Also man kann das nicht unbedingt vorher, also man, ich glaube nicht, dass das eben auch im Sprachdesign ist ja, also das wäre jetzt sozusagen, wie ist eine Sprache design.

Da die richtigen Abstraktionen zu finden, auch super schwierig.

Und da würden da Leute dann auch direkt am Anfang schon unterschiedliche Ansichten vertreten und würden halt sagen, so, okay, also es gibt dann halt ein Lager irgendwie, das sagen würde, so, ach, dieses dynamisch Getypte, das ist alles nicht gut.

Irgendwie statisch getypt, bestes getübt, voll gut.

Muss alles statisch, ja, und an der Stelle wird man sich ja schon, und das ist bis heute nicht raus, was jetzt nur besser ist.

Aber es ist da an, also typisieren ist auf jeden Fall anstrengender, wenn man halt also einfach mal sowas schnell hinhotzen muss.

Ich habe heute eine kurze Übung in Rust geschrieben.

Das ist einfach halt, du musst halt jedes Mal an jedem keinen Fitzel dran treiben, was das eigentlich sein soll oder sollte.

Und dann beschwert er sich der Compiler immer, wenn es halt nicht stimmt.

Was ja auch gar nicht eigentlich schlecht ist, weil eine Benutzer will, man ja, dass es eigentlich stimmt.

Meistens ist es halt an egal, aber es funktioniert irgendwie trotzdem und das ist ein bisschen.

Ja, aber das ist genau so ein Punkt.

Genau, also wenn du jetzt in, du kannst ja jetzt auch zum Beispiel in Python Type-Annotations machen.

Und auch unbedingt in meiner Folge.

Ich habe jetzt erst so vor kurzem damit angefangen, mich so ein bisschen zu beschäftigen, weil ich dachte ich immer so, oh, du musst aber auch Type-Annotationen schreiben.

Oh, keine Lust.

Und mich interessiert das alles nicht.

Ich bin ja nicht deswegen zu Python gegangen, damit ich irgendwie überall Typen dran schreiben muss.

Aber es mit Fast-API, obwohl das wir übrigens auch noch eine Folge machen, das ist cool benutzt, Alter.

Aber da macht das sogar dann Dinge, wenn du die Typen verwendest und so.

Ja, ja, ja, ja.

Aber gut, da passieren auch Sachen dynamisch.

Also das ist halt auch nochmal so ein, das geht ja schon fast darüber, die reinen Typannotationen hinaus, sondern.

Ja, also je nachdem, was für Typen man dann da hat, passieren halt unterschiedliche Sachen, aber dann auch zur Laufzeit, nicht nur nicht nur für einen statischen Typ-Checker.

Ja, aber natürlich, genau, das ist halt so ein Problem beim Sprachdesign.

Will man jetzt Typisierung haben oder nicht?

Weil es natürlich fängt es halt Bugs.

Ich habe das jetzt auch gemerkt, ich mache das seit einiger Zeit, mache ich auch Fast API und habe jetzt auch, dachte ich mir, gut, wenn ich das schon mache, dann schreibe ich die Annotation halt auch mit dazu.

Und tatsächlich sind mir schon ein paar Mal Sachen aufgefallen, wo ich dann gemerkt habe: so, oh, das, da hat mir jetzt, und ich lasse dann auch MyPi drüber laufen, wo mir dann MyPi auf die Finger haut oder halt eben Pilance oder was auch immer, so, da ist irgendwas nicht richtig.

Und ich denke, so, oh, okay, also meistens ist es tatsächlich nur, ich habe es nicht richtig hingeschrieben, ich habe das irgendwie nicht richtig bedient.

Und deswegen, und man muss es ein bisschen anders hinschreiben und dann stimmt's, aber das, was ich vorhatte, war schon richtig.

Und dann ab und zu kommt dann doch so ein Ding, wo ich dann drüber nachdenke und dann so, oh Mist, tatsächlich, an der Stelle kann irgendwas nannen werden oder so.

Das ist meistens sowas.

Und das, wenn man ein bisschen drüber nachdenkt, dann ist es klar, dass das auch so tatsächlich so sein kann.

Aber mir war das vorher gar nicht klar.

Den Fall habe ich, ich dachte, das kann überhaupt nicht passieren.

Und so, ach doch, kann doch passieren, ja.

Und dann habe ich tatsächlich eigentlich im Grunde einen Fall übersehen und auch, da wären Bug gewesen eigentlich.

Aber sowas, also ich glaube auch.

Also die meisten Bugs, die ich irgendwann entdecke, sind wirklich viele Type-Bugs irgendwann.

Ja, nee, also viele sind es nicht gewesen, ein paar waren es.

Also ich hab zum Beispiel, kennt ihr Entfern of Code, ja, ne?

Also Entfern of Code ist so ein tolles Spiel, was man in einem Adventszeit spielen kann, wo man halt so Coding-Rätsel macht, ganz süß immer gemacht.

Dieser ist ein U-Boot.

Und auch da, also ganz einfache Aufgabe, erste Aufgabe iterieren über so ein Array vergleichen.

Es gibt einen unheimlich großen Unterschied, ob man halt den Typ, das ist eigentlich nur eine Liste, also in der Datei von Zahlen, ob man da ein Int drauf castet oder halt nicht.

Weil halt der Vergleich, den man machen muss zwischen Zahlen, halt ein anderes Ergebnis hat.

Aber nur an zwei Punkten.

Das heißt, man kommt am Ende irgendwie auf 1300 Treffer und dann kommt man auf 1301-Treffer, wenn man halt den Typ ändert oder sowas und das ist halt nur eine Sache richtig.

Und das halt zu finden, dass man halt überhaupt so einen Bug hat, wenn halt das meistens stimmt, ja, also 1299 Fällen ist das richtige Ergebnis da.

Das geht halt nur wirklich, wenn man tatsächlich weiß, warum und welche Typen man da hat und wenn man das irgendwie sicherstellen kann.

Und das geht halt mit Typons ganz gut, weil du weißt halt, oh, da muss halt ein Int rein oder so.

Und wenn man das vergisst, dann funktioniert das halt nicht.

Und das ist mir auch erst klar geworden, als ich jetzt zum Beispiel Lösung auch in Russ oder in Go geschrieben habe, weil dann klar ist, welchen Typ er hat und weil es halt immer das falsche Anzeigt, wenn man halt den Typen nicht konvertiert hat.

Ist aber auch, glaube ich, auch eine super Sache, wenn man so interne APs hat, also entweder wenn man irgendwie so zentrale Funktionalität hat, die irgendwo liegt, oder Sachen, die jetzt von vielen verschiedenen Seiten irgendwie verwendet wird oder von vielen verschiedenen Entwicklern, gehe ich inzwischen ja auch immer hin und versuche die so weit wie möglich zu typisieren in Python.

Einfach, dass dann, dass der nächste Entwickler, auch wenn ich das bin, einfach weiß, okay, da kommt jetzt, weiß ich nicht, vielleicht ein Nun raus oder eine Liste oder ist das ein Dictionary.

Weil das sind halt wirklich so Sachen, meistens findet man es, bevor es wirklich auf Production geht.

Aber selbst dann sucht man nochmal irgendwie fünf oder zehn Minuten, wenn man nochmal denkt, hey, ich hab doch einen Baum, was soll das denn?

Und wenn dann da die Idee dann direkt anzeigt, nee, nee, du kannst, du machst die Äpfel mit Birnen, das ist einfach super praktisch.

Und umso tiefer das bei mir drin ist, umso mehr versuche ich auch dann wirklich die Type-ins zu machen.

Ja, mit dem Nunn ist halt echt ein Problem, ne?

Aber ja, das fällt mir auch gerade noch so eine Anekdote zu ein.

Da gibt's, da gibt es noch ein Buch, JavaScript The Good Parts, glaube ich, auch relativ bekanntes Buch.

Das muss halt dünn sein.

Das ist tatsächlich relativ dünn.

Da gibt es auch diesen Witz mit dem dicken Buch, genau.

Die Reference, es ist irgendwie tausend Seiten und dann irgendwie Good Parts ist halt irgendwie so ein Heftchen, ja.

Das stimmt.

Und der Autor davon, ich glaube, das ist David Crockford oder ich weiß nicht genau, der ist auch in diesen Standardisierungsgremien drin und so und der schrieb dann halt auch irgendwo, weiß gar nicht, meinte so, naja, also irgendwie diese, diese, ist eigentlich kein Wert oder ist irgendwie nix, Dinger sind ein Problem bei Sprachen, ja.

Also Python halt nun, da gibt es halt ein Ding.

Und es ist halt immer wieder in diesem, wenn man sich über so Standardisierungsfragen ist halt irgendwie die Frage, ist das eine gute Idee, sowas in der Sprache zu haben oder nicht, zum Beispiel SQL, ja, ist ja auch Null ist für einen Großteil der wirklich hässlichen Sachen im Sprachstandard und auch für viele Bugs in Datenbankimplementationen, die dann halt auch irgendwie und für viele Inkompatibilitäten in den Standards und so, also Null spielt ja eine große Rolle.

Wenn man jetzt nicht so ein harmloses Ding wie Null, das kann ja nicht so viel kaputt machen.

Das Ding macht irgendwie dauernd und seit Jahrzehnten und konsistent irgendwie ganz viel Probleme.

Und ja, er meinte halt so, ja, also es ist immer so, unter Leuten, die sich mit Sprachdesign beschäftigen, die Frage, also will man sowas in einer Sprache haben oder nicht?

Und dann gibt es immer so einen Teil der Leute, die sagen, ja, ach doch, ist eigentlich schon gut, wenn man das hat.

Der andere Teil sagt, nee.

Aber niemand, absolut niemand vertritt die Ansicht, es ist voll gut, zwei davon in einer Sprache zu haben.

Und da hat halt zwei, ja.

Das hat man null und undefined.

Und das ist halt wirklich, ah, ja, das ist halt irgendwie so.

Ja, und das macht Dinge wirklich komplizierter, aber das Problem ist jetzt auch die Type-Annotationen selber machen Sachen natürlich auch komplizierter.

Ja, zum Beispiel auch sekuläre Import oder sowas, das ist ja ein bisschen nervig.

Nee, die Annotationen, also.

Achso, ach du, gut, okay, klar, da kannst du auf das Problem natürlich auch stoßen, ja klar.

Oder leichter.

Aber ich meine, wenn das, wenn das jetzt eben, also entweder man macht halt, wenn man jetzt die Typen annotiert und man macht es jetzt so quasi einfach, man muss halt dann auch seinen Stil ändern.

Wenn die Typen-Annotationen einfach bleiben sollen, dann muss man halt irgendwie das auf so relativ primitive Datentypen runterbrechen und kann dann eigentlich auch nur noch so richtig so relativ primitive Datentypen verwenden.

Ja, man will ja eigentlich schon komplexere Daten, also so auf ein Patentik-Objekt oder sowas hinten.

Ja, ja gut, okay, also Patentik ist nochmal, aber das Problem dabei ist halt, also wenn man das macht, dann hat man halt im Grunde kommt man dann irgendwie so, und wenn das Typsystem relativ einfach ist, was man so verwendet, dann kommt man halt bei einem Dialekt von Java raus, der halt super langsam ist.

Was halt, und sieht überhaupt nicht mehr aus wie Python eigentlich im Grunde genommen.

Das ist halt irgendwie doof.

Aber wenn man jetzt Python idiomatisch schreibt, so Pythonisch irgendwie, dann wird das mit den Typen-Annotationen ziemlich schwierig, ne?

Also weil zum Beispiel so eine, das gab es letztens auch eine Podcast-Episode mit Luciano Ramaglio, der hat früher in Python geschrieben, das Buch.

Auch kann ich nur empfehlen.

Gibt es jetzt, äh, früher kommt eine zweite Ausgabe, zweite Edition, Second Edition, wo er auch viel über Type-Annotationen und so schreibt.

Und der sagt halt so, ja, also der hat in der hat sich das auch dann halt mal so richtig angeguckt und so und hat dann die Typ-Annotation für die Max-Funktionen sich angeguckt.

Und das Problem bei Typ-Annotationen ist jetzt auch, die können jetzt auch, die können ja auch falsch sein.

Die können ja richtig sein, falsch sein.

Die können uns False-Positives geben.

Es kann sein, dass etwas dem Typ zwar entspricht, aber tatsächlich ist es inkompatibel und innen knallt es irgendwo.

Das sollte natürlich nicht passieren.

Typ-Annotationen sollten so sein, dass es keine False-Positives und keine False-Negatives gibt.

Also auch keine, das ist halt das, was mir immer passiert, wenn ich versuche, das hinzuschreiben.

Ich habe halt ganz oft False Negatives.

Das heißt, mir sagt irgendwie MyPi oder so, da hast du was falsch gemacht, und ich hätte gesagt, nee, das ist eigentlich nicht falsch, das ist eigentlich schon richtig, aber ich hab's irgendwie falsch hingeschrieben.

Und bei einer Funktion wie Max ist das halt extrem schwierig und hat er halt in den Type-Annotationen dafür halt Fehler gefunden, eben False Positives, False Negatives.

Und dann hat er versucht, das richtig zu machen.

Also es gibt irgendwo Type-Chat oder so, da steht die Annotation für Max drin.

Und das wurde dann richtig, richtig gemein, weil Max ist halt auch so eine komische, also es gibt so diverse Funktionen, so Max-LAN und so, die halt schön sind irgendwie, weil du kannst halt, es ist eine sehr generische Funktion, du kannst ja alles reinwerfen und es macht eigentlich immer das Richtige.

Aber das jetzt zu annotieren, ist halt die Hölle.

Also er hat dann irgendwie so, naja, also die eigentliche Implementation von Max sind halt irgendwie so 25 Zeilen oder so.

Und allein die Typ-Annotationen waren hinterher, du musstest halt sechs sechs Overloads dafür irgendwie definieren der Funktion und es waren viel, viel mehr Zeilen in den Typdefinitionen, als hinterher in der Implementation.

Und dann ist natürlich die Frage, und es war sehr schwer zu verstehen und also irgendwie diverse subtile Fehler drin.

Also dann ist ja halt die Frage, okay, wenn das so schwierig ist, die Typen hinzuschreiben, ja, macht das dann, ist dieses Verhältnis zwischen, und es ist halt komplett, ist auch sehr schwer zu lesen, ja.

Also es ist halt die Frage, ja, ist das dann wert noch, ja?

Und ja, das ist halt so die, das ist halt so die Frage, ne?

Und da gibt es genauso, weil das war auch aus dem Podcast hat, da hat er, ähm, meinte er so, es gibt dann so auch ein Buch zu Java, auch ich habe vergessen welches das ist, auf jeden Fall auch einer der, ist auch einer, der in der Sprache mitgearbeitet hat oder so, der schrieb dann halt zu, als die Generics eingeführt worden, selber sagt er dazu, also die Generics waren ein Desaster in Java.

Und es gibt diverse Geschichte, Konstrukte, die sie da gemacht haben, wo es dann, wo sie dann gesagt haben, so, okay, wir haben das jetzt irgendwelchen Professoren, die sich mit Typtheorie beschäftigen, gezeigt.

Und die sagen, das stimmt.

Aber wir können das nicht bestätigen oder weil wir verstehen nicht, was das macht.

Und das ist dann halt einfach so, ja gut, wozu macht man es dann jetzt?

Wenn man es nicht mal verstehen kann.

Ja, schwierig.

Und also was man da sieht, ist halt, das Problem ist, dass die Sprache ist halt, also bei Python ist es halt auch so, die Sprache ist halt expressiver als die Sprache, die man verwendet, um die Typ-Annotation zu machen.

Und das hat ja schon in diversen Sprachen zu Katastrophen führt.

Also bei C<unk> mit den Templates, ja, ganz furchtbar als ein Turing vollständig.

Irgendwie, wenn man davon genug verwendet, versteht man auch nicht mehr, was da los ist.

Der Compiler braucht ewig lange viel Hauptspeicher und schrecklich.

Java, Generics, ganz furchtbar.

Wie macht man das so?

Zum Beispiel mit einem JSON-Objekt, wie würde ich das type monentieren?

Das ist so ein bisschen.

Genau, das kann man.

Das kann man tatsächlich.

Also ich beschäftige mich ja gerade auch so ein bisschen mit TypeScript und da gibt das, also da kannst du, du kannst tatsächlich solche Sachen machen wieder.

Rekursive definieren.

Du kannst rekursive Typdefinitionen machen, wenn es geht.

Ja, das kann gut sein, dass es ein Python nicht geht.

Also die Type-Definition für einen JSON, wo dann hinterher der TypeScript, der TypeScript-Compiler, auf die Finger haut, wenn du da auch beliebig rekursiv irgendwo etwas reinschreibst, was jetzt nicht mehr World is JSON wäre, so wo du den rote Kringel kriegst, das sind so 25 Zeilen, rekursive Type ohne Notation in TypeScript.

Das geht.

Und das ist natürlich schon sehr cool, dass das geht.

Auf der anderen Seite, ich bin, ich beschäftige mich jetzt seit einer Zeit damit, also ich kann diese 25 Zeilen sehen, ehrlich gesagt, ich verstehe sie nicht so ganz.

Das ist halt auch wirklich, wirklich schwierig.

Ja, da können ja halt rekursiv irgendwelche Dinge drin, irgendwelche Listen drin liegen und irgendwelche Dicks drin liegen, irgendwelche Listen drin liegen, wo vielleicht noch ein Swing ist und irgendwie null oder irgendwas.

Es ist halt

wieder eine Sprache für sich, also allein schon, dass du in Types, dass du halt sagst, okay, du kannst, es gibt ja eben diese Generics, also sag ich mal, es ist auswärtig, du kannst halt nicht nur, du definierst die Typen nicht fix, sondern du sagst halt, also du kannst jetzt, wenn er in der Funktion sagen, welchen Typ du zurückerwartest und denen dann als Typ-Annotation verwenden.

Du kannst also sozusagen einen Typen parametrisieren, die du irgendwo setzt.

Du kannst eine generische Funktion haben und dann sagen, während du sie aufrufst, im Aufruf kannst du dir sagen, und die gibt jetzt das und das zurück.

Und dann kann der Compiler das überprüfen, dass das stimmt.

Und das kannst du dann auch noch rekursiv machen.

Und das kannst du dann mit beliebig verschachtelten Sachen machen.

Sollte ich das vielleicht ein bisschen refactoren?

Naja, also es wird halt, ich meine, es ist schon cool.

Auf der einen Seite finde ich es super cool, dass es geht, auf der anderen Seite denken wir so, mein Gott, was haben wir getan?

Das wird mein Monster erschaffen.

Aber ja, es ist.

Also, ist das eine Mode?

Also ich habe auch das relativ oft benutzt, ich benutze das auch gerne und ich versuche auch das relativ vollständig so zu benutzen.

Aber halt, ja, es hat halt irgendwie seine Grenzen auch.

Also manchmal nutze ich es halt einfach nicht, weil es einfach keinen Sinn macht.

Also für so ein Int oder String, okay, weil das nur komplexe Objekte.

Ja, bei komplexeren Sachen wird es halt dann sofort ziemlich schwierig.

Also eine Geschichte, die wohl cool ist, ist halt Protocols, damit kann man halt, also Typing.

Protocols mit Python 38, glaube ich, dazu bekommen, damit kann man dann viele der Probleme, die man sonst hat, irgendwie gehen dann weg, weil man dann sagen kann, okay, ich erwarte hier nur ein Ding, das.

Also Protocols sind immer so keine Sachen, wo du eine Methode hast oder vielleicht zwei oder so.

Und dann musst du halt nur diese Methoden implementieren.

Du kannst halt überprüfen, ob das so ist, ob das konform ist.

Und dann fällt ein Großteil der Schmerzen weg.

Aber also wirklich, ja, also.

Also wenn das zu komplex wird, vielleicht muss man dann reflection, dass man einfache Dinge macht, wie zum Beispiel nach Strings realisieren oder sowas.

Nee, nee, aber das Problem ist ja, also das willst du ja eigentlich vielleicht nicht.

Du willst ja vielleicht sowas, so generische Funktionen haben wie Max oder so.

Aber die kannst du praktisch nicht mehr gut annoten, also außer du machst es halt, es ist halt schwierig, die zu adoptieren.

Wir müssen es ja nicht in Python, ne?

Von daher vielleicht.

Ja, genau.

Und vielleicht ist es für die Fälle, das ist auch dann nicht typisieren, sondern sagen, okay, wir machen es an den Stellen, wo es halt was bringt und nicht so genau ist.

Und dann an den Stellen, wo es halt nicht gut geht, dann lassen wir es halt weg und dann schreiben wir halt eine generische Funktion, die halt.

Magic Python, wenn man magie.

Genau, ja, das ist vielleicht irgendwie so der richtige Weg.

Das haben wir hinterher zu Tyson.

Ja.

Eine Sache, die mir noch aufgefallen ist, jetzt in den letzten Monaten beim Arbeiten bezüglich Refactoring, ist, es geht auch so ein bisschen Richtung Modularisierung, aber mehr Richtung die Semantik, denn wirklich die Sachen physisch irgendwie zu trennen.

Und das ist, wenn man relativ viel, also jetzt in meinem Beispiel relativ viel Business-Logik hat.

Also wenn man meistens fängt, also wenn man agil arbeitet, fängt so ein System mit MVP an, also sprich, man hat, weiß ich nicht, irgendeinen Onlineshop, da kann irgendwas kaufen, dann kriegt er vielleicht eine E-Mail, da gibt es irgendwie eine Bestellung und das war es im Endeffekt.

Und dann kommt vielleicht noch ein anderer Fall dazu, noch ein Fall und noch ein Fall und irgendwann wird ein neuer Geschäftsbereich dazu gebaut und irgendwann hat man halt dann da ein riesiges Konstrukt von irgendwie E-Mails, die hin und zurück geschickt werden und irgendwelche Order-Objekte in der Datenbank, die riesig werden, wo 100.000 Felder drin sind.

Und das eigentliche Problem ist, dass dann an einem gewissen Punkt, und das habe ich jetzt schon mehrfach gesehen, weder der Kunde noch die Entwickler eigentlich noch genau wissen, was eigentlich der Geschäftsprozess ist.

Das System macht zwar ungefähr das, aber dann kommt plötzlich irgendwann mal ein Fehler.

Dann schickt nämlich eine E-Mail und irgendein Falsches geschickt, und dann stehen die Leute dann da und sagen, ja, was passiert da eigentlich genau?

Und das finde ich ein total interessantes, interessanten Refactoring-Ansatz, weil das halt nicht so, also keine Ahnung, wenn ich jetzt irgendwie merke, okay, das ist irgendwie schlechtes Pattern oder keine Ahnung, das ist nicht, das ist nicht lintkonform oder keine Ahnung was.

Dann geht man hin und Refactor Zeit, weil das schreit einen quasi an, das ist das Hässliche, was du meintest.

Das ist ein Code Review, wenn man relativ sehen kann, wie gesagt, Kommentare stimmen nicht oder Docs sind falsch oder es sieht hässlich aus, ist zu lang, man kann es so ein bisschen umbauen, Naming sind komisch, dann kann man das mehr machen.

Genau, aber so eine Sache, wenn man sagt, okay, ich habe jetzt da dieses Konstrukt und es ist auch alles vielleicht auch gar nicht so schlecht an sich für den Pattern.

Also man hat das vielleicht alles in Klassen drin und Services und du hast auch irgendwie Models gebaut, wo das auch alles irgendwie die Datenschutzprogramm ist.

Interessant ist man noch Services, da müssen wir auch nochmal drüber reden, was das eigentlich ist.

Aber wenn halt irgendwann dieser ganze Business-Prozess halt nicht mehr offensichtlich ist, da muss man dann einfach diese Art von Abstraktion, einfach eine neue Art von Abstraktion finden.

Und da ist eine sehr interessante Sache, mit der wir uns jetzt beschäftigt haben, sind halt die Finite State Machines.

Dazu gibt es auch einen sehr coolen Vortrag von 2019.

Ich habe vergessen von wem, aber da gibt es Django FSM.

Das Problem ist, das Package ist leider deprecated und die neue Version ist noch in Alpha.

Also man kann die schon nutzen, aber die Doku hat Lücken.

Wen es interessiert, wir haben beim letzten Django Meetup in Köln länger drüber gesprochen.

Das ist bei YouTube.

Vielleicht nochmal ganz kurz dann erklären, was ist denn eine finite State-Maschine?

Also, Finite State-Machine ist im Endeffekt relativ simpel, dass man sagt, ich habe ein Objekt und dieses Objekt kann in verschiedenen Status sein.

Also sprich, ich habe einen Auftrag, der kann neu offen sein, der kann in Bearbeitung sein, der kann in Lieferung sein, der kann abgeschlossen sein, der kann bezahlt sein.

Und dass es eine endliche Menge von Wegen gibt, wie ich von jedem Status, also nicht von jedem, zu jedem, aber wie ich von einem Status zum anderen komme.

Da kann man sich im Endeffekt einfach wie ein Graph mit Pfeilen, also Kringeln und Pfeilen vorstellen.

Und man hat halt im Endeffekt fix definiert, also erstmal auf dem grafischen Level, dass ich zum Beispiel von, ich komme, ich kann nicht von offen direkt nach geschlossen kommen, weil davor muss es erstmal irgendwie bearbeitet, bezahlt und geliefert werden.

Ja, oder so, das geht halt sonst nicht, also könnte man sich jetzt vorstellen, ja.

Und der Vorteil an diesen, also das ist nur eine von vielen Möglichkeiten, um so mit sowas anzugehen.

Und wir haben das jetzt halt ausprobiert und es hat halt wirklich, wirklich gut funktioniert.

Weil das Schöne ist, diese Graphen sind sehr, also die werden natürlich auch immer komplexer, wenn man halt sehr viel Business-Logik hat, aber trotzdem, die versteht halt wirklich jeder.

Also der kompletter Non-Tech, die kannst du das auf den Tisch legen und der weiß sofort, um was es geht.

Und das Schöne ist halt, das geht mit der neuen Version, glaube ich, nicht, mit der alten Version, wenn man diese Flows implementiert in Django, mit diesem Package, dann konnte man sich die Graphen auch rausrendern lassen.

Also sprich, die Business-Logik, die man einerseits für S-Entwickler sinnvoll ablegen kann, weil man halt auf einmal nicht mehr überall irgendwo langwurscht und irgendwie in jedem Service irgendwas irgendwie ein bisschen anders macht, je nachdem aus welcher Ära vom Projekt das dann halt gebaut wurde.

Sondern man sagt, okay, ich habe ein Flow und hier definiere ich jetzt genau, was passiert, wenn Aufdruck von offenen Bearbeitung geht.

Zum Beispiel, da geht eine E-Mail raus oder da geht keine E-Mail raus oder da muss jemand irgendwas machen damit, ja, und welche Variablen gesetzt werden.

Und erstens ist es halt im Code sauber gekapselt und die alte Version konnte, wie gesagt, direkt die Graphen rausrennen.

Das heißt, wenn man ein Hinrechtkomplexe Business-Modell implementiert hat und dann kommt der Kunde und sagt, ich würde da gerne was dran ändern, dann kann man im Endeffekt auf den Knopf drücken, kriegt da ein wunderbares PDF raus, kann darüber dann im Kunden reden und sagen, okay, welche Pfeile sollen wir jetzt umbiegen und wo soll was anders passieren.

Und das ist halt, also das ist halt wirklich auf einer ganz anderen Ebene.

Und das ist halt so trivial.

Also ich bin eher schockiert, dass mir sowas noch nicht, also dass ich da so spät im Endeffekt drüber gestolpert bin über solche Sachen.

Ich glaube, was eigentlich schwierig ist, ist tatsächlich, diese Dinge aufzumalen, weil ich glaube, selbst die Kunden kennen nicht immer ihren Flowchart oder wie man.

Genau.

Weil die halt nicht wissen, was passiert denn da.

Und bevor sich das sich jemand angeguckt hat und vielleicht mal das in der Realität getestet hat, oh, da ist aber noch ein Problem, dann tauchen diese einzelnen Ereignispunkte oder auch die States, die irgendwas haben kann, gar nicht auf.

Und das bei uns hat das so einen ganz bösen Bug geführt.

Ja, die Tests waren eigentlich ganz gut.

Also die haben eigentlich das getestet, was getestet werden soll, dass das Carbage war hoch der Code, aber es gab halt den Fall einfach nicht.

Und das führte halt einfach dazu, dass fälschlicherweise, beispielsweise, wir haben so CMN-Quatsch gemacht, an ein paar hundert Vertriebler einfach so E-Mails rauskriegen, die gar nicht rausgehen sollten oder so.

Oder zu oft.

Und so ist es halt so ein bisschen so ein, okay, ähm, ups.

Und das Böses schreit halt dann, weil denkt sich halt so, nein, wir können den nur und total doof und das macht ja gar nicht das, was sollen, alles falsch.

Aber eigentlich ist es halt nur der Fall, dass man halt nicht bedacht hat, dass es einen besonderen Fall geben kann, der halt nicht abgebildet wird.

Genau, aber das Schöne ist halt, wenn man halt mit solchen Tools vielleicht auch direkt konzeptionell, also auch im Agilen, einfach mal, wenn man, wenn man die Tickets überarbeitet, sagt, hey, wir haben hier dieses Modell und wir arbeiten immer an diesem Modell, dann kann man halt vielleicht über solche Sachen auch schon viel früher stolpern, weil der Kunde dann plötzlich merkt, so, ja Moment mal, oder wenn der Kunde es an seinen Stakeholdern zeigt, oder der Broad-Owning-Stakeholdern zeigt, dann sagt vielleicht, ja Moment mal, aber ich arbeite doch die ganze Zeit an einem Pfeil, den es ja gar nicht gibt, da stimmt doch was nicht.

Weil wenn das halt implementiert ist, dann ist es halt für die Non-Techs halt quasi weg.

Das ist dann nicht mehr einsehbar.

Und als Entwickler natürlich sollte man das grob verstehen, wie du halt gesagt hast, das System ab einem gewissen hinreichender Komplexität ist es halt vorbei.

Dann kann man nicht mehr alles verstehen.

Dann sind die Sachen hoffentlich irgendwie gekapselt und dann will man auch gar nicht mehr wissen, was da hinten passiert.

Vielleicht muss ich das wissen für meine Sache, weil es irgendwas gibt, was halt noch keiner weiß.

Vielleicht nochmal zur Definition, finite State Machine.

Ja, genau, also einen endlichen Automaten kann man quasi auf alles dann abbilden.

Was ja mit unendlichen Automaten geht, so war es auch.

Du kannst damit nicht alles machen.

Also endliche Automaten zum Beispiel, also etwas, was quasi äquivalent ist, sind reguläre Ausdrücke.

Das ist halt auch eigentlich, wobei regulärer Ausdrücke, je nach Implementation, da gibt es auch noch ein bisschen mehr, was man aber machen kann, aber das ist halt, ja, also wenn man endlich ein Automat hat, die Sprachen, die, also jetzt theoretische Informatik, vielleicht hoffentlich richtig nicht allzu großen Unsinn, das ist alles schon sehr lange her, aber im Grunde, wenn du endlich einen Automaten hast, dann sind die Sprachen, die von denen akzeptiert werden, heißen regulär und deswegen auch reguläre Ausdrücke, weil

es halt Ausdrücke sind, mit denen du reguläre Sprachen parsen kannst, halt.

Aber du kannst damit nicht alles machen.

Zum Beispiel, was du damit nicht machen kannst, sind halt so, also das, das ist immer so Informatik 1 oder bei mir war das, glaube ich, tatsächlich Informatik-1-Klausur.

Musst du dann beweisen, dass eine bestimmte Sprache nicht mit einem endlichen Automaten passbar ist.

Normalerweise nimmt man dann irgendwas, wo so Klammer gibt.

Du hast dann eine Sprache, die halt so Klammern hat.

Wo halt, ob du hinten eine Klammer zumachst, davon abhängt, ob du die vorne aufgemacht hast.

Und dann gibt es dann so ein Pumpkin-Lebern, heißt das.

Das kann man dann benutzen, um zu zeigen, dass das halt, dass man keinem endlichen Automaten das parsen kann, weil man sich nicht merken kann, quasi sozusagen, wie das.

Dafür braucht man dann halt so einen Stackautomaten oder irgendwie sowas.

Stackautomat ist, also wie gesagt, ich bin keine Twitch-Informatik kenne.

Was ist ein Stackautomat?

Ja, so ein Ding, was halt einen Speicher hat.

Also einfach nur tatsächlich ein Stapel, den es gibt.

Okay.

Warum ist das Ding Automat?

Ja, ich weiß gar nicht, Methoden im Kind.

Ich weiß es nicht genau, ich weiß gar nicht, ob das Automat heißt.

Und also alles, was halt dann ein unendlicher Automat quasi ist, das hat halt dann States, die du vorher nicht kennst oder sowas?

Oder worum geht es da?

Dass du das nicht vorher wegdefinieren kannst.

Nein, du musst dir halt sozusagen merken, was passiert ist.

Das kannst du im eigentlichen Automaten nicht machen.

Da hast du halt Zustände, die sind endlich und du kannst zwischen denen wechseln, aber du kannst ja jetzt nicht merken, wo du schon über langgelaufen bist oder so.

Oder ob du Klebern aufgemacht hast oder nicht.

Das geht halt nicht.

Und genau, das nächste, also wir gehen wir mal die Dinger durch bei der theoretischen Formatik.

Das zweite ist halt dann sozusagen Stackmaschinen.

Damit kannst du halt dann kontextfreie Grammatiken parsen und dann gibt es halt noch kontextsensitiv.

Dafür brauchst du dann schon Loop-Rechenbar oder sowas und dann irgendwie gibt es noch irgendwie alles irgendwie.

Und dafür brauchst du dann Turing-Maschinen.

Oder halt ein Weilprogramm oder ein Vorprogramm oder was auch noch.

Okay, also nochmal vielleicht zum Abschließen, was eine Turing-Maschine ist.

Oh Gott, eine Turing-Maschine.

Eine 7-Tuppel aus, Sprache, Grammatik, irgendwie, Terminal-Symbolen, Nicht-Terminal-Symbolen, keine Ahnung, weiß ich nicht.

Alphabet, ja, also im Grunde das Ding, was halt sozusagen die Informatik als Fach irgendwie so ein bisschen begründet hat damals.

1937.

Ich glaube, es ist das Paper, glaube ich.

Von Neumann-Architektur, oder was?

Nein, nein, nein.

Nein, nein, nein, du hast eins anderes.

Das ist auch SCP.

Was ist das?

Von Neumann-Architektur ist das halt Hauptspeicher, also dass der Speicher für Daten und Programme dergleich ist.

Mehr oder weniger.

Aber das ist halt eine Rechnerarchitektur, aber das ist halt Hardware.

Turing-Maschine ist ein theoretisches Konstrukt.

Wie gesagt, das hat Turing da 1937 veröffentlicht.

Ich glaube, das Paper hieß On Computable Numbers with an application to the Entscheidungsproblem oder sowas.

Und da hat er das Ding halt vorgestellt und in dem Paper bewiesen, dass das halte Problem nicht entscheidbar ist.

Also, ja, und genau, das hat eigentlich die Informatik begründet, weil so, also, beziehungsweise es gibt da halt noch irgendwie ein Paper zu Lambda-Kalkulus von Church, das ist ein bisschen später rausgekommen, ist eigentlich ein Stückchen eleganter, aber ja.

Ja, aber genau, also das Typ 0 Sprachen, also du kannst mit einer Turing-Maschine kannst du halt alles parsen, was du auch parsen kannst.

Und mit einem regulären, also mit einem regulären Automaten, also mit einem endlichen Automaten halt nicht, sondern nur ganz spezielle Sachen.

Aber trotzdem kannst du wahrscheinlich eine Menge damit abbilden, ja.

Ich meine, so ist nicht.

Ja, vor allem in meinem Case ging es ja wirklich auch um tatsächlich um Business Flows.

Ja.

Und das glaube ich das Interessante halt an Business Flows ist, weil das halt wirklich eine Sache ist, man muss ja dann im Endeffekt die gelebte Realität von dem Kunden oder von demjenigen, für den man das baut, muss man ja halt wirklich eins zu eins spiegeln, ohne dass man wirklich genau weiß, was die da eigentlich tun.

Also wenn man jetzt, wenn man, keine Ahnung, wenn es jetzt darum geht, verschicke E-Mails, dann ist das Ergebnis wichtig.

Aber bei den Geschäftslogik, beim Geschäftsmodell, muss man tatsächlich das nachbauen.

Also da kommt irgendwas daher, da werden irgendwie Daten reingegeben, dann wird mit den Daten irgendwas gemacht, dann wandert das irgendwo weiterhin.

Und das ist, glaube ich, so der spannende Punkt, warum da halt zum Beispiel, ich meine, es gibt doch bestimmt noch 50 andere schlaue Ideen, wie man halt umgehen kann, aber halt damit mit diesen endlichen Automaten halt schon mehr Struktur reinbringen kann.

Ich glaube, wenn man das halt auch von Anfang an sich für irgendwas entscheidet und nicht halt sagt, wir machen das halt, wie ich halt in ganz normalen Code programmieren würde, glaube ich, da kann man sich sehr viel knarcher sparen und hat bestimmt zwei, drei Jahre Entwicklungszeit, Entspannung vom, also quasi ein bisschen Schutz vor tiefgreifendem Refactoring.

Ja, klar, also es ist.

Also um Refactoring zu vermeiden.

Aber das wäre jetzt aber auch nur Refactoring vermeiden, was quasi Bugs entfernt und die Features sicherer macht.

Aber das wäre jetzt nicht das Refactoring, was keinen Style schöner macht, Namenskonventionen besser einhält, dokumentierbarer macht.

Ja, okay, stimmt.

Das ist natürlich auch eine Art von Refactoring.

Ja, man kann auch quasi irgendwas, also wenn man das übergibt, also wenn ich jetzt selber was geschrieben habe, was ich mich gut mit auskenne, ist es ja was anderes, was wenn jetzt jemand anders das gut benutzen muss.

Und wenn man halt seinen Cook, glaube ich, in einen Zustand versetzt, in der der halt irgendwie auch gut übergebbar ist, dass halt jeder damit arbeiten kann.

Wobei man da ein bisschen vorsichtig sein muss.

Ich meine, ich falle, da geht es ja dann quasi um, würde ich mal sagen, Konsistenz.

Und da ist leider, also meine persönliche Ansicht dazu ist, konsistent ist es dann so, ist es dann, wenn es mir gefällt.

Okay, Taste kann man nicht schreiten.

Aber das Problem ist halt, das habe ich gerade sagen.

Ja, aber wenn man so in Codebasen guckt, die es da so gibt und sich denkt so, oh, das ist alles ganz schrecklich, dann habe ich so den, dann so zuerst fängt das Augenlied an zu zucken und dann irgendwann lasse ich Black über alles drüber laufen.

Ich kenne das aber auch von Joch, das ist immer ganz gut.

Also er hat ja netterweise ein paar Sachen von mir mal korrigiert und so.

Und ganz mal anfangen, was sagt denn da?

Das geht ja überhaupt nicht, alles wegschmeißen, neu machen.

Nee, nee, nee kann man nichts trennen.

Und dann habe ich die wieder angefangen neu gemacht und das ging dann so ein paar Mal so, ah, wegschmeißen, neu machen, nein.

Und dann irgendwann hat er gesagt, ah, was ist denn das?

Das hat das alles wieder neu machen, weg.

Ja, das habe ich von dir kopiert.

Ja, das mag sein, dass es ja ich meine, manchmal ist es auch alleine einfach Quatsch.

Man hat man sich so daran gewöhnt, dass irgendwie und dann macht man hinterher irgendwas dann falsch, wenn man davon ausgeht, dass es sowieso irgendwie nicht richtig ist.

Also man muss aufpassen, es ist nicht so einfach.

Aber genau, also ja, also ich tendiere dazu, das dann so zu machen.

Ich glaube aber, es ist falsch.

Also ich glaube, es ist, und eben auch da dieses, das Buch würde sagen, ah, Konsistenz wichtiger, weil es halt für Leute wichtiger ist, das zu verstehen und dass es genauso ist, wie sie das halt kennen, als dass es richtig ist.

Weil richtig ist halt kein guter Wert quasi oder es senkt halt nicht die Komplexität.

Also es kommt drauf an.

Also ich meine, es gibt natürlich Situationen, in denen es ist so schlimm, da muss man halt was machen.

Aber wenn es jetzt sozusagen nur unschön ist, aber halt in sich konsistent, dann ist es wahrscheinlich besser, das so zu lassen, weil es senkt halt nicht, also die Konsistenz zu brechen, erhöht halt die Komplexität ganz sicher.

Während das anders zu machen, verringert die Komplexität vielleicht ein bisschen, aber wahrscheinlich gleicht das nicht das aus, dass man das dann halt inkonsistent gemacht hat und damit dann komplexer.

Also ja, es ist blöd.

Es ist ja generell auch ein Problem, dass wenn man jetzt ein altes, gewachsenes Projekt hat, das man dann vielleicht im schlimmsten Fall übernimmt, aber vielleicht auch, wo man halt auch schon selber lange dran arbeitet und irgendwann kommt dann jetzt der Impuls, wir müssen da jetzt mal irgendwie anfangen, Sachen besser zu machen, das geht so nicht mehr weiter.

Und da ist dann ja auch bei vielen motivierten Entwicklern, wie das bei mir früher auch so war, man geht hin und sagt, okay, machen wir irgendwie so gefühlt alles neu.

Und dann fängt man irgendwie sieben Baustellen an und das klappt halt einfach nicht.

Also ich glaube, die größte Kunst, wenn man wirklich so ein altes Projekt retten möchte, ist wirklich, sich zu überlegen, wie kriege ich die Patterns, die ich möchte, unter den Nebenbedingungen meines Projektes.

Ohne dass ich quasi alles anzünden muss und.

Oh oh, lieber die Finger vorlassen.

Also ich habe tatsächlich mal jahrelang auf einem wirklich komplett von der grünen Wiese gewachsenen Plain PHP-Projekt gearbeitet.

Das war halt einfach, das war vor und hinten eine Katastrophe.

Also die Codebasis war wirklich, wirklich schlimm.

Da gab es nie irgendjemanden, der drüber geguckt hat.

Das waren alles im Endeffekt alles von Freelancern gebaut, die, genau wie du es gerade gesagt hast, halt, die dafür bezahlt wurden, möglichst schnelle Feature abzuliefern und dann danach mit die Sintflut.

Böse, ich meine, nicht bei allen, aber es gab halt auf jeden Fall Leute und wenn du halt einen so im Team hast, dann ist halt schwierig.

Ich habe einen befreundet, einen Entwickler aus Malawi, der halt so versucht, günstige Aufträge ranzubekommen.

Und weil die Kunden, die er hat, dann halt ein relativ wenig Budget haben und immer ausgeben, merkt man halt auch, welche Entwickler sich halt dann leisten können.

Und wenn er halt dann so sieht, so die Leute, die von denen er das aufräumen muss, das wäre der selber nicht weiß, worum es geht, und die haben dann teilweise Pandas selbst implementiert, weil sie nicht wussten, was das dann gab und hat Sachen selber geschrieben und vorne auseinanderfallen, oder mich wie Spaghetti-Zeug und dann das dann neu zu machen.

Also die Arbeit, die hat, er ist die ganze Zeit am Limit und weiß überhaupt nicht, was da passiert ist.

Das ist so unheimlich schwierig, das besser zu machen und das zu refactoren.

Aber ich glaube, da ist dann gordische Knoten besser gelöst, indem man manchmal tatsächlich dann durchschneidet oder halt einfach verbrannte Erde und das neu anfängt oder so.

Also es gibt es auf jeden Fall.

Aber es ist ja leider bei zum Beispiel bei vielen Firmen, die so vor, weiß ich nicht, 10 Jahren, 15 Jahren angefangen haben und einfach ihr Geschäftsmittel irgendwie implementiert haben.

Da wurde ja die meisten, oder vor allem auch so Frühzeiten des Web, da sind ja einfach sehr, sehr viele schlimme Dinge passiert.

Da gab es so teils noch keine Frameworks, das waren Leute, die da nicht so richtig wussten, was die da tun.

Und das Problem ist aber, dass halt, weil halt auch da in der Firma dann nie jemand ist, der dann wirklich da versucht, das kontinuierlich besser zu machen.

Dann kommt halt irgendwann so, okay, es geht nicht mehr, ja, da weiß ich nicht, ein Formular anpassen dauert eine Woche, wir müssen irgendwas machen.

Und das ist halt dann, dass diese Firmen dann halt in so einem Deadlock sind, dass die halt nicht das Budget haben, diese riesige gewachsene Software mit 28.000 Sonderfällen neu implementieren zu können, aber es geht auch nicht weiter.

Und das ist halt genau der Fall.

Und ich glaube, das ist ein sehr, sehr häufiger Fall, insbesondere wenn das halt so eine Software ist, die halt wirklich in-house dann für sich selbst entwickelt wurde.

Dass man da, da ist super wichtig, dass man reflected.

Das ist super wichtig, dass man, also vor allem, ich finde in solchen Fällen das Einzige, was dann irgendwie motivieren kann, an diesem Projekt zu arbeiten, dass man halt versucht, die Herausforderung halt anzunehmen und das irgendwie besser zu machen kontinuierlich.

Und da ist es halt einfach super wichtig, dass man sich Patterns überlegt.

Also beispielsweise bei diesem alten Plain PHP-Ding, war halt auch, dass das einfach eine Kette von Skripten, die eingebunden wurden.

Eine n-lange Liste.

Niemand wusste genau, was da oben kommt und was unten kommt.

Du hattest keinen Variablen-Scope.

Also das kann man sich nicht vorstellen, was das für ein Segen ist, dass man einen Variablen-Scope hat, ja.

Und im Endeffekt habe ich dann, das war das, wo ich dann so mich am meisten darüber gefreut habe, dass es funktioniert hat.

Ich habe dann im Endeffekt Django Class-Based Views den Kleinen nachgebaut.

Und es war ein Segen.

Und es war im Endeffekt, das halt einmal zu bauen, also mir im Endeffekt grob abzugucken und dann halt ein bisschen fein zu schleifen, war ich in zwei, drei Tagen durch.

Das war jetzt echt nicht viel Arbeit.

Und jedes Mal, wenn ich halt an irgendeinem View dran war, also View in Gänsefüßchen, letztes Skript der Reihe, habe ich halt dann einfach, okay, jetzt stelle ich das einfach um.

Habe ich dann mit dem Kunden noch abgesprochen, das hat dann auch meistens nicht rasend viel, was meistens nur einsortieren war.

Ich habe gar nichts im Code wirklich gemacht.

Aber dadurch, dass man plötzlich Scope hatte, konnte auch die Idee plötzlich mit Variablen arbeiten.

Hat einem plötzlich zum Beispiel gesagt, ey, da ist ein ganzer, weiß ich nicht, 100 Zeilen, Zweig in diesem Dings.

Die Variable wird gar nicht gesetzt.

Die kommt nirgendwo her.

Dieses Gips, das kann man einfach rauswerfen, ja.

Also das war im Endeffekt mehr oder weniger eine Kleinigkeit und das war so ein Gewinn für dieses Projekt, weil wie gesagt, man wusste, was diese Views, man hat angefangen, man konnte, man wusste doch erstmal, wie ich überhaupt anfangen soll aufzuräumen, ja.

Ja, ist so unterschiedlich als die.

Ich habe auch da gehört.

Also es gibt Leute auf der Welt, programmieren unterschiedlich.

Zum Beispiel, ich habe jetzt vom Freund gehört, der mit Ukrainern relativ viel zu tun hat, also wirklich, die dann lange Jahre schon so Auftragsarbeit machen für europäische Kunden oder sowas und die sich jetzt halt wirklich auf dem internationalen Vergleich da irgendwie gucken, wie das Ganze aussieht.

Und da gibt es Firmen aus anderen Teilen der Welt, irgendwo aus Asien oder sowas, die entweder genug genau das machen, was sie aufgeschrieben haben und also halt nur genau Definition, das heißt, du brauchst ultra lange, wenn du mit dem Zusammenarbeit, um diese Definition aufzuschreiben, weil alles, was da nicht drinsteht, das wird halt nicht gemacht.

Das ist halt blöd, weil wir waren halt nicht bestimmte Dinge tun.

Oder die halt diese Abstraktionslevels nicht benutzen, also mit auch Firmen aus dem anderen asiatischen Raum, wo du halt dann da stehst und anstatt, dass du so ein Fettern jetzt halt hast und eine abstrakte Klasse dazu schreibst, werden halt alle 100 einzelne Möglichkeiten einzeln implementiert.

Und dann sagt, ja, kommen ja auch noch weitere, ja, 900 dazu, irgendwie vielleicht mehr Abstraktionsniveau sinnvoll.

Nun, die 900 machen wir dann auch ganz schnell.

So halt, das ist halt dann schwierig.

Also wenn man das halt dann refactort, dann ist es halt unheimlich viel Fleißarbeit auch dann, ne?

Wie man das irgendwie dann versucht.

So modular, auseinanderziehen.

Also ist Refactoren Auseinanderziehen oder Extraktion, ich weiß nicht.

Ich glaube, es sind halt viele Facetten, oder?

Ja, aber.

Ja, ich würde sagen eben, das ist halt, letztlich sollte es halt dazu führen, dass die Komplexität vom Gesamtsystem geringer wird.

Und wenn du halt, dann ist halt die Frage, was ist Komplexität eigentlich?

Ja, Don't Repeat your Self vielleicht auch, ja,

manchmal ist es.

Genau, eben, wenn du das halt so implementierst, ja, also nehmen wir diesen Fall, du hast halt nicht, du machst halt nicht eine generelle Lösung für irgendwas, sondern du hast halt dann 900 Spezialfälle, dann sieht das ja erstmal gar nicht so schlimm aus, aber tatsächlich, wenn du jetzt etwas hast, was all diese Fälle betrifft, quasi etwas, was du zum Beispiel immer tun musst, oder dann musst du die alle anfassen.

Das heißt, du hast eine Abhängigkeit zwischen allen, die nicht sichtbar ist.

Ja, also wenn du das sozusagen.

Explizit Methoden Implice, wir sind schon wieder bei Zen of Heist und können jetzt hier die Liste wieder runterbieten, ja,

was wir tun.

Das ist auch, das Beispiel hier in dem Buch ist sozusagen, wenn du eine Webseite mit ein paar tausend Seiten hast und du hast halt irgendwo einen Banner da drin, das halt eine Hintergrundfarbe hat und du hast sie jetzt halt einfach von Hand gesetzt in allen Seiten.

Du hast sie, dann hast du halt eine implizite Abhängigkeit zwischen allen Seiten, weil du kannst diese Farbe nicht mehr ändern, ohne alle anderen Sachen anzufassen.

Besser ist es halt nur eine Abhängigkeit zu haben zu einem Modul irgendwie, wo du diese Farbe setzen kannst.

Und dann hast du eine explizite Abhängigkeit, das heißt, du siehst auch, dass es die gibt und du kannst es an einer Stelle ändern und dann ist es halt für alle geändert.

Das wäre ein Refactoring quasi zum Schluss.

Aber gerade das, also es gibt ja so Sprachen, wo das nicht ging, zum Beispiel mit Variablen Sätzen oder sowas, also in HTML oder alten CSS oder sowas, waren Variablen ja nicht so einfach so setzen.

Gut, keine Ahnung, ich weiß aber auch noch nichts über CSS.

Ja, aber das war halt zum Beispiel dann ein Problem, wenn du quasi eine Variable, also eine Farbe gesetzt hattest auf eine Farbe, die es schon gab.

Von zwei verschiedenen Komponenten.

Weil wie willst du denn jetzt, also das sind wir weiß nicht, ein paar hundert Stellen, wo das auftaucht und die Farbe ist aber dieselbe, und wie kriegst du denn jetzt raus, was dann war jetzt vorher jetzt der Hintergrund 2, was war der Hintergrund 1 oder so?

Solche Dinge.

Das ist halt ziemlich hässlich.

Aber genau, also ja, das Buch sagt dazu quasi zu, wo kommt diese Komplexität eigentlich her und wie kriegt man sie klein?

Es gibt eigentlich im Grunde nur zwei Quellen von Komplexität.

Das eine ist halt so solche Abhängigkeiten.

Und das ist halt, wenn man viel davon hat, ist halt doof, weil das bedeutet halt, wenn du etwas änderst, musst du viele andere Sachen, alle Abhängigkeiten ja auch anfassen.

Und die zweite Geschichte ist Obscurity.

Ich weiß gar nicht, wie man das am besten übersetzt.

Undurchsichtigkeit.

Undurchsichtigkeit, ja.

Nebel.

Obscurität, ja, ich weiß nicht, genau.

Unklarheit, Unklarheit vielleicht, ich weiß nicht.

Naja.

Jedenfalls, das ist halt, ähm, das passiert, also, und das sorgt halt für noch schlimmere Probleme, das sorgt so für so Unknown Unknowns, dass du halt gar nicht weißt, also wenn du viele Abhängigkeiten hast, ja, nehmen wir an, du hast halt irgendwie, du weißt halt, wenn du das jetzt änderst, dann musst du das an 100 Stellen auch noch anfassen.

Dann weißt du halt so, oh mein Gott, das dauert

jetzt lang.

Aber was dann diese 100-Stellen eigentlich alles machen, das weißt du halt nicht, vielleicht?

Ja.

Ja, aber wenn du, genau, zum Beispiel nehmen wir an, du hast jetzt diese eine Abhängigkeit, die sagt, wenn du die Hintergrundfarbe von diesem Banner ändern willst, dann machst du das hier.

Und jetzt hast du aber in zehn Dingern hast du es halt von Hand überschrieben.

Aber das weißt du halt nicht mehr, das ist nicht dokumentiert.

Dann, das sind halt diese Sachen, wo dir dann hinterher auffällt, dass den, oder ein Kunde sagt dann halt irgendwann so, oh, da stimmt aber die Farbe nicht.

Wir hatten das doch geändert.

Wieso ist denn die jetzt da an der Stelle falsch?

Und dann kriegst du das sozusagen als Bugs wieder zurück, was du nicht wusstest, dass es diese Abhängigkeit gibt, aber die war halt nicht dokumentiert.

Ja, und dann, die sind eigentlich, das sind die schlimmsten, weil das Problem ist halt, du weißt halt gar nicht, dass du das eigentlich hättest machen sollen.

Ja, da alles, was implizit dann tatsächlich einem nicht auf die Füße fällt.

Ja, und dann ist halt die Frage, wo kommt das her und wie kriegt man das verändert?

Und oft ist es halt vielleicht Dokumentation.

Das ist auch etwas, das fand ich nett, wie dieses Buch hat meine Einstellung zu Kommentaren und Dokumentation so ein bisschen verändert.

Jochen schreibt übrigens nie Dokumentation oder.

Nein, das da nie.

Es wäre nie zu hart.

Ja, der Code erklärt sich selbst und so.

Ja, okay.

Aber tatsächlich, ich würde auch sagen, also ja, ich meine, es gibt ja da unterschiedliche Ansichten zu.

Eine auch verbreitete, jetzt, wenn man so Clean Code nimmt, auch ein Buch, was sich ja mit solchen Themen beschäftigt, von Robert Martin, Ankel Bob genannt, der sagt ja immer, ja, so komm, wenn du einen Kommentar schreibst, gut, manchmal lässt sich das nicht vermeiden, musst du halt machen oder manchmal musst du halt, aber sei dir bewusst, wenn du das tust, es ist im Grunde ein Fehler.

Also es ist im Grunde eins.

Weil wenn du es richtig gemacht hättest, dann hättest du es so hingeschrieben, dass man das nicht hätte kommentieren müssen.

Ja, ich

meine, ein paar Kommentare sind natürlich blöd, weil man muss sie halt aktualisieren und anpassen, wenn man sie.

Ja, du hast halt eine mögliche Inkonsistenz auch erzeugt, das ist ja findet.

Genau, das ist schon doof, also man muss halt echt schon aufpassen.

Aber es ist einfach an vielen Stellen sehr, sehr hilfreich, auch gerade wenn man kollaborativ arbeitet, einmal kurz hinzuschreiben, was denn da passieren, warum denn da irgendwas passiert.

Absolut.

Anstatt das halt einfach nicht zu machen, weil dann die Leute fragen sich, da wird irgendwie funktioniert aufgerufen, warum?

Oder so.

Selbst wenn der Name toll ist und so.

Absolut.

Ja, ja.

Ja, ich muss auch sagen, also der, der, der, genau, dieses Buch hier nimmt das auch relativ detailliert auseinander.

Und da sagt dann halt so Sachen wie, ja gut, selbst wenn der Code selbst dokumentierend ist, dann einmal, du kriegst das Problem, die Variablen und die Funktionsnamen werden halt lang.

Du hast das Problem, du schreibst dann, wenn das die Dokumentation von deinem Ding ist, dann schreibst du die ja an jede Stelle, wo du das verwendest.

Das ist ja auch Quatsch.

Das sollte man ja nicht, also das ist ja auch irgendwie offensichtlich Quatsch, das kann ja nicht sein.

Das sollte ja reichen, wenn man das an einer Stelle schreibt und dann ja.

Und hat halt noch so viele, viele Punkte, aber der allerwichtigste Punkt eigentlich, wo ich dann auch gedacht habe, okay, ich glaube, ich muss meine Einstellung dazu überdenken und vielleicht mal anders probieren und mal gucken, vielleicht funktioniert es dann ja anders besser, ist, dass er sagt, ja, also eigentlich das, was dein Code tut, ist eigentlich, oder das, das Entscheidende beim Design von so einem System ist eigentlich nicht so sehr, der Code ist eigentlich gar nicht das Entscheidende, weil der Code ist halt die Implementation davon, aber das ist halt.

Ich kann schreiben Magie, Call Magie, Call Magie, Call Magie.

Und aber was da herauskommt, ist wichtig.

Die Abstraktionen sind wichtig.

Und die stehen aber, aber Code ist möglicherweise gar keine so gute Art, um diese Abstraktionen sichtbar zu machen oder irgendwie zu dokumentieren.

Und er sagte also, natürliche Sprache ist dafür deutlich besser geeignet.

Und eigentlich sollte man sich Gedanken über die Abstraktionen machen.

Und dann schreibt man in natürlicher Sprache hin.

Und wie man das dann implementiert, ist ja nochmal eine andere Sache.

Das ist sehr schön, weil bei Python halt, finde ich, von meinem Empfinden her, ich mache natürlich auch keine Ahnung, aber die Sprache ist, mit der man am nächsten an natürlicher Sprache schreiben kann, entwickeln kann und dass es irgendwie stimmt.

Sonst bei Sonic, es hört sich für mich irgendwie so ein bisschen mehr nach, ich schreibe wirklich was dahin, was ich auch so sagen könnte, vielleicht.

Also ein bisschen.

Und das ist nicht immer bei allen anderen Sprachen drin.

Eigentlich so nie.

Nie.

Ja.

Ja, naja.

Es ist halt ja, es gibt da ganz unterschiedliche Philosophien.

Ich finde das, ich finde das sowieso auch interessant.

Bei Go zum Beispiel, die, die, ähm, gibt es auch bekannte, ich weiß jetzt nicht mehr wie der Talkies, aber einer, der ja auch, der, der die Sprache mit designt hat, der ist halt ein Verfechter von irgendwie kurze Variablenamen nehmen.

Ja, aber letztens irgendwann einen.

A, B, C, D und E.

Auf der Frostconf.

Frostcon, ja, also, ja.

Ja, also es ist nicht immer gut.

Es gibt auch einen auf der Frostcon, habe ich letztens einen getroffen, der war, da hatte der sehr extreme Standpunkt und meinte, was muss man lang sein?

Kurze Variablenamen schrecklich.

Ganz furchtbar geht gar nicht, ist schrecklich.

Ich sage so, naja, also manchmal ist das schon nett.

Also gerade wenn man jetzt komplizierte Logik hat, dann kann es sein, wenn man lange Variablen stehen an wie Variablenamen im Weg, dann sieht man überhaupt nicht mehr, was passiert.

Das ist ja auch in der Mathematik so, da schreibt man auch eigentlich immer nur ganz kurz Sachen und Formeln so kurz hin.

Das hat halt auch den Vorteil, dass man das dann auch überblicken kann, wenn man das alles ganz detailliert ausschreibt.

Manchmal machen wir überhaupt nichts mehr sehen.

An der Stelle tatsächlich vorher die Zuweisung, zum Beispiel D gleich Data vor irgendwas.

Und dann mache ich dann nicht immer Data vor irgendwas, dann nimmt man irgendwie so, dann wird das so ein bisschen dadurch klar.

Ja, genau.

Und da macht das Buch auch einen interessanten Vorschlag und sagt so, ja, ja, also der Name sollte umso länger sein, je weiter weg die Variable quasi von ihrem ursprünglichen Ort, wo sie mal definiert wurde, ist, verwendet wird.

Also je weiter das weg ist, desto eher musst du halt einen langen Namen nehmen oder desto länger muss der Name sein.

Aber je näher du da dran bist, dann ist es, ähm, dann kannst du auch kürzere Namen nehmen oder sehr kurze.

Ja.

Weil dann ja immer noch alles im Blick ist.

Du hast halt, du siehst halt, was da passiert irgendwie sofort.

Naja, also es ist.

Also Readability Count, das ist ja auch wieder so eine Sache aus dann auf Python.

Naja, also ja, schon faszinierend.

Genau, aber auch sowas, also Obscurity kommt halt auch, der ist auf dem ein sehr schönes Beispiel beschrieben, wo Variablen-Namen an böse Überraschung bescheren können.

Der hatten sie, die haben, also der Autor von dem Buch, der hat TCL mal diese Scripting-Language geschrieben, also diese Sprache designt.

Vielleicht kennt man das auch von früher, da hat man so User-Interfaces damit gebaut in Unix, häufig Tickle DK, ist das?

Ja, das hintergibt es, ja.

Genau, das ist die Python-Geschichte.

Mit Python kann man das auch machen.

Das ist die einzige UI-Geschichte, die in der Steiner-Bibliothek drin ist.

Und der hat aber noch diverse andere gemacht.

Der hat zum Beispiel ein Cloud-Dings gebaut, also ein quasi verteiltes Betriebssystem und ganz viele coole, interessante Dinge.

Und in diesem Dings gab es ein Fallsystem auch und in der Fallsystemimplementation gab es irgendwie eine Variable, die hieß Block.

Und da hatten sie einen ganz fiesen Bug, wo sie irgendwie da Monate gebraucht haben, um den zu finden.

Und der lag dann letztlich daran, und das ist dann halt eben das, was dann diese Obscurity tatsächlich so schlimm macht, der lag daran, dass sie Block subtil unterschiedlich einer Bedeutung verwendet haben.

Also sie haben Block als Variablen Namen benutzt, aber in dem einen Fall bedeutet er etwas leicht anderes als in dem anderen Fall.

Und wenn du das liest, dann sieht es aber so aus, als ob das irgendwie das gleiche ist.

Immer der Block.

Aber wenn du es dann halt verwendest, so als wäre es das gleiche, dann hast du halt einen subtilen Fehler gemacht.

Und in ganz obskuren Fällen hat es dann halt irgendwie mal irgendwie zusätzliche Daten in irgendwie Files reingeschrieben oder weil irgendwas nicht richtig allein war.

Also so ganz Horrorbockbugs.

Naja, irgendwie so Magie, die passiert im Dunkeln, aber schwarze Magie macht irgendwas kaputt und du weißt nicht genau was.

Ja, ja, schwierig.

Und das ist halt dann, ja, das lag halt einfach daran, dass der Variablename halt zu generisch war.

Also sie können halt zu generisch sein, sie können halt aber auch zu speziell sein.

Also ich meine, irgendwie, keine Ahnung, der Java, File-Input, Buffer, Stream, Schlag nicht tot, Reader, ist halt auch irgendwie dann nicht mehr so der Sinn.

Das ist auch nicht so für ein Jahr.

Ja, aber das ist halt vielleicht geschmacksfrei, vielleicht auch anwendungsfrei spezifisch.

Ich glaube, eine Sache, die man ganz generell festhalten kann, ist, wenn man irgendwas refactoren möchte, also nochmal ganz generell gesprochen ist, dass einem der Unit-Tests oder funktionale Tests oder was auch immer für Tests sehr, sehr helfen können.

Und nicht nur, dass man dass man quasi das, was man refactort hat, dass man das vernünftig testet, das sollte eh klar sein, sondern wenn es hinreichend kompliziert ist, dass man auch einfach mal Tests schreibt für den Bestandscode, dass man einfach sicher sein kann, was mache das eigentlich und dass sich das nicht verändert hat.

Ich habe letztens, ich weiß nicht ob das, ob das mit euch war, ob ich mit euch darüber gesprochen habe, mit dieser Oracle-Implementierung, wo die dann auch gesagt haben, das Ding war irgendwie dermaßen alt and verbuggt, dass sie dann quasi alles komplett mit Unitests zementiert haben.

Also jeden Bug und dieses merkwürdige Verhaltenssystem hatte, haben die mit Unitests zementiert und die haben irgendwie ein Jahr lang, glaube ich, nichts anderes gemacht.

Und dann haben die angefangen das zu refactoren, weil die halt einfach Angst hatten, weil also teilweise war es wohl auch so in der Community, dass die Leute halt auf diesen merkwürdigen Verhalten oder Bugs, wie man es halt nennen möchte, halt aufgebaut haben und Features draufgesetzt haben.

Und die konnten das den Leuten nicht einfach wegnehmen, weil dann halt irgendwie ganz viele Sachen zerbrochen wären, weil das halt irgendwie so Teil der impliziten API gewesen ist und sowas.

Und das kann tatsächlich.

Und das kann tatsächlich auch helfen.

Also ich habe das jetzt einmal gemacht, als ich jetzt ein größeres Teil angefangen habe zu refactoren, also einfach Tests für den Bestandscode zu schreiben.

Es macht keinen Spaß.

Ja.

Ja, aber dass man den Tests auch ein gutes Stichwort, ja.

Das ist halt auch so, also natürlich, es gehört, dass man, dass man Sachen testet und es ist auf jeden Fall super, also das ist eine der Dinge, die viel gebracht haben auf der anderen Seite, muss ich sagen, Test-Driven Development, weiß ich nicht so genau.

Da würde mich jetzt doch nochmal allmählich interessieren, ob es wirklich Leute gibt, die das so durchziehen und die das gut finden.

Ich glaube schon.

Vielleicht müssen wir mal jemanden suchen.

Es kommt noch an, ich glaube, wenn man selber schreibt und wenn man weiß, was man tut.

Dass man halt, wenn man halt tatsächlich weiß, was man raus haben will, dann schreibt man einen Test, der das quasi die Logik, die man implementiert, die zwei Methoden quasi mit einem Test Case so das Ergebnis hat.

Also zum Beispiel zwei, du hast halt einen Datensatz und du kennst das Ergebnis, das heißt, du machst einen Beispieldatensatz und da am Ende weißt du, das Ergebnis kommt raus, und dann weißt du ja quasi schon implizit in der Stelle wahrscheinlich oder explizit so ein bisschen, also du kannst auch hinschreiben in Logik, wie das aussehen soll.

Was muss passieren, damit das passiert, dass das stimmt.

Und dann kannst du den Methoden schon die richtigen Namen geben, die du dann irgendwie füllen musst, damit die am Ende rauskommen sollen, wenn das jetzt nicht zu komplex ist und dann kannst du das implementieren und dann, wenn das für dein Test Case stimmt, wirst du ziemlich sicher sein, dass das auch für die anderen Fälle laufen sollte.

Ja, aber also.

Und wenn du das halt so machst, das ist halt so ein TD-File, wo ich sagen würde, das kann dann ganz gut sein.

Du kennst quasi.

Ja, also wenn du genau weißt, was passieren sollte.

Genau, du kennst den Testfile.

Du kennst halt den Testfall.

Du weißt den Testcase, den kennst du schon.

Du weißt, okay, das sind meine Testdaten und du weißt, das Ergebnis von dem Test ist so und dann kannst du dafür dann eine Methode schreiben, die diesen Testfall nicht dich macht.

Und wenn du quasi alle Testcases hast, dann ist dein Code schon richtig.

Und das ist ein cooler Fall, wo man das machen kann, wo man dann halt für generische Fälle Code hat, der funktioniert und wo TDD Sinn macht.

Wenn du es aber nicht hast, weil du nicht weißt, ob die Testcaser vollständig sind, ob du irgendwelche Edge Cases hast oder sowas, dann ist es halt Nooper nervig, weil dann muss ich Test draußen mal umbauen, irgendwas wegmocken müssen.

Aber das ist ja auch Teil Teil des Prozesses, dass du halt die Tests auch ständig anpasst.

Ja, ja, genau.

Also ich glaube, ich glaube, TDD, der größte Vorteil davon ist einfach, dass man erstens Code so schreibt, dass er testbar ist.

Weil das habe ich früher auch nicht so gemacht.

Wenn man keine Unit-Tests schreibt, dann schreibt man Code anders.

Und das ist schlechterer Code.

Das ist einfach eine generelle richtige Aussage.

Und das zweite ist, du wirst, du kommst, wenn dann plötzlich der PO oder irgendwer Stress macht, dann lässt man die Tests nicht weg, weil die sind schon da.

Ich glaube, das sind die beiden Hauptverkaufsargumente dafür.

Ja, du kannst halt keinen ungetesteten Code schreiben.

Das ist halt irgendwie natürlich so ein bisschen, das ist halt schon vielleicht gut.

Aber eben, das gab es auch in der letzten Django-Chat-IP so, ich weiß nicht, letzte Vorletzte, keine Ahnung, wo sie.

Da gab es auch, da ging es auch um das Thema Test-System Development und auch alle da meinten so, ja, ganz gut hier ist eigentlich vielleicht nicht so schlecht, aber der Konsens in der Runde war halt auch so, naja, so wirklich machen, macht das dann doch keiner.

Und auch mit dem Argument und das, was wir, glaube ich, auch schon mal gemacht haben, dass halt das Problem ist, wenn man jetzt, wenn klar ist, was zu tun ist, dann ist das vielleicht machbar.

Aber ich hatte auch heute wieder so einen Fall, wenn man nicht weiß, was man machen will, dann ist das ganz blöd, weil das hilft einem überhaupt nicht, dass man damit mit dem Test anfängt, weil man muss sowieso irgendwie rumprobieren und das dann in einem Test zu machen, macht irgendwie nicht so viel Sinn.

Das Buch macht da auch einen interessanten Punkt und sagt halt, naja, also wenn du Test-Development machst, dann zwingt dich im Grunde das Vorgehen, dir von Anfang an ganz viele detaillierte Gedanken über die Implementation zu machen, an der Stelle, wo das vielleicht überhaupt nicht zielführend ist, sondern du willst vielleicht am Anfang dir erstmal Gedanken über das Design über die Abstraktion machen und nicht über die Implementierung.

Und das geht mit Test-Driven Development gar nicht so richtig.

Und was er dann vorschlagt, ist zu sagen, mach doch lieber Document oder ja.

Du implentierst die Methoden, schreibst du den Doctrine dazu, weil das tut toll und schreib dann Vortrag.

Genau, überhaupt nicht die Implementation, sondern du schreibst halt nur in natürlicher Sprache sozusagen, was die Abstraktionen sind, was die ungefähr machen sollen.

Und mit denen spielst du so lange rum, bis dir das Design gefällt.

Und dann fängst du erst das an, das zu implementieren.

Ehrlich gesagt, also ich versuche das jetzt mal, mal gucken, keine Ahnung.

Okay, dann die Tests schreiben und dann implementieren vielleicht.

Ja, aber genau, also ich weiß es nicht so genau, ob es wirklich funktioniert, weil ich habe immer so den Verdacht, also bei mir ist es oft so, wenn ich irgendwie, ich merke erst beim Rumprobieren damit um rumspielen und umstellen, irgendwann, ach, wie das Design eigentlich hätte sein sollen.

Ich kann das nicht gut mir vorher irgendwie, also dass ich mit einem Design, dass ein gutes Design dabei rauskommen würde, wenn ich nur so mit abstrakten Geschichten rumspiele, das ist bei mir irgendwie nicht so.

Man merkt ja auch mal ein paar Mal, wenn man auch das erweitert hat, also ist auch doch nicht so toll, dann muss er doch nochmal anders und vielleicht auch selber.

Oft kommt halt die Idee für das Design aus dem aus der Implementation.

Also dass ich merke so, okay, ich halte an der Stelle, mache ich zwei, drei Umstellungen und dann merkst du, okay, das ist jetzt alles, jetzt brauche ich gar kein Objekt mehr, das nämlich da einfach dickt oder so.

Und dann, oh, dann kann ich das ja so ausdrücken und dann kann ich so, oh, und jetzt ist das Design auch klar und so.

Und das kommt halt aus dem, da mit den Datenstrukturen rumspielen.

Nicht so sehr aus dem, sich abstrakte Gedanken machen.

Ich weiß es nicht.

Ich probiere es mal aus, mal gucken.

Also es klingt auf jeden Fall ganz interessant und es ist halt nochmal ein bisschen was anderes als Test-Driven Development.

Und ja, ich glaube auch, das habe ich bisher einfach unterschätzt und irgendwie nicht richtig gemacht mit der Dokumentation und Kommentaren.

Das ist wahrscheinlich doch deutlich wichtiger, als ich gedacht habe.

Da muss ich mal mehr machen.

Ja, das klingt gut.

Also tatsächlich dokumentierter Code.

Sehr Senn, sehr senn, sehr senn ermeißend.

Ja, ich glaube, wir haben über Refactoring, äh, ich habe nicht mehr so viel auf meinem Channel, was ich hätte.

Ich kann mal gerade gucken, ob ich mir, was habe ich mir denn aufgeschrieben, was ich dazu noch.

Ich muss natürlich sagen, mein Tießen kaputt, hatte ich am Anfang schon erwähnt, aber das ist nicht so schlimm.

Ja, übrigens, achso, genau.

Das ist das jetzt, das ich hier gerade habe, was ich mir aufgeschrieben habe, ne, Red Flag, irgendwie extensive Dokumentation, schreibt er auch, obwohl er eigentlich sagt, du hast voll gut.

Er sagt, ja, wenn Leute viel, viel dokumentieren, ist auch ein Zeichen für schlechtes Design.

Weil das ist ja etwas, was nicht, ist ja nicht gut, dass man das hat, sondern je mehr man dokumentieren muss.

Man muss viel erklären, ist auch nicht.

Wenn du viel erklären musst, ist nicht gut.

Eigentlich sollte es offensichtlich sein und man sollte es mit wenig.

Also ein oder zwei Sätze am Anfang, was macht das überhaupt?

Und dann muss man die ganze Funktion nicht lesen, wenn das stimmt.

Aber deswegen, das finde ich auch so eine Sache, warum ich Typeins gut finde.

Jetzt nicht, weil es unbedingt so die Typensicherheit alles sicherstellt.

Aber wenn ich halt den Funktionsnamen lese, der gut gewählt ist, die Typeins, die dazu passen, zu den Parametern, die die Funktion hat, und dann den Doc-String, der idealerweise mir erklärt, was das macht, dann habe ich ja den Return-Wert, dann muss ich gar nicht in die Funktion reingucken, um der alles genau angucken, sondern ich weiß halt, was sie tut.

Ah ja, okay, und kann zum nächsten übergehen.

Das ist super, super schön zum Arbeiten.

Ja, das ist dann halt beispielsweise für eine gelungene Abstraktion.

Wenn du halt sozusagen der Interface-Dokumentation schon ansehen kannst, also alles daraus alles erfährst, was du brauchst, um das benutzen zu können.

Ja, genau.

Du kannst einfach die Doc-Strings skimmen, ja, und kurz gucken, ja, okay, jetzt mach das und das und das.

Muss gar nicht so genau den Code hier angucken, dann ist das auch egal, ob die Leute da so ordentlich gearbeitet haben irgendwann.

Ja.

Ja.

Absolut.

Ja, ja.

Nö, ich habe jetzt gerade nochmal geguckt, ich habe auch sonst nichts mehr eigentlich, was ich irgendwie unbedingt unterbringen kann.

Nein, bei mir ist ja auch alles untergebracht.

Oh, jetzt sind wir auch, wir sind ja schon relativ weit dran.

Wir haben immer viele Leute, die ab dann abspringen.

Jetzt kann man Meinung von Leuten, die sich, die bis hier durchgehalten haben, wäre ganz interessant vielleicht.

Und zwar habe ich, das war letztens im Stream, hat dann irgendjemand geschrieben und meinte, so, ach, es wäre doch voll gut, wenn ihr sowas hättet wie ein Discord oder so.

Aha.

Wollen wir sowas haben?

Ich meine, wir haben einen Slack, aber Slack ist irgendwie.

Wie hat das jemand dann gedacht?

Ach, Slack ist ja immer so ein Boomer-Discord.

Ja.

Also Discord habe ich übrigens auch, habe ich auch von meinen eigenen Zeugs von online einmal und so.

Also ja, wir können einen Tele anmeister kein Problem.

Oder ich meine, welche Plattform sollte man da verwenden?

Discord.

Discord echt.

Ja.

Ja, die machen auch so NFT-Kram und Krypto.

Dass das sagt jemand, der Werbung für VPNs macht.

Spoiler Flynn, ich weiß nicht.

Ja, es ist alles so ein bisschen.

Ich weiß nicht so genau.

Ja, okay.

Also Discord wäre gut.

Ja, weil ich meine, dann könnten halt auch Leute da irgendwie mal, man könnte mit Leuten chatten und so.

Also könnten Leute live.

Das haben wir auch irgendwann wieder weggeschmissen.

Also Discord würde ich auch sagen, ist cool.

Okay.

Das nutzen halt alle von früher und so vom Gaming und so weiter.

Und man kann halt super easy da halt irgendwie reingehen, man hat halt Video, man halt halt Chat, man hat halt alles eigentlich, was man so bildet.

Das ist argument.

Die Firma kenne ich gar nicht.

Du hast irgendwas Böses für die Firma gehört.

Ja, also es ist halt nicht so, dass man das selber betreiben könnte.

Du bist halt dann abhängig von der Firma, genau wie bei Slack.

Ja, gut, du machst halt einen Channel auch fertig, ne?

Ja, ja, okay.

Ja, ich weiß so ein bisschen, was du meinst, aber so.

Also ich würde das natürlich, äh, mir ist es schon sympathisch, zum Beispiel auch, was sie technisch machen.

Die haben ja auch irgendwie da Rekorde aufgestellt, mit wie viele Clients an einem Server hängen können, mit Erlangen und so.

Die machen halt, das ist alles schon cool, aber irgendwie, ja, das ist halt eine Firma, also ich würde es gerne selber hostenkosten können oder sonst was.

Ja, aber diese ganzen Indie-Lösungen, die es für sowas halt gibt, ich weiß nicht, die sind halt von der Nutzerbasis, glaube ich, gar nicht so interessant.

Ja, man muss wahrscheinlich dahingehen, wo die User sind.

Ja, genau.

Hey, wir haben.

Gefällt mir gar nicht, aber gut.

Nein, sind wir doch nicht auf Instagram-Tade.

Ja, gefällt mir.

Genau, ja, dann lass uns doch noch nicht festkommen.

Nee, aber Discord finde ich ganz okay, es geht.

Du hören mir es eh immer an.

Ja, gut.

Johannes auch da.

Ja, ja, ich weiß, der hat ja da auch irgendwie ein eigenes Ding aufgemacht, aber der ist auch gar nicht so wahnsinnig viel los.

Ja, aber das liegt auch ein bisschen daran, also unter anderem, dass er das halt auch seine Sachen benutzt, wie seine Spielfirma.

Naja, aber wie auch immer.

Du hast ja auch Discord auf der Arbeit.

Nein.

Okay.

Also ich habe meine eigene, mit Leuten, ich würde da auch mit Kunden drüber sprechen.

Also ich finde, das ist so die beste Teams-Alternative zum Beispiel, wenn ich jetzt so Kundenprojekte habe.

Wenn die auf meine Plattform kommen, ich nicht auf deren muss, dann die Kommunikation ist irgendwie schöner, professioneller, sauberer Cleaner irgendwie.

Aber es ist noch wieder so eine ästhetische Sache und keine Ahnung, als kommerzieller

Profitherer hat.

So besser als Teams zu sein, ist jetzt nicht so furchtbar,

weil wir darum, wo die

User sind und so.

Und die sind ja auch schon alle leider da, meistens dann.

Ja, ja, ja.

Ja.

Wollen wir noch Picks machen?

Stimmt, wir haben noch Picks, keine Hammer keine Picks.

Bonny darf anfangen.

Ich habe mich jetzt motiviert von der letzten DjangoCon jetzt echt intensiver mal mit HTMX auseinandergesetzt.

Oh ja, ja.

Und das finde ich wirklich sehr, sehr cool.

Ja, dafür machen wir auch irgendwas eine Folge, das ist tatsächlich toll.

Ich bin ja tatsächlich auch nicht so ein riesen JavaScript-Freund.

Und diese Karotte quasi kleinseitige Weblogik ohne JavaScript zu schreiben, ist schon sehr, sehr groß für mich.

Hab da letztens noch einen sehr interessanten Vortrag von dem Macher gehört.

Ich glaube, das war von der

Pacon US oder so.

Castleister irgendwie.

Ja, genau, genau.

Der hat auch sehr schön erklärt, wie REST eigentlich funktioniert.

Genau, und dass es ja eigentlich darum geht, halt dem H-Snips hin und her zu schicken und nicht JSON-APIs zu bauen.

Und es ist ein super interessanter Vortrag, hat mir ein Kollege empfohlen.

Und ich habe mich damit nochmal beschäftigt, habe heute noch ein kleines Feature damit gebaut.

Ich muss gestehen, ich glaube, ich habe es noch nicht so 100%.

Also es tut die Beispiele, die da drin sind, relativ simpel.

Also ich klicke irgendwo, dann tauscht sich was aus, das ist klar.

Aber wenn man halt so ein bisschen darüber hinausgehen möchte und halt einfach mal irgendwo Daten schicken oder so, also mal Postdaten schicken, die Patterns habe ich noch nicht so ganz raus.

Ich bin leider nicht ganz ohne JQuery rausgekommen.

Das hat mich persönlich dann sehr geärgert, weil erstens jQuery und zweitens JavaScript.

Aber ich glaube, wenn, also die Dokumentation lässt leider in meinen Augen ein bisschen zu wünschen übrig und googeln kann man auch nicht, weil Google immer denkt, man meint HTML.

Das ist beides ein bisschen blöd.

Genau, wie HTTPX ist auch mal doof.

Ja, genau.

Und ja, aber ich glaube, wenn, dass das sehr viel Potenzial hat.

Es macht auf jeden Fall sehr viel Spaß, damit zu arbeiten.

Und im Endeffekt die Idee ist halt einfach, dass man halt Custom JavaScript-Code durch Custom HTML-Tags ersetzt.

Und das ist echt cool.

Also ich habe da auch letztens meine Findings, wie man das mit Django verheiraten kann, auch dem kleinen Artikel zusammengeschrieben.

Das habe ich mir noch nicht angeguckt, ich weiß nur, dass es gibt.

Es gibt ein Paket von Adam Johnson, also der mit dem.

Was tut das Paket denn?

Weil das sind tatsächlich sind es eigentlich vier Zeilen Code, man muss den CSF beibringen und das war's.

Ah, okay.

Also das ist Django HMX ist das Paket, glaube ich.

Ah, okay, ich weiß gar nicht, was das tut.

Weiß ich auch nicht.

Weiß ich auch nicht, aber das ist auf jeden Fall, der Autor ist auf jeden Fall schon mal ein Hinweis darauf, dass man sich das mal angucken sollte.

Auf jeden Fall, ja.

Und ja, genau.

Ja, muss ich echt mal machen.

Aber wie gesagt, ich habe es halt einfach zu Fuß gemacht, wenn ich wusste, dass das Paketexten sind.

Wenn man es halt mal einmal gefunden hat, es sind literally halt einfach vier Zeilen JavaScript, die man einbinden muss, dass man halt dem HTMX quasi den CSF-Token injectet.

Ja, da muss auf jeden Fall einen oder nächsten Folgen hören, da werden wir da auch nochmal drauf eingehen.

Ja.

Ja.

Jochen.

Ich weiß nicht so genau, was picke ich denn?

Also ich picke Pendulum.

Ich glaube, das hatte ich schon mal gepickt.

Weiß ich nicht.

Ich weiß immer, weil kann man ja immer nicht merken.

Du musst immer so einfache Sachen picken.

Ja, kennst du Pendulum?

Nee.

Nein.

Das ist eine Datetime-Parsing-Bibliothek.

Cool.

Ja, da kannst du so ein bisschen einfacher, so ein bisschen schöneres Interface, ein bisschen moderner.

Früher hat man, glaube ich, Maya viel benutzt, Kenness Reeze irgendwie, jetzt halt ziemlich tot ist oder so.

Und ja, aber da kann man so schöne Sachen machen, bei denen man Date Times irgendwie machen möchte.

In Time Zone wechseln und so Strings umbauen und sowas.

Okay, interessant.

Ich bin letztens habe ich, äh, das war, nein, nicht letztens, das war gestern, glaube ich.

Ich habe irgendwie so einen kleinen, da war ich, dass mich mit JavaScript beschäftigt und Zeit.

Ich wollte eigentlich nichts kompliziertes machen.

Ich wollte zum Beispiel einfach nur ein Date-Objekt einfach darstellen.

Und da, da war ganz schrecklich.

Ja, also Pendulum ist für Python für sowas, weil das auch immer nervt, meiner Meinung nach, sehr schön eigentlich.

Ja, also da ist, also das JavaScript-Date-Ding, also das, das hatte, also sowas wie Surf Time gibt es da halt einfach nicht.

Wenn man jetzt die Differenz zwischen zwei Dates bildet in JavaScript, ja, also du hast ein Date-Objekt, ein anderes, machst du eins minus das andere, was kommt dabei raus?

Wisst ihr das?

Ein Integer.

Bei Python kommt so ein Time-Delta raus.

Ja.

Ja, bei, genau, bei JavaScript kommt die absolute Zeit in Millisekunden raus.

Ja, tatsächlich.

Was natürlich ein bisschen blöd ist, wenn man jetzt Mikrosekunden braucht oder keine Ahnung oder was ganz anderes oder dann oder halt an den Tagen interessiert ist oder so.

Ja, das hat mich gemacht.

Ja, also ich kann es.

JavaScript weiß ich jetzt nicht, aber Pendulum in Python macht genau das so ein bisschen schöner, so ein bisschen mehr moderner vielleicht.

Okay, gut.

Keine Ahnung, ich kann es nicht, wir mal angucken.

Ja, vielleicht pick ich einfach Blue statt Black.

Macht im Grunde das gleiche, nur halt mit einem einfachen Tick statt Doppel-Anführungszeichen.

Wir hatten noch letztens irgendwas mit Black, was man.

Also Darker.

Darker war auch schön, ja.

Weil Darker macht nämlich inkrementelles Black und zwar immer nur auf die neuen Änderungen.

Was gut ist, wenn man halt ein neues Workshop hat.

So dass es halt immer dunkler wird mit der Zeit.

Und wenn man, weil das macht auch Sinn, dann halt als Skit-Commit-Hook irgendwie einzusetzen.

Darker, weil dann nur die neuen Sachen halt tatsächlich gelintet werden und das ist

ganz schön.

Okay, aber Blue ist ein bisschen.

Oh warte, was ich auch noch picke, ist Pip Tools.

Da habe ich letztens auf Twitter gesehen, auch jemand, ich habe für meinen.

Dann wird angefangen, weil du mir das gezeigt hast, wollte ich gerade was mitmachen, ich komme immer nicht dazu.

Weil ich habe nämlich auch, ich verwende ja sonst Poetry und genau, dann jetzt für das neueste Ding mit Fast API und View View und Frontend Dings da für meinen von meinem Deploy-Teil.

Da habe ich jetzt auch Piptools verwendet, weil mich Poetry so genervt hat, weil es so lange braucht.

Also Piptools so richtig toll fand ich es jetzt auch noch.

Und weil das halt oft auch irgendwie komisch kaputt geht und es gibt funktioniert.

Pip Tools gibt eine Empfehlung von dir?

Ja, also genau, heute auf Twitter meinte jemand so, also Poetry, eigentlich super sexy, sieht das aus und so, aber ich bin, ich bin durch.

Ich nehme jetzt wieder Piptools, weil es funktioniert einfach nicht.

Und da dachte ich so, ja, und dann habe ich dann in diesem Twitter-Stread, den muss ich nochmal aufverlinken, haben ganz viele Leute was ähnliches gesagt.

Also da viele Leute sagen so, oh, furchtbar langsam, geht immer kaputt.

Ja, also es geht auch bei mir ständig ständig kaputt und ich muss immer was manuell fixen, das nervt extrem.

Aber es ist schon eigentlich eine gute Idee und eigentlich sollte es genauso aussehen.

Nur was sollte es geben, tut halt nichts.

Aber vielleicht solltest du uns einfach mal fixen, anstatt was Neues wieder zu machen, was noch nicht funktioniert.

Vielleicht.

Gutes Schlusswort.

Ja, vielleicht sollte man das mal refactoren.

Danke, Ronne, dass du wieder da warst.

Ja, vielen Dank für eure Aufmerksamkeit.

Die Einladung.

Seid uns gewogen.

Schalte uns gerne wieder ein.

Bis zum nächsten Mal.

Bis dann mit Werbung.

Tschüss.

Tschüss.

Ciao.