Hallo und herzlich willkommen zu einer neuen Folge von Podcast Software Testing. Ich bin euer Host Ritschi und heute soll es mal um das Hirn gehen, nämlich konkret darüber, wie gut unser Hirn eigentlich Code versteht und warum wir manches nicht verstehen. Peter und Stefan haben das mal ein bisschen erforscht und sind von Clean Code aus auf die Reise ins menschliche Gehirn gegangen. Also schauen wir mal, ob wir alles verstehen. Viel Spaß bei der Folge.
Hallo Stefan, hallo Peter, schön, dass ihr da seid. Hi Ritschi. Hallo. Es freut mich, dass ihr hier in den Podcast gefunden habt. Ihr wurdet mir vorgeschlagen hier von einem ehemaligen Podcast-Gast und habt schon in der Headline ein spannendes Thema gehabt, nämlich warum Code ja nicht verständlich ist oder schon. Und ich denke mal, ja, warum Code ist doch verständlich, oder? Wenn es gut läuft, kann das so sein, ja. Ja, wie seid ihr denn da dazu gekommen? Was bewegt euch denn bei dem Thema?
Also, Stefan und ich sind wir beide als Dienstleister unterwegs, als Softwareentwickler, und wir setzen uns generell viel mit Clean Code auseinander. Und da haben wir natürlich auch das Buch gelesen von Robert C. Martin. Und der gibt ja so ein paar Regeln, die sind alle ganz interessant, ganz nett. Aber irgendwie haben wir uns gefragt, was steckt denn dahinter? Also warum, wie kommt denn Bob Martin eigentlich auf seine Empfehlungen? Und da haben wir versucht, einen neuen Ansatz zu finden.
Ja, also das Kernproblem ist ja insbesondere für die jüngeren Kollegen immer, dass wenn sie in ein Team reinkommen und man ihnen dann erklärt, der Code, der ist unleserlich, du hast hier vier Argumente in deiner Methode benutzt, sowas macht man nicht. Und dann fragt der jüngere Kollege, warum nicht? Und dann sagt der ältere Kollege, ja, das steht im, also wenn er gut ist, sagt er, das steht im Clean Code Buch so drin. Wenn er schlecht ist,
sagt er, mach es einfach so. Beides ist nicht so richtig die optimale Antwort, weil der Junior jetzt sagt ja, gut, wie viele Bücher muss ich jetzt vollständig memoriert haben, um zu wissen, wie man Code schreibt. Und die Idee ist einfach gewesen, gibt es denn eine Möglichkeit, sich das auch irgendwie zu erschließen, was guter Code ist und nicht tausend Bücher gelesen zu haben zu müssen oder überhaupt zu wissen, welches denn jetzt das richtige
Buch, weil es gibt ja auch widersprüchliche Aussagen in den Büchern. So sind wir dann irgendwie dahin gekommen, dass es doch irgendwas dahinter geben muss. Ich meine, ich denke, das, was in den Büchern drinsteht, das ist ja auch einfach Best Practice. Das hat ja irgendwo Mayerbär zusammen gesammelt, weil es gut funktioniert hat in seiner Welt. Genau, also es sind Erfahrungswerte und die darf man auch nicht unterschätzen. Also die
sind alle, ich würde sagen, alle irgendwie wahr. Aber wenn man hinterher eben weiß, das kommt auch nicht so aus dem Nichts heraus, sondern es gibt auch eine Begründung dafür, dass die funktionieren, dann kann man sich eben auch andere Best Practices erschließen oder auch merken, warum funktionieren andere Sachen ganz gut. Und dann ist auch ein bisschen die Erklärung für Kollegen ein bisschen besser, wenn man ihnen einfach erklärt, wieso man so was nicht machen
soll. Man einfach sagt, dein Gehirn wird einfach überlastet, wenn du zu viel Informationen dorthin leitest. Versuch das irgendwie zu reduzieren. So und so könnte man es machen. Und wie seid ihr da vorangegangen? Wie habt ihr das quasi für euch erschlossen, dass ihr das auch so vermitteln könnt? Ja, also wenn es um Verständlichkeit geht, ist sehr offensichtlich, dass das Gehirn irgendwie beteiligt ist. Und jetzt haben wir uns halt mal
geschaut, wie funktioniert eigentlich das Gehirn. Wir haben uns dafür Dinge angelesen, das ist vielleicht der Disclaimer, den wir vorausschicken müssen. Wir sind ja keine Neuroscientists oder was auch immer. Also wir können nur wiedergeben, was wir gelesen und recherchiert haben. Aber im Wesentlichen unterscheiden wir beim Gehirn zwischen dem Arbeitsgedächtnis und dem Langzeitgedächtnis. Und wenn ich jetzt Code lese, ist natürlich das
Arbeitsgedächtnis, das arbeitet ja, wie der Name sagt. Es hat aber seine Limitierungen. Unter anderem ist eine Limitierung, dass es eben gleichzeitig immer nur vier sogenannte Chunks weiterverarbeiten kann. Diese Chunks, das sind quasi so Informationsklumpen, die im Langzeitgedächtnis abgespeichert sind. Und jetzt kann man sich denken, wenn ich viel Erfahrung habe, dann habe ich viele Chunks angesammelt in meinem Gehirn und habe mehr Vernetzungen, auf die ich eben zurückgreifen kann. Und dann?
Wenn ich mehr Vernetzungen habe, dann steigert das natürlich auch das Verständnis oder mein Verständnisvermögen. Also man muss sich das so vorstellen, jeder Informationsklumpen in unserem Code, also jedes Wort, jeder Zusammenhang wird irgendwo im Gehirn auf irgendeinen Chunk abgebildet. Und wenn ich eine Programmiersprache gelernt habe, dann lerne ich eben zum Beispiel einen Chunk für die Grammatik der Programmiersprache. Das sind vermutlich sehr viel mehr Chunks. Also,
wie muss ich das eben interpretieren, wenn dort etwas steht in meiner Programmiersprache? Und dann kann ich intern das nachsimulieren. Genauso ist es, wenn ich irgendwelche Namen vorfinde, dann assoziiere ich irgendwas damit, also variablen Namen, Methodennamen, Klassennamen, assoziiere ich nur irgendwas mit, kriege eine Vorstellung davon, was es sein könnte und kann
damit dann symbolisch rechnen. Genau. Und die Idee ist einfach, habe ich jetzt zum Beispiel eine Zeile Code, dann besteht die ja oft aus einem, machen wir jetzt mal ganz naiv eine Zuweisung. Wir haben ein Ergebnis, was dort rauskommt. Wir haben ein Objekt, auf dem die Methode aufgerufen wird. Wir haben eine Methode, wir haben ein Argument. Und die alle werden gleichzeitig im Arbeitsgedächtnis aktiviert. Das Ergebnis nicht, das ist ja noch nicht da. Das soll am Ende raus
kommen. Das heißt, wir haben ein Subjekt, auf dem wir ausführen, eine Methode, ein Argument. Das geht an das Arbeitsgedächtnis, das rötelt dann ein bisschen rum und dann gibt es das Ergebnis. Wir haben jetzt eben gerade gesehen, das waren drei beteiligte Chunks. Und drei beteiligte Chunks kann das Arbeitsgedächtnis natürlich gut verarbeiten, weil es eben nur ein Limit von vier hat und alles drunter. Das geht eigentlich ganz locker. Aber dann, wenn ich jetzt quasi,
das heißt, quasi eure Idee geht davon, diese Dinge kleiner zu machen auch. Also, die man betrachtet, ist das der richtige Weg, den ich da habe im Kopf, in meinen Chunks gerade? Eigentlich geht es, also das ist eine Möglichkeit natürlich, dass man die Sachen kleiner macht. Weniger, also je kleiner sie sind, desto eher passen sie ins Arbeitsgedächtnis rein. Aber der Witz an diesen Chunks ist auch der, dass die Größe der Chunks selber gar nicht einheitlich ist. Also,
man kann hinter einem Chunk sehr, sehr viel verbergen. Also, in der Informatik nennen wir, kann man einen Chunk ungefähr so vergleichen, was wir unter Abstraktion verstehen. Also, wir haben eine Abstraktion von etwas. Und also, wenn wir jetzt einen Namen hören, zum Beispiel eben den Namen, wenn wir Design-Patterns kennen und den Namen Observer hören,
dann haben wir sofort eine Assoziation, was könnte sich hinter dem Ganzen verbergen. Und alle diese Chunks, die feuern, also diese Einzeldetails, die feuern gleichzeitig mit. Das heißt, wir können zwar vier Informationen gleichzeitig nur verarbeiten, aber in einer Information selbst können sehr, sehr viele Unterinformationen sein. Und die werden gleichzeitig, also nicht so wie beim Computer, dass wir dann eben symbolisch nur noch auf der Abstraktion
arbeiten. Nee, wir können die auch gleichzeitig im Gehirn verarbeiten. Das ist eben der Trick, dass das Gehirn ein bisschen anders funktioniert als der Computer und auf die Art und Weise eben viel, viel mehr Daten verarbeiten kann in einem Schritt. Die Schritte sind natürlich auch ein bisschen langsamer, aber in der Evolution hat sich sowas offensichtlich bewährt. Okay, verstehe. Also jetzt weiß ich, wie mein Hirn funktioniert und wie habt ihr,
wie sieht jetzt der Transfer aus? Also in dieses, des Clean-Codes quasi oder der Pattern oder wie auch immer das dann genannt ist. Ja, man kann so sagen, Code ist ja auch eine Form von Kommunikation. Also ich bin, ich habe eine Idee, ich habe Anforderungen, die möchte ich umsetzen, in Feature gießen, ich schreibe Code. Und jemand anderes liest diesen Code. Also jemand anderes kann auch bedeuten, dass ich das selbst bin, aber mit T plus X, ja, also in der Zukunft.
Ja, ich kann mir denken, wenn ich mich mit Chunks überflute, dann ist das für das Verständnis natürlich nicht förderlich. Also es geht auch ganz viel davon, dass ich eben Chunks habe, die beim anderen auch vorhanden sind. Also es bringt niemandem etwas, wenn ich die ganze Zeit von einem Observer rede, wenn ich gegenüber jemanden habe, der davon noch nie gehört hat. Ja, und das ist auch dieses Trick. Also gehen wir mal, nehmen wir uns mal exemplarisch ein Beispiel
aus dem Clean-Code Buch vor. Das wird ja immer wieder zitiert, das Thema Naming. Und also ich weiß gar nicht, wer dieses Naming, ist es das schlimmste Problem in der Informatik, geprägt hat, aber auf jeden Fall, Naming, wenn wir das in das Gehirnmodell übersetzen, bedeutet, wir müssen unter dem richtigen Namen, in den richtigen Chunk abgespeichert haben. Das heißt, jeder, dem ich einen Begriff an den Kopf werfe, der muss sofort wissen, um was es sich handelt. Und es gibt
ja viele verschiedene Begriffe, zu denen wir verschiedene Vorstellungen haben. Und es gibt welche, zu denen haben wir gar keine Vorstellung. Und gutes Naming ist eines, das sehr, sehr vielen Leuten bekannt ist. Also dieses Wort, unter dem sie auch das Richtige verstehen. Und wenn wir diese Voraussetzung, was ich jetzt hier so etwas informell beschrieben habe, wenn wir das jetzt ins Gehirn wieder reinbringen, bedeutet das, also dass die Chunks im Gehirn eben ähnlich vernetzt
sind. Die sind mit den gleichen Sachen assoziiert, wie beim, also meine sind ähnlich assoziiert, wie beim Peter. Und je ähnlicher die assoziiert ist, desto mehr kann ich das rüberbringen in der Kommunikation, was ich eigentlich selber denke. So und das geht ja im, also haben wir als Softwareentwickler ja relativ schnell auch kapiert, dass Teamarbeit sehr, sehr viel Kommunikationsarbeit ist und dass
Informatik auch eigentlich eine sehr, sehr viel, sehr, sehr viel Kommunikation enthält. Und das liegt eben einfach daran, dass wenn wir eben Code schreiben, der lesbar und verständlich sein muss, dann müssen wir eben auch gucken, dass wir nicht irgendwelche abstrusen Ideen, die nur wir so plausibel finden, formulieren, sondern dass wir eben für unsere Teammitglieder schreiben. Nur so
können wir dann eben richtig kommunizieren. Ich finde das ein super Beispiel, weil ich gerade, wenn ich jetzt an so variablen Namen denke, und die sollen dann irgendwie sprechend sein oder so etwas, dann impliziert das ja häufig, dann überlege ich mir irgendwas, was für mich sprechend ist, aber das muss ja nicht zwangsläufig für den anderen auch sprechend sein. Und der sitzt dann da vorne und denkt sich, hö? Der Witz ist ja auch, also es heißt dann auch immer sprechende Namen
und manche interpretieren das so, wie sie dürfen keine Buchstaben mehr verwenden. Aber das ist ja nicht wahr. Ich darf schon ein X benutzen, wenn ich die X-Koordinate verwende zum Beispiel. Ja, das ist eine Konvention. Das muss nicht, man muss nicht X-Koordinate schreiben. Also das, man kann dem Leser schon eine gewisse Cleverness unterstellen. Auch ist es so, dass viele meinen, naja, wenn ich es nicht beschreiben kann mit einem Wort, dann versuche ich plötzlich einen
ganzen Satz in meine Variable reinzuschreiben. Das ist an sich auch nicht der Gedanke, weil nämlich ein ganzer Satz jetzt, wenn wir uns gerade uns jetzt das Gehirn anschauen, ich habe, wir haben ja gesagt, wir sind etwas limitiert mit unserem, in unserem Arbeitsgedächtnis auf vier Chunks und jeder Teil von einem Wort, jeder Wortbestandteil, der würde irgendwie als Chunk verarbeitet und wenn wir einen ziemlich langen Variablenamen haben, dann kann es schon
passieren, dass wir allein mit dem Variablenamen so überfordert sind, dass wir hinterher, wenn man durchgelesen haben, nicht mehr wissen, was am Anfang stand. Das heißt, auch bei einem Variablenamen ein bisschen auf Kürze und Prägnanz gucken, wirklich ausführlich beschreiben ist an der Stelle nicht gut. Und das ist eben auch ein Punkt mit den Kommentaren. Manche Leute sagen, okay, mein Variablename, der beschreibt nicht so viel, also schreibe ich einen elendlangen Kommentar
vorne dran. Das Dumme ist, der strengt unser Gehirn halt unglaublich an, weil wir beim Kommentar halt alles vorne weg sorgfältig lesen müssen, das will das Gehirn nicht und dadurch sinkt die Verständlichkeit. Also natürlich ein guter Kommentar ist besser als nix, ja, aber wenn wir das Ganze schon mit dem Variablenamen sagen können oder den schon einen Eindruck mit dem Variablenamen vorprägen können,
dann ist es natürlich viel besser. Ja, verstehe. Also das mit den Namen ist mir total klar. Hast du noch vielleicht ein anderes Beispiel auch noch aus dieser ganzen Clean-Code-Welt, wo ihr da quasi einen anderen Übertrag macht ins Hirn? Also eine Idee, die wir immer hervorheben ist, es gibt ja in dieser Clean-Code-Welt einen Rat, wie viele Argumente man bei Methodenaufruf verwenden soll. Ankel Bob hat da mal gesagt, es sind etwa zwei Argumente, die darf man verwenden. Wenn man
mehr verwendet, wird es unverständlich. Weniger darf man natürlich verwenden. Und da haben wir uns einfach mal überlegt, wie passt denn das? So zwei Argumente sind ja jetzt zwei und nicht vier. Aber der Witz bei der ganzen Sache ist eben, wir haben ja nicht nur die Argumente, die wir gleichzeitig verarbeiten müssen, sondern wir müssen ja wissen, wie sie verarbeitet werden, also die Methode und wer diese Methode aufgerufen hat, auf welchem Objekt sie aufgerufen wird.
Der Ankel Bob, der Robert Cecil Martin ist ja objektorientierter Guru sozusagen, da wird immer irgendwas auf irgendetwas aufgerufen und dadurch haben wir plötzlich an der Stelle vier Chancen. Und wenn wir jetzt noch ein Argument dazu packen würden, dann hätten wir fünf und dann würden wir schon einige Leute abgehängt haben, die mit den fünf nicht mehr zurechtkommen. Diese vier, die sind keine exakte Grenze. Also die Psychologie sagt vier plus minus eins und ich weiß jetzt
nicht, wovon es abhängt, wann man mal plus eins oder mal minus eins hinkriegt. Aber entscheidend ist, bei dem fünften Argument wird es halt schon richtig schwierig, das zu verstehen. Das ist also so ein Beispiel, wo man eben an die Grenzen des Arbeitsgedächtnisses kommt. Und was Sie ja gesagt haben, man kann das natürlich abkürzen durch Abstraktion. Also wenn man eine Abstraktion findet, die zwei Argumente, zwei Parameter zusammenfügt, dann würde das funktionieren.
Nur wenn man umgekehrt generisch sein möchte, also man sagen möchte, diese Funktionen möchte ich eigentlich relativ variabel verwenden. Ich möchte nicht immer für jede Methode eine neue Abstraktion finden. Dann muss man die Argumente eben nebeneinander als gleichberechtigte Chance ansehen und kann sie nicht einfach so zusammenfassen. Ja, verstehe. Jetzt habt ihr ja das, also das ist immer schon, jetzt verstehe ich das mehr, diesen Transfer auch quasi zu der
hirngerechten Verständlichkeit des Ganzen. Habt ihr denn da auch irgendwo gesehen, bei diesem ganzen Clean-Code-Pattern oder sonst irgendwas, wo ihr gemerkt habt, dass diese Regel gar nicht kompatibel ist mit unseren Verständnismöglichkeiten in der Form? Also vergleichsweise, also eigentlich weniger. Also ich habe ein paar Bücher gelesen, wo ich gesagt habe, also die sind aber nicht Clean-Code-Bücher. Also die, die aus der Erfahrung
sich ergeben, die sind alle relativ konsistent mit dem Gehirnmodell. Da habe ich eigentlich selten Einwände gefunden. Ich habe ein paar andere Bücher zu dem Thema gelesen, die versucht haben, das auch zu erklären, wo ich gesagt habe, dass dieses Statements, die hätte man auch, die hätte jeder machen können und sie sind nicht wirklich richtig nachprüfbar, ohne, ohne dass man die Versuche dazu kennt und so weiter. Also tatsächlich muss ich sagen,
die Praxis ist an der Stelle durchaus sattelfest. Die Theorie, also das, was wir eigentlich hier machen, die ist ein bisschen vage an der Stelle. Also das heißt, es gibt viele Leute, die auch Erklärungen haben und die bekriegen sich im Augenblick auch so ein bisschen, vermutlich, weiß ich jetzt gar nicht, also es gibt gar nicht so viele Leute, fairerweise. Also eigentlich ist es die Theorie, die da noch viel nachzuholen hat.
Ja, das heißt also quasi das, was in der Praxis läuft, da ist schon viel, viel richtig, wie es gemacht wird. Gefühlt schon. Also zumindest jetzt, wenn man das auf unser Modell jetzt bezieht, gibt es da eigentlich selten irgendwelche Abweichungen. Also jetzt zu sagen, in der Praxis läuft es immer richtig, das habe ich durch Bauchschmerzen, aber die Momente, wo ich das Gefühl habe, hier läuft es jetzt nicht richtig, da passt es immer
ganz gut dazu, dass ich irgendwie eine Überforderung habe. Also noch so ein Aspekt, der mir einfällt, sind eben Seiteneffekte, die ich in Methoden habe. Also wenn ich im Hintergrund noch irgendwie einen Counter mit hochzähle, dann muss ich das ja auch noch in meinem Kopf behalten, wenn ich das verstehen möchte. Ja, ist klar, das ist doch so ein super Beispiel. Ja, also genau, also die Funktionalprogrammierer, die sind ja super Fans davon, zu sagen,
macht keine Seiteneffekte, verwirrt nur. Und es liegt eben unter anderem daran, dass unser Gehirn nicht so richtig mit Zustandsübergängen umgehen kann. Also man hat eben eine Assoziation zu einem bestimmten Namen und die bleibt eine Zeit lang erhalten. Also ich habe ja gesagt, so ein Chunk, also den kann ich nicht einfach so umschreiben, der braucht eine Zeit, bis er umgeschrieben ist. Und wenn ich jetzt eine Variable neu zuweise, dann ist plötzlich ein anderer
Wert drin. Und ich habe plötzlich eine ganz andere Assoziation, also sollte eine andere Assoziation haben. Und deswegen ist alles, was einen Zustand hat, für uns eine gewisse Herausforderung, weil wir eben diesen Zustandsübergang im Gehirn nachvollziehen müssen, obwohl das Gehirn eigentlich für sowas gar nicht so richtig ausgelegt ist. Also das Gehirn ist sehr gut dafür ausgelegt, Zustandsänderungen wahrzunehmen, aber nicht intern zu reproduzieren. Darum geht es.
Wenn ich jetzt bei mir im Team so wahrnehme, ja, oh, da ist ja jetzt irgendwie, ich kann das total nachvollziehen mit dieser Überforderung bei uns laufen, Code Reviews immer so ein bisschen nicht gut und so. Was habt ihr denn für Tipps? Wie kriegt man denn das als Otto Normalo bei sich ins Team auch mit hinein? Habt ihr da irgendwas an der Hand? Ja, da können wir eigentlich gleich an den Anfang gehen, was wir ganz am Anfang schon gesagt haben.
Also es geht darum, Chunks gemeinsam zu haben. Und das erreicht man dadurch, indem man ganz banal miteinander spricht, sich austauscht, gemeinsames Verständnis von der Welt bekommt. Und natürlich, wenn ich selbst Code schreibe, dass ich mir entsprechend Mühe gebe, meinen Code ideal zu präsentieren. Ganz banal zum Beispiel Code-Formatierung mitzumachen, dass ich den Formeter
ansetze. Aber auch, wenn ich eben meine Methoden schreibe, auf diese Überlegungen mit eingehe, habe ich jetzt irgendwie Variablen, die unnötig lange leben, weil dann muss man die auch in seinem Kopf irgendwie zwischenspeichert haben. Und das wirkt natürlich dann auch wieder die Gefahr, dass man die anderen überfordert oder sich selbst. Es gibt ja auch eine ganze Menge von agilen Praktiken, die ein bisschen in diese Richtung gehen, die Chunks zu synchronisieren.
Also wenn wir zum Beispiel Pair-Programming anschauen. Durch Pair-Programming stellt man einerseits sicher, dass wenn ein Driver plötzlich eine komische Vorstellung hat, was denn ein Chunk sein sollte, dann ist das für den Navigator nicht richtig nachvollziehbar. Dann kann man darüber reden und wie kommst du denn da drauf, dass das jetzt gut verständlich wäre. Aber die zweite Sache ist auch, dass man dadurch immer einen Zweiten hat, der auf die gleiche Art
und Weise den Code erstellt hat und also die gleichen Erfahrungen gemacht hat. Und Chunks werden im Gehirn eben so angelegt, weil man Ereignisse wahrgenommen hat. Und die festigen sich dann eben synchron, wenn man Pair-Programming macht. Und diese synchrone Festigung bedeutet, man hat die gleiche, haben schon mal zwei Leute die gleiche Vorstellung davon, was ist. Und wenn es beim einen halt nicht so gut in den Kopf geht, dann ist es eben ein Zeichen, das geht womöglich
auch bei anderen Leuten nicht so einfach in den Kopf rein. Vielleicht muss man ja ein bisschen nachschärfen im Code, damit es doch eher auf die allgemeine Verständlichkeit funktioniert und nicht auf die individuelle Verständlichkeit für mich. Also für sich selber kann man, ich nenne das immer gerne Ad-Hoc-Chunking, für sich selber kann man das immer irgendwie zurechtbiegen und sagen,
das ist doch richtig plausibel und so weiter. Und die Tatsache, dass man das schon zwei Wochen später nicht mehr lesen kann, das ist eben auch, deutet darauf hin, für mich war das die ganze Zeit plausibel, während ich es erzeugt habe, aber es hat sich halt nicht gefestigt, weil ich diesen Chunk halt nur einmal beim Erstellen produziert habe, aber dann nie wieder genutzt habe, weil er
einfach wertlos war. Und dann habe ich ihn auch nach zwei Wochen wieder vergessen und sehe dann plötzlich meinen eigenen Code und der ist plötzlich für mich nicht mehr lesbar. Ich finde, manchmal sind Dinge auch vollkommen unnötig verklausuliert. Also, bestes Beispiel ist die Verwendung von Abkürzungen. Es gibt ja auch schon massenhaft Memes über drei Buchstaben Abkürzungen in Unternehmen und da sage ich halt, ja, versucht doch darauf zu verzichten.
Ja, sicher, wenn das zum Verständnis beiträgt. Gibt es denn auch etwas, sagen wir mal, gerade in Richtung dieser Verständlichkeit, was hier toolmäßig, wo man sagt, okay, das kann helfen dabei auch solche Problemstellen rauszufinden? Ich würde sagen, der Scrollbalken in der IDI ist immer ganz guter Indikator. Ich weiß nicht, hast du was, Stefan? Naja, wir haben ja immer, also ich weiß jetzt nicht, ob die Frage genau in die Richtung geht.
Wir haben immer auch gelegentlich mal die Frage, gibt es denn Metriken, mit denen man Lesbarkeit oder Verständlichkeit? Ja, zum Beispiel. Und das ist so ein zweischneidiges Schwert. Also, es gibt ja immer noch die Sache, also der Metrik, die lässt sich halt auch gelegentlich durchaus einfach betrügen. Und diese Metriken, die man üblicherweise zur Softwarequalität macht,
die sind jetzt erstmal nicht schlecht. Also, oft ist es, es ist oft so, dass eine hohe zyklomatische Komplexität auch zu einer Überforderung des Gehirns führt. Das hat einfach damit zu tun, hohe zyklomatische Komplexität bedeutet, ich muss immer Bedingungen, die ich dort hingekommen bin, im Kopf behalten. Und ab irgendeinem Zeitpunkt ist mein Arbeitsgedächtnis voll mit diesen Bedingungen.
Dann kann ich einfach nicht mehr rechnen, weil ich mir ständig überlege, in welchem Branch bin ich jetzt und so weiter. Dann verdränge ich irgendwelche Informationen und dann werden meine Ergebnisse, die ich später habe, eben ungenau. Das heißt, das ist schon irgendwie ein Anzeichen. Es ist aber weder hinreichend, ich habe ja auch gesagt, es ist weder hinreichend noch notwendig. Es gibt unlesbare Sachen, die durchaus komplex sind, auch zyklomatisch komplex, aber die durchaus lesbar sind.
Und umgekehrt, es gibt unlesbare, die an einer ganz anderen Stelle unlesbar sind. Also ich habe mir irgendwann mal im Internet ein paar Metriken rausgenommen und alle Metriken, die so auf Softwarequalität testen, die sind irgendwie und wo kompatibel mit dem Gehirnmodell. Das heißt, also sie deuten alle mit einer Gewissheit, mit einer gewissen Gewissheit darauf hin, dass der Code auch nachher unleserlich ist.
Aber sie sind nicht hinreichend und es gibt halt auch eine Menge von Fällen, da reichen die überhaupt nicht aus. Also gerade solche Sachen wie Naming kann man damit ja nicht ab. Also das Naming ist ja eine sehr, sehr individuelle Sache, dass man eben hinter dem Namen das Richtige vermuten soll und das kann auch die Technik einem auch gar nicht abnehmen.
Und da jetzt erfahrungsgemäß die ganzen Experten eben sagen, Naming ist das Allerwichtigste, dann muss man halt sagen, die Metriken nehmen eigentlich sozusagen einem die Beinarbeit ab. Also das, was unwichtig ist, das können die dann noch rausfiltern, aber wenn man mit dem Naming schon gepusht hat, dann kriegt man jeden ausgetrickst. Ja, verstehe.
Jetzt ist es ja so, heute, viele Entwickler arbeiten ja jetzt auch mit Tools wie Copilot und so für Programmierung, also spielen auch mit KI rum, lassen sich da unterstützen. Merkt ihr denn da eine Veränderung, was die Verständlichkeit angeht? Auch zweischneidig natürlich. Stefan hat ja vorhin von entsprechenden Namen gesprochen und wer spricht, kann auch labern. Das heißt, du wirst ja förmlich zugeschüttet von einem Copilot.
Auf der anderen Seite, ich kann den Copilot ja auch einfach fragen, hey, ich verstehe das nicht, was meinst du damit? Und dann erklärt mir der Copilot, das kann ja helfen bei dem Verständnis. Also ich habe eine nette Anekdote dazu. Ich habe es tatsächlich mal geprüft und habe irgendein Beispiel, was ich aus meinen Vorträgen habe, in ChatGPT reingegeben und habe gesagt, schreib es doch auf leserlich. Und das hatte allerdings einen ganz komischen Effekt.
Das Erste, was es war, er hat mir die Namen, wenn ich Namen gehabt habe, hat die Namen mir plötzlich verlängert, weil ich habe eben x für die x-Koordinate und dann hat er eben x-Koordinate drin geschrieben sozusagen. Das Zweite, was er gemacht hat, ist, dass er die Methodennamen extrem verlängert hat. Also mehrere, da sind dann mehrere Wörter drin gewesen.
Ich glaube, er schlägt immer vor, wenn man dort "Calc" drin stehen hat, dann soll man dann sagen, "Calc difference of squares", also so einen richtig schönen langen Methodennamen. Und das Allerwitzigste, was er macht, ist, er schreibt immer eine elendlange Dokumentation vorne dran, weil das ist das, was konsistent immer passiert. Es ist immer vier Zeilen Dokumentation da dran.
Und dann, jetzt habe ich jetzt gerade der eigentliche Witz an der ganzen Sache, das war "Calc difference of squares", und das ist x²-y², aber ausgerechnet hat er x-y mal x+y, was äquivalent ist, also für diejenigen, die es jetzt nochmal nachrechnen wollen. Aber absolut unlesbar, warum das Ding jetzt die "Difference of squares" sein soll.
Das heißt, er hätte das einfach "Difference of squares" hingeschrieben, wäre nicht ganz so performant gewesen, aber hätte man besser lesen können, als einfach diese Methode aufzurufen. Das heißt, er macht das auf eine mechanische Art und Weise. Ich glaube, er ist einfach auch noch nicht richtig angelernt worden an der Stelle. Vielleicht lernt er das nochmal irgendwann mal. Aber im Augenblick war es eher amüsant als hilfreich.
Ja, sehr cool. Na ja, kommen ja immer lustige Sachen zum Teil raus, aber es ist natürlich jetzt auch da und wir müssen... Also ich bin zuversichtlich, dass da noch was geht, aber ich habe gemeint, im Augenblick ist es halt einfach... Also sonst hätte ich nicht gefragt. Im Augenblick ist es noch ein bisschen... Also ich sage, jetzt bin ich immer... Im Augenblick bin ich noch Experte und die Akakie kann mich nicht ersetzen.
Also für mich der größte Nutzen ist immer noch, dass ich mir endlich regular expressions erklären lassen kann. Genau, also solche Sachen sind die Dinger gut. Das war für mich immer, da bin ich immer ausgestiegen. Ja, sehr schön. Stefan, Peter, vielen Dank, dass ihr hier im Podcast wart und mal so ein bisschen über das hirngerechte Verstehen von Code gesprochen habt. Das ist ein interessanter Blick mal drauf. Finde ich ganz klasse. Ja, ich freue mich, dass ihr hier wart.
Und vielleicht nicht zum letzten Mal. Und ich wünsche euch noch eine schöne Zeit und bis bald. Bis bald. Ja, danke, bis bald. [Musik]