Transcript: 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 auch Ronny da.

Hi Ronny.

Hi.

Jo, hi.

Kennt ihr vielleicht auch noch.

Grüße.

Jo.

Ja, vielleicht erstmal ein bisschen News.

Ich weiß nicht, so viel Neues gab es noch nicht.

Ja, 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 vorbeigekommen.

Das habe ich wahrscheinlich nicht bekommen.

Ja, cool.

Habe ich bei mir jetzt überall eingebaut und

stable. Ich glaube, das war

vorgestern oder so,

oder gestern, ich bin mir gar nicht sicher.

Vielleicht gestern ist Django 4

released worden. Ja, stimmt, genau.

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 Backward-Incompatibility-List,

oh mein Gott,

die ist ungefähr fünfmal so lang wie die neuen Features.

Das ist echt krass. Das ist super, ja.

und so ein paar Sachen rausgeflogen, die man nicht mehr braucht

oder die gefährlich sind oder so, schon gar nicht so schlecht.

Ja, ansonsten,

weiß nicht genau,

machen wir auch News in anderen, für andere Sprachen?

Ja.

Ich glaube, hier in PHP 8.1

ist 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

und 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

dann passiert irgendwie magisch das Richtige oder

was Falsches oder was Falsches.

Aber man hat halt daher, was in Python

tatsächlich ein bisschen nervig ist, ist, dass man halt

dieses Farbigkeitsproblem der Funktionen hat,

dass man halt, wenn man irgendwo async

was machen möchte, dann muss man

und Async sein. Ich meine, man kann natürlich auch hingehen

und sagen, okay,

async.io.run oder so,

aber das natürlich...

Man muss dann erstmal den Event-Loop immer rausführen, oder wenn man im

Jupyter gerade ist, dann ist das auch immer ein bisschen doof.

Ja, also

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.

Aber das ist vielleicht auch noch wenigstens wert,

weil damit wird in PHP auch dann irgendwann

das möglich, was ja jetzt in Python...

Das kommt ja jetzt in Python, ist das jetzt in den

ganzen Frameworks halt irgendwie so, oder zumindest Django, ich weiß gar nicht so genau,

FastAPI halt auch, aber das war ja schon immer so angekommen, dass man halt irgendwie

Async-Kram da machen kann und dann eben, ja, kann man halt solche Sachen machen, wie auch

Filesorving vom Applikationsserver aus oder halt auch WebSockers, relativ einfach und so.

Das geht dann halt, weil ich weiß gar nicht, wie das in PHP ist, da normalerweise eben Sachen

PHP-Filesorven, 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

Hustern. Da brauchst du mich jetzt gar nicht fragen.

Ich kenne den Nullkummer gar nicht aus, wenn es die Sprache ist.

Naja, aber genau, da geht es

halt auf jeden Fall auch voran. Also sowieso

per den letzten Versionen viel dazu gekommen.

Ich kenne mich noch vom Gegenschubsen

um zu treten.

Tja, kann man natürlich auch machen.

Ja, haben wir noch andere News?

Haben wir noch was?

Was war denn in Dango 4 drin?

Alles Schönes. Wüsst ihr das noch?

Ja, neuer

also Django Redis ist irgendwie also Redis scheint mit rein gekommen, weil automatisch, das gab ja immer sonst Django Redis Package und das kam direkt als Default-Test 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, Memcached war eingebaut und aber alle nehmen Redis, daher macht es irgendwie nicht so richtig viel Sinn, das nicht eingebaut zu haben und ja, deswegen ist das jetzt halt drin. Ja, ansonsten naja, war's nicht. Die IT-Set ist rausgeflogen, glaube ich,

in der Zeitzone oder so.

Aber ich glaube,

das war echt mehr ein Aufräumen

Release, gefühlt.

Was ja auch eine gute Sache ist

und was auch sehr gut zu unserer Refactoring-Session

passt.

Genau, das ist nämlich das Thema.

Genau, das Thema.

Ja, was ist denn das überhaupt, Refactoring?

Was sagt ihr denn, was das ist? Also ich sag mal so,

ich baute oft meinen Code um,

aber ist das schon Refactoring?

Also immer dann, wenn man halt ein bisschen später wieder draufguckt,

merkt man halt so, oh, wie war ich doof,

oder EU ist das aber hässlich oder schlecht,

was ich dir vorgemacht habe. Mach ich das doch mal nochmal

oder pass ein bisschen an oder mach es

ganz von neu. Was heißt

Refactoring für euch?

Nimmt man sich da extra Zeit für?

Gehört das in einen Sprint oder so?

Also ich würde jetzt mal sagen,

meiner Verständnis nach

gehört das halt schon dazu

zu den, wenn man

sich der agilen Softwareentwicklung

bedient als

Prozessmethode,

was auch immer man das nennen möchte,

dann würde ich sagen, so Definitions of Done

zum Beispiel bei Scrum

sagt, wann ist was fertig und dann

würde aus meiner Sicht halt

dazugehören, normalerweise, dass man sagt, man hat das

auch irgendwie mal refactured oder so

Wie viel Prozent der Zeit würde in sowas

wie? Och, keine Ahnung, das kommt drauf an, also

So ein Tag? Je nachdem, was man macht

Nee, das kommt halt, also

und manchmal muss man vielleicht auch das komplette System refacturen, weil

Wer refactort das denn? Man selber? Ein anderes Team?

Das eigene Team mit

vier, fünf, sechs Augen im Prinzip? Nee, immer

der, der fragt

Bei uns bin ich nicht mehr ich,

weil ich mag das irgendwie, Code umzubauen.

Ich weiß auch nicht, das ist 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.

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

Aber ist das ein guter

Grund zum Reflektor, dass es dann nachher hübscher aussieht?

Es tut halt dasselbe.

Ist das wasbarer?

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 rum zu feilen,

dass immer alles ein bisschen hübscher ist, das macht halt kein einziges

Feature mehr. Aber das ist auch vielleicht,

das hat man schon ein paar Mal erwähnt, so dieses

warum Programmierer irgendwie

Programmierer sein irgendwie nicht so

Business, wie ist nochmal dieser

Talk, da hatten wir schon mal drüber gesprochen.

Weiß ich gar nicht, welchen meinst du?

Ja, ja, du kennst den auch noch, den 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, weil man mag halt programmieren 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, genau 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 Sachen kriegst du halt, 21% der Zeit Refactor

und die Details, die kostet man dann richtig viel.

Die ganz wichtigen Details, davon das wäre klasse.

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

Du sagst ja,

der Business-User ist eigentlich, glaube ich,

eine sehr gesunde Einstellung, wenn man sagt,

es geht darum, Business-Value,

also zumindest aus der Business-Sicht ist es eine sehr

gesunde Einstellung.

Aber ich würde nicht nur sagen das. 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 jetzt 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 musste,

dass halt die Sprache reingegeben wird, etc., etc.,

habe ich halt dann direkt gesagt, okay, ich refactor

jetzt direkt alle E-Mails zu Classbase. Das ist natürlich

viel, also das war

