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
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,
Call Magie, Call Magie, Call Magie, und aber
was dabei rauskommt, ist wichtig.
Die Abstraktionen sind wichtig und die
stehen aber, aber Code ist
möglicherweise gar keine so gute Art, um das
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. Dann schreibt man in natürlicher
Sprache hin. Und wie man das dann implementiert,
ist ja nochmal eine andere Sache.
Weil Python, finde ich, von meinem
Empfinden her, ich habe 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 das irgendwie stimmt.
Pythonic 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 so, eigentlich nie.
Ja, naja, es gibt da ganz unterschiedliche Philosophien.
Ich finde das sowieso auch interessant.
Bei Go zum Beispiel gibt es auch bekannte, ich weiß jetzt nicht mehr, wie der Talk ist,
aber einer, der auch die Sprache mitdesignt hat,
der ist halt ein Verfechter von
kurze Variablen Namen nehmen.
Ja, aber letztens irgendwann...
A, B, C, D und E.
Ja, also
ja, also es ist nicht immer gut.
Es gibt auch einen auf der Frostcon,
da hatte ich letztens einen getroffen, der hatte
einen sehr extremen Standpunkt und meinte, das muss mal lang sein.
Kurze Variablen Namen, schrecklich.
Ganz furchtbar, geht gar nicht.
Das ist schrecklich.
Manchmal ist das schon nett, also gerade wenn man jetzt
komplizierte Logik hat,
ja, dann kann das sein, wenn man lange Variablen
und stehen einem wie variablen Namen 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 ausschreiben würde.
Was ich dann manchmal mache, an der Stelle tatsächlich
vorher die Zuweisung, zum Beispiel
Idee gleich Data vor irgendwas
und dann mache ich dann nicht immer Data vor irgendwas,
sondern nur das D.
Dann wird das so ein bisschen dadurch klar.
Ja, genau. Und da macht
das Buch auch einen interessanten Vorschlag und sagt so,
Der Name sollte umso länger sein, je weiter weg die Variable von ihrem ursprünglichen Ort, wo sie mal definiert wurde, verwendet wird.
Je weiter das weg ist, desto länger muss der Name sein.
Aber je näher du da dran bist, dann kannst du auch kürzere Namen nehmen oder sehr kurze.
Weil dann ja immer noch alles im Blick ist.
Du siehst halt, was da passiert sofort.
Also Readability counts, das ist ja auch wieder so eine Sache, außer noch Python.
Naja, also
ja, schon faszinierend.
Genau, aber auch sowas,
Obscurity kommt halt auch,
ein sehr schönes Beispiel beschrieben,
wo Variablen Namen
an böse, böse
Überraschungen bescheren können.
Also der Autor von dem Buch,
der hat TCL mal dieses Ritting Language
geschrieben, also diese Sprache designt.
Vielleicht kennt man das auch von früher,
da hat man so User Interfaces
damit gebaut in Unix
TickleTK
Ja, das gibt es ja
Genau, das ist die Python Geschichte
mit Python kann man das auch machen, das ist die einzige UI-Geschichte
die in der Standard-Bibliothek drin ist
und der hat aber noch
diverse andere, der hat zum Beispiel einen
Cloud-Dings gebaut
quasi verteiltes Betriebssystem
und ganz viele
coole, interessante Dinge
und in diesem
Dings gab es ein Fallsystem
und in der Fallsystemimplikation gab es
eine Variable, die hieß Block.
Und da hatten sie einen ganz fiesen
Bug, wo sie Monate
gebraucht haben, um den zu finden.
Und der lag dann letztlich daran,
dass das dann diese Obscurity tatsächlich
so schlimm macht, der lag daran,
dass sie Block subtil unterschiedlich
in der Bedeutung verwendet haben. Also sie haben
Block als Variablen-Namen benutzt,
aber in dem einen Fall bedeutete er
und Jochen unterhalten sich über die Programmiersprache Python
und das lag halt einfach daran, dass der Variablename
halt zu generisch war.
Sie können halt zu generisch sein, sie können aber auch zu speziell sein.
Ich meine, keine Ahnung, der Java-File-Input-Buffer-Stream-Schlag-mich-tot-Reader
ist halt auch irgendwie dann nicht mehr so der Sinn.
Das ist auch nicht so schön.
Ja, aber das ist vielleicht geschmacksfrei, vielleicht auch anwendungsfrei spezifisch.
Ich glaube, eine Sache, die man ganz generell festhalten kann,
ist, wenn man irgendwas refactoren möchte,
und Jochen unterhalten sich über die Programmiersprache Python
mit dieser Oracle-Implementierung,
wo die dann auch gesagt haben, das Ding war irgendwie dermaßen alt und verbuggt,
dass die dann quasi alles komplett mit Unit-Tests zementiert haben.
Also jeden Bug und jedes merkwürdige Verhalten, das das System hatte,
haben die mit Unit-Tests zementiert.
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.
Also teilweise war es wohl auch so in der Community,
dass die Leute halt auch 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 auch...
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. Das macht keinen Spaß.
Ja, aber das mit den Tests ist auch
ein gutes Stichwort.
Das ist halt auch so. Also natürlich, es gehört
dass man Sachen testet und das 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 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.
Das kommt nochmal an, also ich glaube, wenn man selber
schreibt und wenn man weiß,
was man tut.
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 Testcase
so das Ergebnis hat.
Zum Beispiel, du hast halt einen
Datensatz und du kennst das Ergebnis, das heißt, du machst
einen Beispiel-Datensatz und 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?
Dann kannst du den Methoden schon die richtigen Namen geben,
die du dann irgendwie füllen musst,
die am Ende rauskommen sollen,
wenn das jetzt nicht zu komplex ist.
Und dann kannst du das implementieren.
Und wenn das für dein Testcase stimmt,
wirst du ziemlich sicher sein,
dass das auch für die anderen Fälle laufen sollte.
Ja, aber...
Das ist halt so ein TDD-Fall,
wo ich sagen würde, das kann dann ganz gut sein.
Du kennst quasi...
ein Test-File.
Du kennst den Test-File, du kennst halt den Test-File,
du weißt den Test-Case, den kennst du schon,
du weißt, okay, das sind meine Test-Daten und du weißt,
das Ergebnis von dem Test ist so und dann kannst du
dafür dann eine Methode schreiben, die diesen Test-File
richtig macht und wenn du quasi
alle Test-Cases 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 TDDs sind, macht.
Wenn du es aber nicht hast, weil du nicht weißt, ob die Test-Case vollständig sind,
ob du irgendwelche Edge-Cases hast oder sowas,
dann ist es halt super nervig, weil dann
muss ich Testhaus mal umbauen, irgendwas wegmocken.
Aber das ist ja auch Teil des Prozesses,
dass du halt die Tests auch ständig anpackst.
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 Unitests
schreibt, dann schreibt man Code anders.
Und das ist schlechterer Code.
Das ist einfach eine generelle, richtige Aussage.
Und das Zweite ist,
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 ja keinen ungetesteten Code schreiben.
Das ist halt irgendwie natürlich so ein bisschen,
das ist halt schon vielleicht gut.
Aber eben,
es gab auch in der letzten Django-Chat-EP
so, ich weiß nicht, letzte oder vorletzte, keine Ahnung,
da ging es auch um
das Thema Test-Development und auch alle
da meinten so, ja, ganz gut,
ist eigentlich vielleicht nicht so schlecht, aber
der Konsens in der Runde war halt auch so,
naja, also 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 dann mit dem Text 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 ein
interessanten Punkt und sagt halt,
naja, also wenn du
Test-Driven 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 oder Abstraktionen machen und nicht über die Implementierung
und das geht mit
Test-Driven Development gar nicht so richtig.
Und was er dann vorschlägt, ist zu sagen,
doch lieber Document.
Oder
ja.
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 an, das zu implementieren.
Ehrlich gesagt,
also ich versuche das jetzt, mal gucken, keine Ahnung.
Dann die Tests schreiben und dann implementieren vielleicht.
Ja, aber
genau, also ich weiß es nicht so genau,
und Jochen unterhalten sich über die Programmiersprache Python
aus der Implementation. Also dass ich merke so,
okay, an der Stelle mache ich zwei, drei Umstellungen
und dann merke ich so, okay, das ist jetzt alles, jetzt brauche ich ja kein
Objekt mehr, das nehme ich da einfach im Dikt 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.
Aber es kommt halt aus dem
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 den
Dokumentationen 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 zen, sehr zen, sehr zen auf Python.
Ah, ja.
Ja, ich glaube, wir haben
bei Refactoring, ich habe nicht mehr
so viel auf meinem Titel, was ich hätte.
Ich kann mal gerade gucken, ob ich habe, ich habe mir,
was habe ich mir denn aufgeschrieben, was ich dazu noch?
Ich muss natürlich sagen, mein T-Sync kaputt, hatte ich am Anfang schon
erwähnt, aber das ist nicht so schlimm.
Übrigens, achso, genau,
das, was ich mir aufgeschrieben habe,
Red Flag, irgendwie
extensive Dokumentation schreibt er auch, obwohl er
eigentlich sagt, Dokumentation, 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 gut.
Ja, wenn du viel erklären musst, ist nicht gut. Eigentlich sollte es offensichtlich sein,
man sollte es mit wenig...
Also ein oder zwei Sätze am Anfang, was machen das
zu kaufen. Dann muss man die ganze Funktion nicht lesen, wenn das
stimmt. Aber das finde ich
auch so eine Sache, warum ich Typefins gut finde.
Nicht, weil es unbedingt die Typensicherheit alles sicherstellt,
aber wenn ich halt den Funktionsnamen lese,
der gut gewählt ist, die Typefins, die dazu passen,
zu den Parametern, die die Funktion hat
und dann den Dockstring, 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 dir alles genau angucken, sondern ich weiß halt, was sie tut,
und kann zum nächsten übergehen.
Das ist super schön zum Arbeiten.
Ja, das ist dann halt beispielsweise für die gelungene Abstraktion,
wenn du halt sozusagen
der Interface-Dokumentation
schon ansehen kannst.
Also daraus alles erfährst,
was du brauchst, um das benutzen zu können.
Ja, genau. Du kannst also die Docstrings skimmen
und kurz gucken, okay, jetzt mach das und das und das.
Du musst gar nicht so genau den Code dir angucken, dann ist das auch egal,
ob die Leute da so ordentlich gearbeitet haben
irgendwann. Ja, absolut.
Ja, ja.
Ja. Ne, ich habe jetzt gerade nochmal geguckt,
ich habe auch sonst nichts mehr eigentlich, was ich
unbedingt unterbringen wollte.
Nein, bei mir ist auch alles untergebracht.
Oh, wir sind ja schon relativ weit dran.
Wir haben immer viele Leute, die ab dann
abspringen.
Die Meinung
von Leuten, die
das hier durchgehalten haben, wäre
ganz interessant vielleicht.
Und zwar, das war letztens
im Stream, hat dann irgendjemand geschrieben, 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 Slack, aber Slack ist irgendwie...
Wie hat das jemand dann genannt? Ah, Slack ist ja mehr so ein Boomer-Discord.
Ja.
Also Discord habe ich übrigens auch
für meine eigenen Zeugs schon online
einmal und so. Also ja, wir gucken
den Teller an, ist ja kein Problem.
Ja, oder ich meine, welche Plattform sollte man
da verwenden? Discord. Discord, echt?
Weil, also die Firma dahinter
ist auch so ein bisschen unsympathisch, ne? Ja.
Ja, die machen auch so NFT-Kram
und Krypto...
Das sagt jemand, der Werbung
für VPNs macht.
Spoiler, ich weiß nicht.
Ja, es ist alles so ein bisschen...
Ich weiß
nicht so genau. Ja, okay,
Also Discord wäre gut, weil ich meine, dann könnten halt auch Leute da irgendwie mal, man könnte mit Leuten chatten und so, also Leute live, wenn wir machen jetzt noch nichts live.
Ja, das ist eigentlich auch doof, also das haben wir auch irgendwann wieder weggeschmissen. Also Discord würde ich auch sagen, ist cool.
Okay.
Also was cooler Discord ist, das nutzen halt alle von früher und so vom Gaming und so weiter. Man kann halt super easy da halt irgendwie reingehen, man hat halt Video, man hat halt Chat, man hat halt alles eigentlich, was man so will.
Die Firma kenne ich gar nicht, also du hast irgendwas Böses, wo 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 dann
ein Channel auf für dich, ne? Ja, ja, okay
Ja, ich weiß so ein bisschen, was du meinst, aber so
Also ich würde das natürlich, mir ist
schon sympathisch zum Beispiel auch, was die technisch machen
die haben ja auch irgendwie
da Rekorde aufgestellt
mit wie viel 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 hosten können oder sowas.
Ja, aber diese ganzen Inti-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 dahin gehen, wo die User sind.
Ja, genau.
Hey, wir haben ein Instagram-Store.
Gefällt mir gar nicht, aber gut.
Sind wir doch nicht auf Instagram, schade.
Ja, gefällt mir nicht. Genau, ja.
Dann lass uns doch noch ein Facebook-Store machen.
Ja, Discord finde ich ganz okay, es geht.
Aber bei mir ist es eh immer an.
Ja, gut, okay.
Johannes auch da. Ja, ich weiß,
der hat ja da auch irgendwie ein eigenes Ding
aufgemacht, aber da ist auch gar nicht so wahnsinnig viel los.
Ja, aber das liegt auch ein bisschen daran,
also unter anderem, dass
er das halt auch so bei seinen Sachen
benutzt wie seine Spielfirma.
Naja, aber wie auch immer.
Lustig auch, das gerade 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
und ich nicht auf deren muss, dann
die Kommunikation ist irgendwie schöner, professioneller, sauberer, cleaner.
Aber es ist noch wieder so eine ästhetische Sache und keine Ahnung,
alles kommt ja teller.
So besser als Teams zu sein ist jetzt nicht so furchtbar schnell.
Okay, das war ein Beispiel.
Weil wir darüber reden, wo die User sind und so.
Die sind ja auch schon alle leider da.
Wollen wir noch Pics machen?
Stimmt, wir haben noch Pics.
Bonnie darf anfangen.
Ich habe mich jetzt motiviert von der letzten DjangoCon jetzt echt intensiver mal mit HTMX auseinandergesetzt.
Ah, ja.
Und das finde ich wirklich sehr, sehr cool.
Ja, da machen wir auch irgendwann eine Folge und 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.
Ich habe da letztens noch einen sehr interessanten Vortrag von dem Macher gehört.
Das war von der...
Das war Python US oder so.
Der hat auch sehr schön erklärt,
wie REST eigentlich funktioniert.
Genau, und dass es ja eigentlich darum geht,
HTML-Schnittlern herzuschicken und nicht JSON-APIs
zu bauen.
Also super interessanter Vortrag, hat mir ein Kollege empfohlen.
Und ich habe mich damit noch mal
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 taucht sich was aus.
ist klar, aber wenn man halt so ein bisschen
darüber hinausgehen möchte und halt
ja, 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,
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
an mein HTML,
das ist beides ein bisschen blöd. Ja, wie HTTPS
ist auch mal doof. Ja, genau.
Und
ja, aber ich glaube, wenn
das sehr viel Potenzial hat, das 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
auch letztens meine Findings, wie man das mit
Django verheiraten kann,
auch in einem kleinen Artikel zusammengeschrieben.
Das habe ich mir noch nicht angeguckt. Ich weiß nur, dass es es gibt. Es gibt ein
Paket von Adam Johnson
also der mit dem
Was tut das Paket denn?
Tatsächlich sind das eigentlich vier Zeilen Code
man muss den CSF beibringen und das war's.
Ah, okay, also das ist
Django-HTMLX heißt das Paket glaube ich.
Ah, okay, ich weiß gar nicht, was das tut.
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, weil wie gesagt, ich hab's halt einfach
zu Fuß gemacht, weil ich wusste, dass das Pakete existiert sind.
wenn man es einmal gefunden hat, das sind literally halt einfach vier Zeilen JavaScript, die man einbinden muss,
dass man halt dem HTMLX quasi den CSF-Token injectet.
Ja, da muss er auf jeden Fall in unserer nächsten Folge hören, da werden wir da auch nochmal drauf eingehen.
Jochen?
Ich weiß nicht so genau, was pücke ich denn?
Also ich picke Pendulum. Ich glaube, das hatte ich schon mal gepickt, weiß ich nicht.
Ich weiß immer, vielleicht kann man ja immer das nicht merken.
Du musst immer so einfache Sachen picken. Ja, kennst du Pendulum?
Nee.
Das ist eine Date-Time-Parsing-Politik.
Cool.
Ja, also ein bisschen einfacher, so ein bisschen schöneres Interface, ein bisschen moderner. Früher hat man, glaube ich, Maya viel benutzt, aber ich kenne das Ries irgendwie, als wenn es nicht tot ist oder so. Und ja, aber da kann man so schöne Sachen machen, indem man Date-Times irgendwie machen möchte, in Time-Zone wechseln und so zu Strings umbauen und sowas.
Okay, interessant, ich bin letztens
das war gestern glaube ich
da war
das 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
das war ganz
schrecklich
Also Pendulum ist für Python, weil das auch immer nervt
meiner Meinung nach, sehr schön eigentlich
Ja, also da ist
das JavaScript-Date-Ding
also das hatte, also sowas wie
StoveTime gibt es da halt einfach nicht.
Wenn man jetzt die Differenz
zwischen zwei Dates bildet
in JavaScript, ja, so hast du ein DateObjekt,
ein anderes, machst eins minus das andere,
was kommt dabei raus? Wisst ihr das?
Bei Python kommt so ein
Timedelta raus.
Bei JavaScript
kommt die absolute
Zeit in Millisekunden raus.
Was natürlich ein bisschen
blöd ist, wenn man jetzt Mikrosekunden braucht oder keine Ahnung
oder was ganz anderes oder
oder halt an den Tagen
interessiert oder so.
Ja, das hat mich
Ja, ich kann es so erklären,
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 mal angucken.
Ist das du noch ein Pick?
Ja, vielleicht picke ich einfach
Blue statt Black.
Macht im Grunde das gleiche, nur halt mit
einem einfachen Tick statt
Doppel-Einführungszeichen.
Ja. Wir hätten noch mal
erstens irgendwas mit Black, was man... 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...
Sodass es halt immer dunkler wird zu der Zeit.
Und wenn man... Weil das macht auch Sinn, dann halt
As-Git-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 PipTools. Da habe ich letztens auf Twitter gesehen
auch jemand... Ich habe...
Angefangen. Weil du mir das gezeigt hast, wollte ich gerade
was wir machen, 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 FastAFI
und View und Frontend-Dings da,
für meinen Deploy-Teil, da habe ich
jetzt auch PipTools verwendet, weil
mich Poetry so genervt hat, weil es so lange braucht
und... Also PipTools sind so richtig
toll, fand ich es jetzt auch. Und weil es halt oft auch
irgendwie komisch kaputt geht. Aber es gibt
Empfehlungen von dir?
Ja, also genau,
heute auf Twitter meint jemand so,
also Pochi, eigentlich super sexy sieht das aus, aber ich bin durch, ich nehme jetzt wieder PipTools, weil das funktioniert einfach nicht.
Und dann habe ich in diesem Twitter-Thread, den muss ich nochmal aufmerksam machen,
ganz viele Leute was Ähnliches gesagt haben.
Viele Leute sagen so, oh, furchtbar langsam, geht immer kaputt.
Ja, also es geht auch bei mir ständig kaputt und ich muss immer was fixen, das nervt extrem.
Aber es ist schon eigentlich eine gute Idee und eigentlich sollte es genauso aussehen,
aber es tut halt nichts.
Aber vielleicht lassen wir uns einfach mal fixen, anstatt was Neues wieder zu machen, was auch nicht funktioniert
Vielleicht, gutes Schlusswort
Ja, vielleicht lassen wir das mal refactoren
Danke Ronne, dass du wieder da warst
Ja, vielen Dank für eure Aufmerksamkeit
Ja, bleibt uns gewogen, schaltet uns gerne wieder ein
Bis zum nächsten Mal
Bis dann mit Werbung, tschüss
Tschüss, ciao