definitiv in den 20%, 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 eh gerade 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.

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. Ich finde so Refactoren aufgrund

von, wir brauchen das vielleicht nochmal

und wie das da so steht, das versteht ja keiner.

Das ist ein Spaghetti-Band.

Irgendwer hat irgendwas gebaut, weil er noch gar nicht wusste, wie das ging.

und hat das dann alles hingeschrieben. Das ging dann irgendwie,

aber so richtig nutzbar

und schön ist das alles nicht, dass das irgendwie so,

wie man es so kennt, so zusammengezimmert.

Ich finde auch ein ganz wichtiger Punkt ist, dass

halt die meiste Software,

die funktioniert, wird ja konstant weiterentwickelt.

Das ist ja einfach so.

Da frage ich mich auch ehrlich gesagt immer warum.

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.

Das heißt, man fängt dann an

in etwas, was nicht dafür gedacht ist, mehr Sachen

reinzubauen. Das ist immer der Punkt, wo, glaube ich,

intrinsisch einfach schon der Bedarf von einem gewissen

Refactoring besteht. Vielleicht nicht bei der ersten oder zweiten

Änderung, aber irgendwann ist dann,

gibt die Struktur das einfach nicht mehr her.

Das ist halt genau die Frage. Wird

was moderner, muss man das dann, diesen modernen

Stil dann auch refactoren.

Das ist aber eine Stilfrage. 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.

Ein schönes Beispiel finde ich Google. Google hat

unheimlich viel Energie reingesteckt in das

Gmail-Programm oder so. Und eigentlich

würde ich fast setzen, dass so quasi Feature

Kompli zu dem, was man sich so wünscht. Also man kann alles

dann machen, was man mit zum E-Mail-Teil eigentlich so machen will.

Und die haben auch schon so viel Zeit draufgeschmissen,

dass so viel Neues nicht kommt. Was ich

jetzt immer sehe, da kommen irgendwelche Änderungen am Style,

an der Grafik, die irgendwas eigentlich einfach nur anders

machen, die mich dann zum Beispiel eher

nerven, weil ich brauche die einfach nicht, die will ich so 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 so,

okay, wir haben jetzt noch wieder einen Sprint, wir wollen nicht

aufgelöst werden. Wir wollen irgendwas machen.

Und dann wie fängt dann die da irgendwie rum?

Ist halt eigentlich schon fertig, die Software.

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 dann nur schlechter für manche Leute.

Und dann hast du halt vielleicht einfach Pech.

Aber das 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 es zu entwickeln, irgendwann wird das halt

negativ und aus einer Business-Sicht

müsstest du dann einfach aufhören zu entwickeln.

Aber ja, bestimmt,

mit diesem Schritt tun sich viele schwer.

Ja, genau. Und dann würde er sagen, okay,

wir machen jetzt was anderes.

Würde ich auch sagen,

das wäre eigentlich, irgendwann ist es halt durch.

Klar kann man irgendwann zehn Jahre 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, 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.

Den ganzen Code kann man fast wieder neu schreiben und dann hat man am Ende

was viel Schöneres dastehen.

Und ich weiß nicht, ist das Refactoring?

Ja, in einem halben Jahr später

fasse ich es wieder an.

Ich denke, das hätte ich irgendwie schöner machen können.

Also ich habe

das ja gleich mal direkt schon mal

spoilern. Ich habe so ein Buch gelesen,

das nennt sich

A Philosophy of Software Design von

John Osterhut oder so.

Keine Ahnung, ob ich den jetzt richtig ausgesprochen habe.

Das wurde mir empfohlen,

in der Hacker News Diskussion

und deswegen werde ich jetzt ganz viel daraus

zitieren oder beziehungsweise Dinge

sagen, die da drinstehen, weil ich davon jetzt noch

eine Menge weiß und dann demnächst habe ich das wieder alles vergessen.

Vielleicht habe ich jetzt schon eine ganze Menge vergessen.

Aber

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

Weil man hat kaum

Begrenzungen durch irgendwelche Dinge.

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

Seite.

Das ist halt

ein Wert, wenn das schön ist.

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, ist doch egal, Hauptsache es tut.

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

Und ich habe möglichst wenig Zeit dran im Rechner gesessen.

Der Product Owner hat es abgenommen.

Nach mir diesen Flut.

Eher so ein pragmatischer Ansatz.

Ich glaube, beide haben so eine gewisse Berechtigung.

Ja, total. Gerade wenn ich jetzt meinen Nutzen maximiere,

dann will 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 würde 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 oder hässlich ist, ist einem

völlig egal, Hauptsache es ist schnell damit fertig

und können das 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 passiert

mir egal und ob ich dann selber dann was Neues dranflatschen 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 Deliveren

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,

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,

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

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.

Das ist halt sehr normal gesehen.

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 heraus vorstellt,

und jedes Feature ist ja irgendwie ein Teil auf dieser Strecke zum Produkt, das irgendwann fertig oder an einem Release-Punkt ist.

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

Aber wenn man das halt über das 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,

wo wirklich dann Firmengeld drüber läuft, glaube ich, ist das halt viel zu kurz gedacht.

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 Zombiescrum zu werden. Es war eine relativ hohe Bugquote, das Team ist sehr viel Sachen hinterher gelaufen.

generell. Was war Bugquote? Ganz kurz,

Anzahl an Bugs pro 100-Zeilen-Code?

Bugquote ist quasi

die Anzahl der Bug-Tickets an allen Tickets im Sprint.

Oder Bug-Story-Points

auf die insgesamt Sprint-Story-Points

gezogen, berechnet.

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 halt insgesamt

so eine latente

Unmut auf allen Seiten.

Es lief halt einfach nicht wirklich rund.

Dann haben die halt angefangen,

so ein paar größere Sachen einfach mal anzugehen.

Weil dann war halt gerade das eine große

Release durch.

Wir machen irgendwie Coverage rein.

Wir zwingen Coverage in der Pipeline.

Sprich, neuer Code muss getestet sein.

Sonst kann ich nicht deployen.

Committen schon, aber nicht deployen.

Dann einfach mal geschaut,

dass man einfach so

Streamlining, wie kriegen wir

wie kriegen wir alle möglichen Variablen beim

Protiprogramm, das immer wieder mal auf die Nase fällt, wie kriegen wir

das raus und immer mehr solche Sachen

haben die halt dann angegangen

und damit hat sich dann, also nicht nur, dass halt dann plötzlich

die Backquote enorm gefallen ist,

man glaubt nicht, was so ein simples

Maß wie

ich erzwinge

Coverage in der Pipeline, das ist

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 die selber nicht drüber nachgedacht,

dass das wirklich so einen großen Effekt haben kann, aber auf einmal

ist auch so diese ganze Lethargie raus, wenn man plötzlich mit

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

so lange zusammenzuzimmern, dass es bloß nicht auseinanderfällt,

sondern man macht halt wieder was,

ja, das Kreative, das Schöne halt.

Mhm.

Ich finde das so ein bisschen schwierig,

und Jochen unterhalten sich über die Programmiersprache Python

neu machen muss.

Aus Business-Sicht ist das aber so ein bisschen komisch, weil

es ist eher so, die meckern immer die ganze Zeit

rum, warum läuft das denn noch nicht und warum sind da noch so viele Bugs

und das verstehe ich alles nicht und es muss alles fertig sein.

Aber später sind die dann gewohnt,

dass sie genauso viel Zeit und Geld aufwenden müssen

für Neuentwicklung und du denkst dir, ja, aber eigentlich

das ist ja in zwei Tagen fertig, weil

wir haben ja ordentlich am Anfang den Effekt gehört und schön gemacht.

Das heißt, wenn man 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

ist auch eher gefährlich, das zu kommen.

weil da so eine Erwartungshaltung entsteht,

dass das halt immer so wäre und dass das

auch nicht irgendwie clever dann vielleicht

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 Product Owner ist ja noch so

quasi mehr oder weniger Teil des Teams, aber

halt, genau, Product Owner

und Team irgendwie und

dem Product Owner mit einem bezogen

und halt irgendwie im weitesten Sinne das Management oder so.

Wenn es da kein Vertrauen gibt, ist es schlecht.

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 der User-Stories,

dass die halt da selber so committed drin sind

auch, weil wenn halt die immer nur irgendwie

ihre Tics wegschubsen, dann

ist das dann irgendwann wurscht.

Das ist halt genau so eine Kommunikationssache.

Was der eigentliche Clou wäre,

gutes Refactoring zu machen, von Anfang an das richtig zu tun,

ist halt ein gutes Teamgespräch

immer am Laufen zu halten, auch

und zwar nicht nur über Tickets und Leistungen

und KPIs, sondern halt auch...

Aber tatsächlich, ich meine, das ist halt auch das,

zu dem ganzen Agile-Kram

gibt es halt auch einen kleinen Absatz in dem Buch,

wo da halt so

gesagt wird, ja, okay, Agile, voll gut,

iterativ super, irgendwie,

dass die Fachkompetenz nicht an den reichsten

gekommen ist, also es gibt 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 designt

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

meiner Ansicht nach nichts in dem

zum Beispiel bei Scrum, was

eine Rolle, die dafür zuständig wäre, das durchzusetzen.

Simples, Better than Complex

Das ist der nächste Sender auf Python

Wenn das durch die Review beim Produkt owner, der da aber nicht aus einer

technischen Perspektive drauf guckt, sondern aus einer

Business Perspektive durchgeht, dann ist das ja gut

und das Team ist halt, wird immer dazu gesagt

ist dafür verantwortlich, dass es halt

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

Ich habe 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 der

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 nach Reflection

nicht so lange dauert, aber

man muss halt diese 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.

in unerwarteter Weise auch.

Und ich würde jetzt sagen, Reflectoring ist halt auch so ein Ding,

was halt im Grunde dafür da ist, die Komplexität

von so einem Software-System

zu reduzieren. Das wäre

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

Die Frage, was ist Komplexität? Komplexität

würde ich jetzt auch so mal definieren, wie es in dem Buch wurde,

dass er 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 zu hohen Abhängigkeiten oder zu hohe Abstraktionsniveaus oder zu verschachteltem Falschnamen. 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 macht das Sinn?

Noch ein bisschen Style

Du hast irgendwie gesagt, du wolltest den Unterschied

zwischen Design und Style an der Stelle

vielleicht erklären, was Design gemeint ist

Design

ist tatsächlich

wie funktioniert das

System gemeint, nicht so sehr, wie sieht es aus

oder wie sieht der Code aus

das ist alles nicht so, sondern eher wie

funktionieren die Teile miteinander

Also tatsächlich so Pattern

Ne

also wie ist, also du hast ja

also ich meine, nimm mal sowas wie Design Patterns

da sieht man vielleicht, was damit gemeint ist

das ist halt so

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, man hat immer mehr Ahnung davon

bekommt und das dann refactored, ohne mal, dass man

die Pattern kennt, ob jetzt die Lösung, die man hat, selber

Richtung dieser Pattern konvergiert.

Ja, genau, Design-Python ist genau das, worauf es dann halt

immer hinausläuft. Das ist eigentlich die Idee dabei.

Ich wollte noch gerade eine Sache einwerfen zu der Sache

mit der fehlenden Rolle 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 guten Entwickler hast,

und Jochen unterhalten sich über die Programmiersprache Python

der Scrum Master

ist vielleicht Techniker, aber vielleicht auch nicht.

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

Dann hast du ein Team, das ja meistens gemischt aus

Juniors und Juniors ist. Bei den Juniors kann man es eigentlich nicht erwarten,

dass 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 ein Gänsefüßchen gesagt, IT-Architekt,

weil das irgendwie in dieses

Fram 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 das ist auf jeden Fall ein Muss

und dann gibt es Artikel, die sagen, nein, braucht man

nicht, weil 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

sage ich mal so als Lead-Entwickler im Team sieht.

Das ist im Scrum ja explizit eigentlich nicht gewünscht, weil da alle

gleich sind und alle haben gleich die Verantwortung,

aber ich glaube, so zumindest

Aber so gut wie es geht sind die Teams ja auch immer nicht.

Genau aber ich glaube wenn du jemanden hast der sich daf verantwortlich f und der das technische Know hat und wie gesagt wichtig ist auch dass er erstens wei dass er diese Rolle hat und zweitens auch dass er das machen kann dann glaube ich kann das diese Br schon ganz gut also diese Br spannen und wenn der PO dieser Person auch vertraut und wenn die Person sagt nee sorry aber wir m das Technik vorher machen bevor wir das umsetzen weil sonst wird sonst nichts dann glaube ich ist das so der Weg den man da gut gehen kann

80% Planung und dann wird umgesetzt.

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 separat, logischerweise.

Aber ich glaube, die Idee ist wirklich, das ist jemand,

der gar kein zwingender Entwickler sein muss, der aber

trotzdem halt technisches Know-how hat und der

versucht, alle Abhängigkeit

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 und vom Kunden.

Und halt auch technisch. Das ist das Wichtige,

so dass man zum Beispiel sagt, weiß ich nicht, wenn ich

jetzt irgendwas habe mit asynchronen

Prozessen und Mailing, dass ich halt sicherstelle,

dass irgendwo drüber nachgedacht ist, dass ich irgendeine Art

von asynchronen Processing auch drin habe und nicht,

dass das halt dann nachher irgendwann auffällt, ups, blöd.

Wie machen wir das denn jetzt?

Blöd ist Blödbeformung.

Blockiert leider unter Protest.

Ja, also genau, Softwarearchitektur

ist natürlich auch so ein verwandtes Thema und

ja,

genau, aber

wer ist dafür zuständig, gibt es dann meistens,

also kann sein, dass die

dann halt nicht in den Teams immer mit drin sind, sondern

übergreifen, 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 drum kümmern müsste,

mal so, ist eigentlich schon

relativ offensichtlich.

Ja, aber 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?

Muss man das refactoren?

Ja gut, Refactoring ist jetzt sozusagen

das, was man dann tut, aber

was wäre denn das Ziel

von so einem Refactoring, wenn es darum geht,

die Komplexität zu senken?

Also ich würde auch

tatsächlich mit diesem Schönheitsansatz

ausreden.

Wahrscheinlich wisst ihr alle,

was man damit meint, wenn ihr schon mal ein bisschen

gut geschrieben habt. Kennt ihr was, was agil ist

und was stinkt irgendwie oder was, wo ihr denkt,

Oh, das ist aber hübsch.

Was wir da am Anfang irgendwie dann so um die Ohren,

ich habe das am Anfang nicht so richtig verstanden, ich weiß nicht, vielleicht geht es

ja anderen Leuten auch so, wenn

dann jemand draufgeguckt hat und war so, okay, vielleicht

nicht so toll, dann hieß es immer so, ja,

da muss man vielleicht mal so ein bisschen modularisieren

oder so, ne?

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

David Palas, genau.

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

Und 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 schon ganz einfach.

Im Idealfall.

Also zum Beispiel in Django gelingt es mir nicht immer, dass man so die Sachen von einer trennt, weil viele Sachen sind von der User-App abhängig oder sowas. Das ist nicht so einfach.

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, das ist 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, wie sind die Interfaces

Das ist eigentlich im Grunde das, was man für Architektur macht

beziehungsweise was man halt auch macht,

wenn man jetzt Design macht.

Also nochmal, Interface

ist halt die Schnittstelle, quasi eine API,

wo ein Modul mit dem anderen interagiert.

Und da muss man quasi definieren,

welches Protokoll reden wir miteinander und

mit welchen Feldern und welchen

Datentypen wollen die denn haben.

Und im Grunde ist,

also das ist jetzt wieder,

aus mir spricht dieses Buch,

ist der

interessante Teil gar nicht darum, wie man das jetzt

technisch umsetzt oder so, sondern im Grunde

ist die interessante Frage.

Naja, also man hat halt

Abstraktionen. 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 Tende ist halt versteckt.

Und deswegen hat man nur 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 daran 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, also 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, im Gegensatz

Ja, gut.

Das heißt, wenn wir in den Registern rumspringen wollen, wenn wir irgendwie

ein Web-Server schreiben, ist das schon mal gar nicht so schlecht.

Ja, das ist ja schon eine Hochsprache.

Ich habe da tatsächlich ein ganz schönes

Beispiel. Ich hatte letztens

eine sehr undankbare

Aufgabe. Ich sollte in einem

Projekt

bei

also quasi

eine Sache, die sich durch das gesamte

System gezogen hat, das hat relativ viel mit

mit Zeitberechnung zu tun, also wo irgendwelche Tage und irgendwelche

Uhrzeiten Tage berechnet werden. 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 Feiertage je nachdem, wo halt jemand dann ist, also wie das Zeitberechnungssystem.

Und das hat halt wirklich querbeet

und Jochen unterhalten sich über die Programmiersprache Python

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,

ich habe das ganze Ding

umgebaut, ist ja auch eine Art von Refactoring

eigentlich, nur dass es halt in dem 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,

dass ich halt die Methoden austausche.

Und das war, es hat mich

selbst total überrascht, wie gut das funktioniert hat.

Also das hätte ich mir selbst nicht zugetraut,

dass die Idee dann doch so gut trägt.

Ja.

Ja, das ist super, wenn man so eine

High-Level-API hat, die man gut bedienen kann, das ist schon

echt was wert. Ja, also genau

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

klein ist, ist das auch gut. Also je kleiner die API

und tiefer, je kleiner und tiefer, desto besser.

Genau, du kannst mit einfachen Worten

viel erreichen. Ja, also

als sozusagen Beispiel für

das ist irgendwie eine schöne API

und Jochen unterhalten sich über die Programmiersprache Python

und das war es eigentlich schon fast.

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

Ja, doch, wahrscheinlich.

Aber stimmt, genau.

Und ja, es gibt noch

IOControl. Also wahrscheinlich Read und

Write oder so, aber ja. Was ist IOControl?

Ja, man kann jetzt noch Spezialoperationen machen.

Da wird es dann auch allmählich hässlich.

Aber tatsächlich eigentlich so mit

Pfeil aufmachen, irgendwie drin rumseeken,

lesen, schreiben,

kommt man halt schon sehr, sehr weit.

Und

ja, das ist halt eine schöne

eine schöne Abstraktion, während zum Beispiel die

Abstraktion,

das ist dann so ein Negativbeispiel gewesen,

halt so, wenn man jetzt in Java

irgendwie Dinge lesen will

aus einem File, dann macht man erstmal irgendwie so

einen Input-Reader auf und dann macht man so

einen Buffered-Input-Reader auf, wenn man das vergisst, hat man ein Problem,

das 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 I.O.

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 ist super flach. Also sowas wie in Python

with open file name is file

file.read.

Genau, oder ja, for line and file

oder sowas. Das ist halt irgendwie

und das macht halt auch per Default

alles richtig. 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 es sich

anders verhält.

Aber genau, das ist halt gutes

versus schlechtes API-Design quasi.

Und

ja, aber

die richtige API für ein Problem,

das man hat oder ü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 das einer der Erfinder, der irgendwie gesagt

hat am Anfang so, ja, eigentlich kenne ich

Programmiersprachen eigentlich gar nicht aus und ich wollte eigentlich auch

Sprache machen, aber hey, jetzt bin ich ja irgendwie

und wir müssen jetzt irgendwie das wieder retten.

Ja, aber ich meine,

es ist schon einen langen Weg gekommen

sozusagen, also mittlerweile ist der

PHP-Kurs. 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,

und Jochen unterhalten sich über die Programmiersprache Python

also das wäre jetzt sozusagen, wie ist eine Sprache

designt, da die richtigen

Abstraktionen zu finden, auch super schwierig

und da würden ja 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

dieses dynamisch getypte

das ist alles nicht gut

irgendwie statisch getypt, bestes getypt

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.

Ja, aber Typisieren ist auf jeden Fall

anstrengender, wenn man halt einfach mal

sowas schnellstens hinhotzen muss. Ich habe heute

eine kurze Übung in Rust geschrieben,

weil das ist einfach halt, du musst halt jedes Mal

an jeden kleinen Witzel dran schreiben, 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 in der Benutzung will man ja,

dass es eigentlich stimmt.

Im Reißen ist es halt dann 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.

Das ist auch unbedingt eine Folge.

Ich habe jetzt erst

vor kurzem damit angefangen, mich so ein bisschen zu beschäftigen,

bevor ich dachte, ich soll auch

Type Annotation schreiben.

Keine Lust.

Mich interessiert das alles nicht. Ich bin ja nicht

deswegen zu Python gegangen,

damit ich überall

Typen dran schreiben muss.

Aber

Ja, aber mit FastAPI, obwohl das wir übrigens auch noch eine Folge machen,

das ist cool benutzt,

aber dann macht das sogar dann Dinge, wenn du die Typen

verwendest und so. Ja, ja, ja, ja,

also, 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

für den statischen Typchecker.

Ja, aber natürlich,

Genau, das ist halt so ein Problem beim Sprachdesign. Will man jetzt Typisierung haben oder nicht?

Weil natürlich fängt es halt Bugs. Ich habe das jetzt auch gemerkt. Ich mache das seit einiger Zeit.

Mache ich auch FastAPI und habe jetzt auch, dachte 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,

oh, da hat mir jetzt, ich lasse noch MyPy drüber laufen, wo mir dann MyPy auf die Finger haut oder halt eben PyLens oder was auch immer.

und Jochen unterhalten sich über die Programmiersprache Python

und Jochen unterhalten sich über die Programmiersprache Python

und Jochen unterhalten sich über die Programmiersprache Python

tatsächlich weiß, warum und welche Typen man da hat.

Und wenn man das irgendwie sicherstellen kann. Und das geht halt

mit Python 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

die Lösung auch in Rastor in Google 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.

Ist aber auch, glaube ich, eine super Sache,

wenn man

so interne APs hat, also entweder

wenn man irgendwie so

und Jochen unterhalten sich über die Programmiersprache Python

dann direkt anzeigt, nee, nee, du machst

die App mit Birnen. Das ist einfach super praktisch.

Und umso tiefer das bei mir drin ist,

umso mehr versuche ich auch dann, welche Type-Ins

zu machen. Ja, mit dem Dann ist halt echt ein Problem.

Aber,

ja, da fällt mir auch

gerade noch so eine Anekdote zu ein.

Da gibt es noch

ein Buch, JavaScript, the good parts,

glaube ich, auch ein relativ bekanntes Buch. Das muss halt dünn sein.

Das ist tatsächlich relativ

dünn. Da gibt es doch diesen Witz mit dem dicken

Buch. Genau, die

Reference, das ist irgendwie zu tausend Seiten und dann irgendwie Good Parts ist halt irgendwie so ein Häppchen, ja, das stimmt.

Und der Ausser 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,

naja, also irgendwie diese, ist eigentlich kein Wert oder ist irgendwie nix,

Dinger sind ein Problem bei Sprachen, ja, also Python halt none,

gibt's halt ein Ding und es ist halt immer wieder in diesem, wenn man sich über so

Standardisierungsfragen, ist aber 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 da eine große Rolle, ja, wenn man jetzt

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 fies Probleme. Und

ja, er meinte da so, ja, also es ist immer so,

unter Leuten, die sich mit

Sprachdesign beschäftigen, und fragen, will man sowas in der Sprache

haben oder nicht? Und dann gibt es immer so

einen einen Teil der Leute, die sagen, ja, doch,

ist eigentlich schon gut, wenn man das hat. Ein anderer Teil sagt, nee.

Aber absolut niemand, absolut niemand

vertritt die Ansicht, es ist voll gut,

zwei davon in einer Sprache zu haben.

Und da was gibt, hat halt zwei.

Null und undefined. Und das ist halt wirklich

ah, ja.

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 zirkuläre Importe

oder sowas, das ist ein bisschen nervig.

Nee, die Annotationen.

Da kannst du auf das Problem natürlich auch

stoßen, ja klar.

Oder leichter.

Aber ich meine, 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

Typ-Annotationen einfach bleiben sollen, dann

muss man halt irgendwie das auf so relativ

primitive Datentypen runterbrechen

und kann dann eigentlich auch nur noch so relativ

primitive Datentypen verwenden.

Ja, man will ja eigentlich schon komplexere

Daten, also so ein Pathentic-Objekt oder

sowas hinten. Ja, gut, okay.

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

Und es sieht überhaupt nicht mehr aus wie Python eigentlich.

Das ist halt irgendwie doof

aber wenn man jetzt Python

idiomatisch schreibt, so Pythonisch

irgendwie, dann

wird das mit den Typ-Annotationen

ziemlich schwierig, also weil zum Beispiel

so eine, da gab es letztens auch eine

Podcast-Episode mit

Luciano Ramaglio

der hat für Python geschrieben das Buch

kann ich nur empfehlen, gibt es jetzt

im Frühjahr kommt eine

zweite Ausgabe, zweite Edition

Second Edition

wo er auch viel über Type-Annotationen

und so schreibt und

der hat

sich das auch dann halt mal

so richtig angeguckt und so und hat dann

die Typ-Annotationen für

die Max-Funktionen sich angeguckt

und das Problem bei Typ-Annotationen

ist jetzt auch, die können ja auch falsch

sein, die können ja richtig sein falsch sein, die können uns

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, sollte 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 MyPy oder so,

da hast du was falsch gemacht und ich sage, nee, das ist eigentlich schon richtig,

aber ich habe es irgendwie falsch hingeschrieben.

Und bei einer Funktion wie Max ist das halt extrem schwierig

und hat halt in den Type-Annotationen dafür halt Fehler gefunden, eben false positives, false negatives

und hat halt versucht, das richtig zu machen.

also es gibt irgendwo TypeShed 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 MaxLen und so, die halt

schön sind irgendwie, weil du kannst halt

es ist eine sehr generische Funktion, du kannst da alles reinwerfen

und es macht eigentlich immer das Richtige

aber das jetzt zu annotieren

ist halt die Hölle

also er hat dann irgendwie

die eigentliche Implementation von Max

sind halt irgendwie so 25

Zeilen oder so und

und allein die Typ-Annotationen waren hinterher, du musst halt sechs Overloads dafür definieren, der Funktion,

und es waren viel, viel mehr Zeilen in den Typ-Definitionen als hinterher in der Annotation.

Und dann ist natürlich die Frage, und es war sehr schwer zu verstehen,

und also irgendwie diverse subtile Fehler drin,

also dann ist halt die Frage, okay, wenn das so schwierig ist, die Typen hinzuschreiben,

macht das dann, ist dieses Verhältnis zwischen, und es ist halt auch sehr schwer zu lesen,

also ist halt die Frage

ja, ist das

dann wert noch?

Ja, das ist halt so

die Frage

und das gibt es genauso

das war auch was, der im Podcast hat

da meinte er so

es gibt denn sozusagen

ein Buch zu Java

ich habe vergessen welches

das ist, auf jeden Fall ist auch einer

der in der Sprache mitgearbeitet hat oder so

der schrieb dann halt zu, als die Generics eingeführt wurden

selber

sagt er dazu, also die Generics waren ein

Desaster in Java

und es gibt diverse Geschichte

Konstrukte, die sie da gemacht haben

wo sie dann gesagt haben

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, wenn man es nicht mal verstehen kann

kann. 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-Annotationen zu machen.

Und das hat ja schon in

diversen Sprachen zu Katastrophen geführt. Also bei

C++ mit den Templates, ja, ganz

furchtbar, es ist 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-monetieren. 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 es, also da kannst du, du kannst tatsächlich

solche Sachen machen wie...

Du kannst rekursive Typ-Definitionen

machen, das geht.

Das kann gut sein, dass das in Python nicht geht.

Also die Type-Definition für

ein JSON,

wo dann hinterher der TypeScript,

der TypeScript-Compiler auf die Finger haut,

wenn du da auch bliebig rekursiv

irgendwo etwas reinschreibst, was jetzt nicht mehr

wirkliches JSON wäre, wo du eine rote Klingel

kriegst, das sind so 25

Zeilen rekursiv type-unautotationen

in TypeScript. Das geht. Und das ist natürlich

schon sehr cool, dass das geht. Auf der

anderen Seite,

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

schwierig.

Ja, da können halt rekursiv

irgendwelche Dinge drin, irgendwelche Listen drin liegen,

irgendwelche Dicks drin liegen, irgendwelche Listen drin liegen, wo vielleicht noch ein Zwingl ist

0 oder irgendwas.

Ja, es ist halt wieder eine Sprache für sich,

also allein schon, dass du

in Type, dass du halt sagst,

okay, es gibt ja eben diese

Generics, sag ich mal, es ist ausweichlich,

du kannst halt nicht nur,

du definierst die Typen nicht fix,

sondern du sagst halt, also

du kannst jetzt in der Funktion

sagen, welchen

Typ du zurück erwartest und

den dann als Typ-Annotation verwenden.

Du kannst also Typen parametrisieren,

die du irgendwo setzt. Du kannst eine generische

Funktionen 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 man das vielleicht ein bisschen refactoren Naja also es wird halt ich meine es ist schon cool auf der einen Seite finde ich es voll cool dass es geht auf der anderen Seite denke ich mir so mein Gott was haben wir getan Wir haben einen 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 benutze ich das einfach nicht, weil es einfach keinen Sinn macht.

für so ein Int oder String, okay,

aber 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 3.8, glaube ich, dazugekommen, 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, also Protocols

sind immer so kleine 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 es

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 reflektieren, dass man

einfachere Dinge macht, wie zum Beispiel nach Strings

realisieren oder sowas.

Nee, 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

also außer, du machst halt

es ist halt schwer, die zu amperieren.

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

Von daher vielleicht. Ja, genau. Und vielleicht ist es für die Fälle

einfach nicht typisieren,

sondern sagen, okay, wir machen es an den Stellen, wo es halt was bringt

und nicht so gerne Arbeit ist und an den Stellen, wo es

halt nicht gut geht, dann lassen wir es halt weg und dann schreiben wir halt

eine generische Funktion.

Magic Python.

Genau, ja, das ist vielleicht irgendwie so der richtige

Weg.

Wir kommen hier zu Tyson.

Ja.

Eine Sache, die mir noch aufgefallen ist,

jetzt in

den letzten Monaten beim

Arbeiten bezüglich Refactoring,

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 in meinem Beispiel relativ viel Businesslogik 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 Online-Shop, da kann irgendwer was 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,

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 man sich eine E-Mail und hat irgendwie ein 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 ein schlechtes Pattern oder

keine Ahnung, das ist nicht

lindkonform oder keine Ahnung was, dann geht man hin

und refactors halt, weil das schreit einen quasi an,

dass das hässlich überzumalte ist.

Das ist ein Code-Review, weil man relativ sehen kann,

wie gesagt, Kommentare stimmen nicht,

oder Docs sind falsch, oder es sieht hässlich aus,

es ist zu lang, man kann es so ein bisschen umbauen,

Namings sind komisch, dann kann man das schnell machen.

Genau, aber so eine Sache, wenn man sagt, okay, ich habe jetzt 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 Datenstruktur ist.

In der Phase, wenn man auf Services ist, müssen wir auch nochmal darüber reden, was das eigentlich ist.

Aber wenn halt irgendwann dieser ganze Business-Prozess halt nicht mehr offensichtlich ist, da muss man halt 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 Finance-Welt-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 Packet 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 haben wir länger drüber gesprochen, das ist bei YouTube

Vielleicht nochmal ganz kurz erklären, was ist denn

eine Finite State Machine?

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 spreche ich am 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.

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

So könnte man sich jetzt vorstellen, ja.

Und der Vorteil

an diesen, also das ist nur eine von vielen

Möglichkeiten, um sowas anzugehen und wir haben das

ausprobiert und es hat wirklich, wirklich gut funktioniert.

Weil das Schöne ist, diese

Graphen sind sehr, also

die werden natürlich auch immer komplexer, wenn man halt

und Jochen unterhalten sich über die Programmiersprache Python

oder so.

Und dann hat er gesagt, okay, ich habe einen Flow und hier definiere ich jetzt genau, was

passiert, wenn Auftritt von offenen Bearbeitungen geht.

Zum Beispiel, da geht eine E-Mail raus oder da geht keine E-Mail raus oder da muss jemand

irgendwas machen damit 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 hinreichend komplexes 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 dann ein wunderbares PDF raus, kann darüber dann dem Kunden reden

welche Pfeile sollen wir jetzt umbiegen und wo soll was anders passieren.

Und das ist halt wirklich auf einer ganz anderen Ebene.

Das ist halt so trivial.

Ich bin eher schockiert, dass ich da so spät drüber gestolpert bin.

Ich glaube, was eigentlich schwierig ist, ist tatsächlich diese Dinge aufzumalen.

Weil ich glaube, selbst die Kunden kennen nicht immer ihren Flowchart.

Weil die halt nicht wissen, was passiert denn da.

und bevor sich das nicht 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 bei uns hat das

einen ganz bösen Bug geführt.

Ja, die Tests waren eigentlich ganz gut.

Also die haben eigentlich das getestet, was getestet werden soll,

das heißt, Carbide war hoch, aber es gab halt

den Fall einfach nicht. Und das führte halt einfach dazu,

dass fälschlicherweise beispielsweise, wir haben so

viel im Endquatsch gemacht, an

ein paar hundert Vertriebler einfach so E-Mails rausgingen,

die gar nicht rausgehen sollten oder so, oder zu oft.

und du hast halt so ein bisschen so ein, okay,

ups, und das

schreit halt dann, weil man denkt sich halt so, nein,

wie können die nur und total doof und das macht ja gar nicht

was, was soll, alles falsch. Aber eigentlich

ist halt nur der Fall, dass man halt nicht bedacht hat, dass

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 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, also der

Stakeholder 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-Techies halt

quasi weg.

Dann nicht mehr einsehbar.

Und als Entwickler, natürlich sollte

man das grob verstehen, wie du halt gesagt hast,

das System ab einer gewissen Hinreichung an 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.

und vielleicht muss ich das wissen für meine Sache,

weil es irgendwas gibt, was halt noch keiner weiß.

Ja.

Vielleicht nochmal ein Definitionsding.

Finite State Machine.

Deutsch ist endlicher Automat.

Genau, also einen endlichen

Automaten kann man quasi auf alles dann abbilden.

Was ja mit unendlichen Automaten geht, du weißt auch.

Nein, 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äre Ausdrücke, je nach Implementation,

und da gibt es auch noch ein bisschen mehr, was man da machen kann,

aber das ist halt, ja,

also

wenn man endlich

einen Automat hat, die Sprachen,

die, also jetzt komme ich

in die theoretische Informatik,

vielleicht rede ich 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 dem 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, aber

du kannst damit nicht alles machen.

Zum Beispiel, was du damit nicht machen kannst, sind halt

so, also das ist

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

parsbar ist. Normalerweise nimmt man dann

irgendwas, wo es so Klammer gibt. Dann hast du 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 Lemmon heißt das.

Das kann man dann benutzen, um zu zeigen,

dass man

keinem endlichen Automaten das parsen kann,

weil man sich nicht merken kann,

wie das...

Dafür braucht man dann halt so einen Stack-Automaten oder

irgendwie sowas.

Was ist ein Stack-Automat?

Ich kenne keine theoretische Informatik.

Was ist ein Stack-Automat?

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

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

Okay.

Warum ist das Ding Automat?

Ja, ich weiß gar nicht.

Methode mit Maschine, vielleicht auch, ich weiß es nicht genau,

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

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 endlichen Automat nicht machen. Da hast du halt Zustände,

die sind endlich und du kannst zwischen

denen wechseln, aber du kannst dir jetzt nicht merken, wo du

schon überlang gelaufen bist oder so, oder ob du Klammern aufgemacht

hast oder nicht. Das geht halt nicht.

und genau, das nächste

also, gehen wir mal die Dinger

durch

das zweite ist halt dann sozusagen Stack Machine

damit kannst du halt dann kontextfrei

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 While-Programm oder ein For-Programm

oder was auch immer. Okay, also nochmal jetzt vielleicht

zum Abschließen, was eine Turing-Maschine ist.

Oh Gott,

eine Turing-Maschine, ein Siebentuppel aus

Sprache, Grammatik,

Terminalsymbolen, Nicht-Terminalsymbolen,

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 gab es das Paper, glaube ich.

Von Neumann Architektur?

Nein, nein, nein.

Was ist das?

von Neumann Architektur ist, dass

der Speicher für

Daten und Programme der gleiche 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 Problem

nicht entscheidbar ist.

Also, ja, und genau,

das hat eigentlich die Informatik begründet.

Beziehungsweise

es gibt da halt noch irgendwie

ein Paper-to-Lambda-Kalkulus

von Church, das ist ein bisschen später rausgekommen,

ist eigentlich ein Stückchen eleganter, aber

ja.

Ja, aber genau, also

Typ 0 Sprachen,

also mit einer Turing-Maschine kannst du halt alles

parsen, was du auch parsen kannst.

Und 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 es nicht.

Vor allem in meinem Case ging es ja wirklich auch

tatsächlich um Business Flows.

Ja.

Ich glaube,

das Interessante an Business Flows

ist, weil das halt wirklich eine Sache ist,

man muss ja dann im Endeffekt

und Jochen unterhalten sich über die Programmiersprache Python

der spannende Punkt, warum da halt

zum Beispiel, ich meine, es gibt doch bestimmt noch 50

andere schlaue Ideen, wie man da 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 den ganzen normalen Code

programmieren würde, glaube ich, da kann man sich sehr

viel Knatscher sparen und

hat bestimmt

zwei, drei Jahre Entwicklungszeit Entspannung

vom

also quasi

ein bisschen Schutz vor

tiefgreifendem Refactoring.

Ja.

Nee, klar.

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

als wenn jetzt jemand anders das

benutzen muss. Und wenn man

seinen Krug in einen Zustand versetzt, in dem er

gut übergiebbar ist, dass jeder

damit arbeiten kann.

Ja, wobei man da ein bisschen vorsichtig sein muss.

Ich meine, da geht es

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,

wenn es mir gefällt.

Taste kann man nicht schreiben.

aber

das Problem ist halt, das habe ich ja auch

eine eigene Code-Ankunft, die einem selber nicht mehr gefällt.

Ja, aber wenn man so in Code-Basen

guckt, die es da so gibt und sich denkt

so, oh, das ist alles ganz schrecklich, dann habe

ich so den, dann zuerst fängt

das Augenlid an zu zucken und dann irgendwann

lasse ich Black über

alles drüber laufen.

Ja, ich kenne das aber auch von Jochen, das ist mal ganz

super, also er hat ja immer netterweise

ein paar Sachen von mir mal korrigiert und so

und ganz am Anfang so, äh, was ist das denn, das geht ja überhaupt

nicht, alles wegschmeißen, neu machen, nee, nee, kann man nicht

wieder angefangen, neu gemacht und das ging dann so ein paar Mal so, ah, wieder wegschmeißen,

und dann irgendwann hat er gesagt, ah, was ist denn das, das ist ja das, was er alle wissen will,

wieder neu machen, weg, ja, das habe ich von dir kopiert.

Ja, das mag sein,

das ist vollkommen sowas.

Ja, ja, ich meine, manchmal ist es auch einfach Quatsch,

da 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

oder so, man muss aufpassen, das ist nicht so einfach.

Aber, genau, also,

Also ich tendiere dazu, das dann so zu machen. Ich glaube aber, es ist falsch. Und eben auch da das Buch würde sagen, 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.

und Jochen unterhalten sich über die Programmiersprache Python

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. Das ist ja generell auch ein Problem,

dass wenn man jetzt

ein altes, gewachsenes Projekt hat,

dass man dann vielleicht im schlimmsten

Fall übernimmt oder 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 dann halt, okay, machen wir irgendwie so,

und so. Hier fü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 vor lassen.

Also ich habe tatsächlich mal jahrelang auf dem

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 Code-Basis war

wirklich, wirklich schlimm. Da gab es nie irgendjemand,

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 schnell

eine Feature abzuliefern und danach mit diesem Flut.

Böse, ich meine, nicht bei allen, aber

es gab auf jeden Fall Leute und wenn du halt einen so im Team

hast, dann ist es halt schwierig.

Ich habe einen Freund, einen Entwickler aus

Malawi, der halt so versucht,

günstige Aufträge heranzubekommen und weil die

Kunden, die er hat, dann relativ wenig Budget haben und immer

ausgeben, merkt man halt auch, welche Entwickler sich

dann leisten können und wenn er halt

dann so sieht, so die Leute, die

von denen er das aufräumen muss,

weil er 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 und unheimlich viel Spaghetti-Zeug

und das dann neu zu machen, also die

Arbeit, die er hat, ist die ganze Zeit

am Limit und weiß überhaupt nicht, was da passiert

und es ist unheimlich schwierig, das besser zu machen und das

zu refactoren, aber ich glaube, da ist dann

gotische Knoten besser gelösen,

indem man manchmal tatsächlich dann durchschneidet

oder halt einfach verbrannte Erde hinterlässt

und das neu anfängt oder so.

Also es gibt es auf jeden Fall, aber

es ist ja leider,

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

teilweise 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, okay, es geht nicht mehr,

ja, weiß ich nicht, ein Formularen passend 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 häufiger Fall,

in der Sonderwende, 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 reflektiert,

das ist super wichtig, dass man, also vor allem, ich finde

in solchen Fällen das Einzige, was einen irgendwie motivieren

kann, an diesem Projekt zu arbeiten, dass man

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, das war

halt einfach eine Kette von Skripten, die

eingebunden wurden, eine N-lange

Niemann wusste genau, was da oben kommt und was unten kommt. Du hattest keinen Variatenscope.

Das kann man sich nicht vorstellen, was das für ein Segen ist, dass man einen Variatenscope hat.

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

ich habe mir im Endeffekt Django Class-Based Views in klein 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,

da war ich in zwei, drei Tagen durch. Das war jetzt echt nicht viel Arbeit.

jedes Mal, wenn ich halt an irgendeinem

View dran war, also View in Gänsefüßchen,

letzte Skript der Reihe,

habe ich halt dann einfach,

okay, jetzt stelle ich das einfach um, habe ich mit meinem Kunden

noch abgesprochen, das hat dann auch meistens

nicht rasend viel, weil es meistens nur einsortieren war.

Ich habe gar nichts im Code wirklich gemacht, aber

da ich dann plötzlich Scope hatte, konnte auch die

IDE plötzlich mit Variablen arbeiten,

hat einem plötzlich zum Beispiel gesagt, ey, da ist ein

ganzer, weiß ich nicht, 100-Zeilen-Zweig in

diesen Dings, die Variable wird gar nicht gesetzt,

die kommt nirgendwo her,

das kann man einfach rauswerfen, ja,

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 auch nicht, wie ich überhaupt anfangen soll aufzuräumen.

Ja, so unterschiedlich ist die

Ich habe auch da gehört

Also es gibt Leute auf der Welt, die programmieren unterschiedlich

Zum Beispiel, ich habe jetzt

von einem Freund gehört, der mit

Ukrainen 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 auf internationalen Vergleich

da irgendwie gucken, wie das dann so 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 halt nur genau Definition, das heißt du brauchst

ultra lange, wenn du mit dem zusammenhäufst, um diese Definition

aufzuschreiben, weil alles, was da

nicht drin steht, das wird halt nicht gemacht.

Das ist halt blöd.

Oder die halt diese Abstraktions-Levels

nicht benutzen. Also mit

auch Firmen aus dem anderen asiatischen Raum, wo du

halt dann da stehst und

anstatt, dass du so ein Pattern jetzt halt hast

und eine abstrakte Klasse, dass du schreibst,

werden halt alle 100

einzelne Möglichkeiten einzeln implementiert.

Und dann so, ja, kommen ja noch weitere, ja,

900 dazu, irgendwie vielleicht mehr

im Abstraktionsniveau sinnvoll. Nur, nur, die 900

machen wir dann auch ganz schnell.

So halt, das ist halt dann schwierig.

Also wenn man das halt dann refactored, dann ist halt

unheimlich viel Fleißarbeit auch dann, ne?

Wie man das irgendwie dann versucht, so

modulisieren, auseinanderziehen.

Ist Refactoring auseinanderziehen

oder Extraktion? Ich weiß nicht.

Ich glaube, es hat viele Facetten, oder?

Ja, aber...

Ich würde sagen, eben,

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, so wie BGSA vielleicht auch.

Genau, wenn du das

so implementierst, also nehmen wir

diesen Fall, 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.

Wir sind schon wieder bei Son of Python

und können jetzt hier die Liste wieder runter bieten.

Was hast du da zu tun?

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 die jetzt halt einfach von Hand

gesetzt in allen Seiten.

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.

Ja, aber gerade das, also es gibt ja so Sprachen, wo das nicht ging,

zum Beispiel mit Variablen setzen oder so was,

also in HTML oder alten CSS oder so was,

waren Variablen ja nicht so einfach zu setzen.

Keine Ahnung, ich weiß aber auch nicht,

zu beziehen.

Das war 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,

da sind ein paar hundert Stellen, wo das auftaucht

und die Farbe ist aber immer dieselbe.

Wie kriegst du denn jetzt raus, was war jetzt vorher 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 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

anderen Sachen, die von allen Abhängigkeiten her auch anfassen.

Und die zweite

Geschichte ist

Obscurity.

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

Undurchsichtigkeit. Undurchsichtigkeit,

Nebel

Obskurität

Unklarheit

Unklarheit vielleicht, ich weiß es nicht

Jedenfalls, das ist halt

das passiert, also

das sorgt halt für noch schlimmere

Probleme, das sorgt für so unknown

unknowns, dass du halt gar nicht

also wenn du viele Abhängigkeiten

hast, 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, aber wenn du, genau, zum Beispiel

nehmen wir an, du hast jetzt diese eine

Abhängigkeit, die sagt, wenn du die Hintergrundfrage

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 der

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 in der Stelle falsch?

und dann kriegst du das sozusagen als Bugs wieder zurück,

was du nicht wusstest dass es diese Abh gibt aber die war halt nicht dokumentiert Das sind die schlimmsten weil das Problem ist halt

du weißt halt gar nicht,

dass du das eigentlich hättest machen sollen.

Ja, 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 her und oft ist es halt vielleicht

Dokumentation. Das ist auch etwas,

das fand ich nett,

dieses Buch hat meine Einstellung zu

zu Kommentaren und Dokumentationen so ein bisschen verändert.

Jochen schreibt übrigens nie Dokumentationen.

Nein, das wäre

nie zu hart.

Der Code erklärt sich selbst und so.

Ja, okay.

Aber tatsächlich, ich würde auch sagen,

es gibt ja da unterschiedliche Ansichten zu.

Auch verbreitete,

wenn man mal so Klingcode nimmt, auch ein Buch, was sich

mit solchen Themen beschäftigt,

von Robert Martin, Uncle Bob genannt,

der sagt ja immer,

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, ist es im Grunde

ein Fehler, also es ist im Grunde ein Versagen,

hast versagt, 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. Ja, genau, das ist

schon doof, also man muss halt echt schon auffassen,

aber es ist einfach an vielen Stellen sehr, sehr

hilfreich, auch gerade wenn man kollaborativ arbeitet,

einmal kurz hinzuschreiben, was denn da

passiert, warum denn da irgendwas passiert.

Ja, absolut.

Anstatt das halt einfach nicht zu machen, weil dann die Leute fragen sich ja,

da wird irgendwo schon auch gucken, warum?

Selbst wenn der Name toll ist und so.

Ja, absolut.

Ja, ich muss auch sagen,

genau, dieses Buch hier nimmt das auch

relativ

detailliert auseinander.

Und da sagt er 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 handelang

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 die verwendest

Das ist ja auch Quatsch, das ist ja auch offensichtlich Quatsch, das kann ja nicht sein

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

Und hat halt noch so viele Punkte, aber der allerwichtigste Punkt eigentlich, wo ich dann auch gesagt habe, okay, ich glaube, ich muss meine Einstellung dazu überdenken und es vielleicht mal anders probieren

und mal gucken, vielleicht funktioniert es dann ja anders besser.

Ist, äh, das ist ja,

also eigentlich das,

was dein Code tut, ist

eigentlich, oder 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

Magie, äh,