Dieser Episode beinhaltet keine Notizen

Alex: [00:00:09.50] Halli hallo, Hallöchen liebe Craftbegeisterte! Herzlich willkommen!

Matthias: [00:00:15.86] Schön, dass du bei der neuen Folge von der Macht der Craft dabei bist. Wir machen heute mit Cleancode weiter.

Alex: [00:00:21.26] Aus welchem Grunde solltest du deinen Code so verständlich wie möglich machen?

Matthias: [00:00:27.05] Und welche Praktiken und Methoden helfen dir dabei, das zu erreichen?

Alex: [00:00:30.53] Darüber wollen wir heute sprechen.

Matthias: [00:00:33.32] Für dich und für alle, die mit deinem Code arbeiten dürfen.

Alex: [00:00:36.77] Erörten wir das? Warum? Um das Wie.

Matthias: [00:00:40.13] Auf dass sein Code noch besser wird. Los geht’s.

off: [00:00:45.41] Die Macht der Craft arbeitet für dich.

Matthias: [00:00:52.12] Genau. Also für mich. Verständlichkeit bedeutet vor allem, dass also wenn man es jetzt im Kontext von Programmieren sieht, dass der Code, den ich produziere, a) von mir selbst, ohne groß darüber nachdenken zu müssen, verstanden werden kann. Auch nach zwei Wochen wieder aber das auch dritte Also wenn jetzt jemand anders auf mein Stück Code schauen würde, auch der in der Lage ist, mit möglichst wenig Hirnschmalz verstehen zu können, was da passiert.

Alex: [00:01:24.97] Also für dich ist das hauptsächlich Lesbarkeit. Versteh ich das richtig?

Matthias: [00:01:28.12] Nicht nur Lesbarkeit in dem Sinne, sondern eben auch, dass man sich jetzt nicht fragt „Hähh, warum hat denn der das so gelöst?“ Also dass man halt wirklich keinen mentalen Aufwand betreiben muss, um zu verstehen, was da passiert. Und da zähle ich auch so Sachen rein wie das zum Beispiel bei einer Abfrage, dass da kein komplexe mathematische Ausdruck in dieser If steht, sondern dass da ein sprechender Methodenaufruf zum Beispiel steht, der diese komplexe arithmetische Sache abstrahiert, – Aber man liest sofort und weiß sofort, was da vom Prinzip her passiert, ohne den Algorithmus kennen zu müssen, wenn du verstehst, was ich meine. Und es geht aber auch so weit, dass ich zum Beispiel dann vermeiden wollen würde, also jetzt nicht für mich selber, dass ich unnötig mehrfach über ein Array zum Beispiel iterieren, wenn es möglich ist. Alles, was ich mit diesem Array-Eintrag machen muss, in einem Durchlauf zu machen. Also das sind alles so Sachen, die für mich zur Verständlichkeit dazugehören, weil wenn es anders gemacht wird, also wenn ich jetzt hier sehe, es wird einmal über die Liste iteriert, zehn Zeilen später wird noch über die Liste iteriert, dann würde es sich in meinem Kopf einfach automatisch so die Frage stellen warum iteriert man da jetzt zweimal drüber? Und das ist genau dieser mentale Aufwand, den ich vermeiden würde, wenn ich verständlich programmieren will.

Alex: [00:03:00.01] Was für mich das so alles bedeutet, ist. Im Großen und Ganzen geht es bei Verständlichkeit in meinen Augen darum, es wie du sagst, mir, mir selber und andere leichter zu machen, der Code an sich zu verstehen, aber auch die Intention, die dahinter steckt und und das Warum. Warum machen wir die Sachen so wie wir sie machen und das ist halt einfach ersichtlich ist oder so ersichtlich wie möglich, natürlich. Ein gewisser Aufwand wird immer zu betreiben sein, aber dass die Menschen es so leicht wie möglich haben zu verstehen, was diese Code macht, warum es so macht und wie es funktioniert. Ohne jetzt zwei Wochen Aufopferung Studium hier betreiben zu müssen, Das ist für mich, was Verständlichkeit des Codes ausdrücken soll. Ich glaube, da sind wir sehr, sehr nah aneinander.

Matthias: [00:04:00.10] Das sehe ich auch so.

Alex: [00:04:02.41] Und warum ist das überhaupt wichtig? Also was bringt mir das oder mir oder andere? Was bringt meinem Team, wenn wir halt entsprechend, Verständlich.

Matthias: [00:04:12.88] Ich würde mal ganz simpel sagen, es spart uns Zeit. Also je weniger Energie, weil je weniger Aufwand ich betreiben muss, um zu verstehen, was an einer bestimmten Stelle passiert, desto mehr Zeit habe ich wirklich die Änderungen zu machen, die ich machen muss, wenn ich vorher erst zwei Tage irgendwie durch den Code kriechen muss, von Stelle zu Stelle. Am besten noch im Debugger in der laufenden Anwendung, um dann irgendwann nach zwei Tagen zu checken. Ach so, das ist so, weil da gerade ein Bug eine Implementierung ist und zufälligerweise kommt das Richtige raus und so halt. Und da würde ich ganz einfach echt die Zeitersparnis sehen und die Nervenersparnis und überhaupt.

Alex: [00:04:58.81] Also Einarbeitungszeit reduzieren sich zum Beispiel. Für mich auch ein relevanter Aspekt, wenn ich irgendjemanden, die nicht die Codebasis mit implementiert hat, mitgeflickt. Wenn diese Codebasis verständlich ist und gut aufgebaut, dann dauert es nicht so lange, bis jemand anders das verstanden hat. Und wie wir ja gesagt haben, das dient auch für uns selber. Wir haben’s ja irgendwie verbrochen, wie man so sagt, ne? Wir haben es ja geschrieben. Also eigentlich mussten wir wissen, was es tut und warum es tut. Aber leider ist es so, also ich weiß nicht, ob es im fortgeschrittenen Alter liegt, aber ich vergesse das ganz schnell.

Matthias: [00:05:38.44] Ja, ja.

Alex: [00:05:39.79] Und in ein paar Tage, ein paar Woche, vor allem ein paar Monate später, weiß ich nicht mehr, was ich da fabriziert hatte.

Matthias: [00:05:48.73] Meistens weiß man ja schon nicht mal mehr, dass. Von uns selbst fabriziert hat. Da denkt man sich so, welcher Honk hat denn jetzt bitte das gemacht?

Alex: [00:05:56.37] Genau das war ich. Ups.

Alex: [00:06:00.53] Auch für mich selber hat tatsächlich ein Wert einen Wert, weil ich werde mit diesem Code, die ich jetzt produziere, wahrscheinlich in der Zukunft wieder konfrontiert. Und auch wenn ich selber geschrieben habe, muss ich irgendwie wieder reinkommen, es wieder verstehen. Vielleicht nicht so viel wie irgendjemand, die es noch nie gesehen hat, die es nicht mit formuliert hat, aber nichtsdestotrotz auch für mich relevant und wichtig. Also das macht man nicht nur für andere, sondern auch für sich selbst.

Matthias: [00:06:30.17] Warum nochmal kurz auf die ursprüngliche Frage zurückzukommen. Zeit kann man natürlich immer auch zusätzlich noch Geld sagen, weil wenn ich Zeit spare, spare ich auch Geld und da werden dann viele Leute dann auch aufmerksam.

Alex: [00:06:45.14] Ja, aber ich meine ich, Ich habe bei viele der Themen, die wir immer wieder besprechen, die die Software Craft betreffen, höre ich immer Das kostet immer nur Zeit. Jetzt Nummer eins, die keine Zeit kostet. Und das muss man ja auch mal sagen.

Matthias: [00:07:01.94] Genau. Spart sogar Zeit.

Alex: [00:07:03.68] Spart Zeit. Ja. Wunderbar. Wunderbar. Fällt dir sonst irgendwas ein? Warum?

Matthias: [00:07:11.24] Ich meine, letztendlich kann man da ganz viel mehr nehmen, glaube ich. Weil, wie du vorhin auch schon gesagt hast, die Einarbeitung von neuen Leuten, sei es erfahrene oder unerfahrene Softwareentwickler, die fällt halt einfach deutlich leichter, wenn eine Codebasis schön, einfach, selbsterklärend sauber ist. Auch da spart man wieder Zeit. Ergo Geld, weil die Leute können schneller produktiv sein, können schneller Aufgaben, Features in der Anwendung umsetzen. Und ja – Also wie gesagt, da fällt ganz viel rein, glaube ich.

Alex: [00:07:49.04] Und vor allem Bugs. Je verständlicher und einfacher zu lesen, und zu eruieren, was gerade der Code so macht. Das erleichtert auch die Suche nach der Motte, wenn irgendwas nicht so ganz genau läuft. Natürlich sprechen da Tests Bände, dann aber auch die Lesbarkeit des Code. Die Verständlichkeit des Codes spielt eine Rolle, wenn die Geschwindigkeit Bugs zu finden und vor allem auch die Geschwindigkeit, wie ich sie dann auch noch flicken kann.

Matthias: [00:08:30.87] Hm, ja.

Alex: [00:08:32.63] Das ist auch so ein Aspekt. Also Verständlichkeit, ein Konglomerat an – an Methoden und Praktiken, die man dafür anwenden kann. Natürlich. Und eben wichtig für all das, was bedeutet, wir müssen mit dem Code arbeiten, mit Code, die wir nicht kennen, mit Code, die wir programmiert haben. Aber vor einiger Zeit. Und je verständlicher der Code ist, desto leichter tun wir, uns den auch zu verändern, anzupassen, zu erweitern. Themen, die wir auch in weitere Folgen durchleuchten wollen, Themen wie Veränderbarkeit oder Erweiterbarkeit usw. und so fort, gehören auch zu Clean Code. Aber heute konzentrieren wir uns eben nur auf diese, diese eine Verständlichkeit. Okay, dann womit wollen wir anfangen? Welche Themen nehmen wir uns als erstes?

Matthias: [00:09:33.59] Na, wir können uns halt einfach mal angucken, mit welchen Methoden oder Praktiken es uns überhaupt möglich ist, mehr Verständlichkeit in ein Projekt zu kriegen. Also zum Beispiel würden wir jetzt mal Source Code Conventions einfallen.

Alex: [00:09:54.22] Ja, okay. Und was könntest du darüber sagen?

Matthias: [00:10:01.04] Naja, letztendlich find ich halt persönlich, dass sobald mehrere Leute an einem Projekt arbeiten, wird es häufig schwierig, wenn man keine Source Code Conventions hat. Also nur mal um etz den Leuten zu vermitteln, die jetzt den Begriff vielleicht noch nie gehört haben. Also da geht es im Prinzip darum, dass man sich auf gewisse Regeln einigt, wie man programmiert und das vor allem im Hinblick auf „Wie setze ich Klammern?“, „Habe ich Leerzeichen vor Klammern?“, „Leerzeichen nach Klammern?“ Wie gehe ich mit sowas um? Und da gibt es ganz nette Standards, die kann man sich anschauen. Wenn man die nicht mag, kann man die auch modifizieren. Und letztendlich gibt es dann eben dafür Tools, die einen dabei unterstützen, dass man sich an diese Konventionen hält und dass die auch in dem gesamten Projekt angewendet werden. Und da ist für mich eben auch von Anfang an ganz klar der Vorteil, dass häufig schon ein Verständlichkeitsproblem sein kann, wenn so ganz allgemeine Programmierkonstrukte wie IF Anweisungen oder so was, wenn die gleich aufgebaut sind. Das hilft ungemein, sich eben nicht darauf konzentrieren zu müssen, Was habe ich hier eigentlich gerade für ein Konstrukt vor mir? Sondern es sieht einfach immer gleich aus. Also so ganz viele Programmiersprachen ermöglichen es mir zum Beispiel die geschweifte Klammer bei IF Abfragen auf die gleiche Zeile wie den Kopf zu setzen oder auf die nächste Zeile. Und wenn es mal so und mal so ist, ich glaube es ist wirklich nur ich, den so was stört, weil sonst hätten sich glaube ich solche Coding Conventions nie entwickelt. Und da gibt es halt ganz viele Stellen im Code, wo solche ganz allgemeinen Vereinbarungen, wie man ja auf Deutsch sagen würde, helfen, den grundsätzlichen Lesefluss schon mal zu optimieren in der Hinsicht, dass man weniger mentale Leistung aufbringen muss, um überhaupt das Gerüst des Codes zu verstehen.

Alex: [00:12:15.12] Für mich bedeuten Source Code Conventions egal welche wir nehmen, ob Klammern oder Punkte oder Striche, völlig egal. Für mich bedeutet das grundsätzlich, dass mein Code annähernd gleich wie dein Code aussieht von der Struktur. Also wenn wir eine Datei aufmachen, wir gucken uns, wie das aussieht. Wenn die Struktur, die Datei, wie die Struktur der Klasse aufgebaut ist, dann sieht es ungefähr gleich, ob du es geschrieben hast oder ich oder irgendjemand anders im Team. Und das ist ein Vorteil. Brutal. Also ich muss mich nicht in dein Kopf erst einmal versetzen, um zu eruieren oder rauszufinden, wie du die Klasse aufgebaut hast, wie deine Syntax aufgebaut ist, sondern wir verwenden alle die gleiche Normen, die gleiche Konvention. So das für mich leichter ist dein Code zu lesen, für dich leichter mein zu lesen. Und das ist für mich einfach das, was der Sinn und Zweck von diese Konventionen darüber, welche Konventionen genau. Da kann man lange diskutieren und lange streiten. Das hängt davon ab, von welcher Sprache du verwendest. Dann gehören die geschweifte Klammer oben für die andere Sprache in die geschweifte Klammer unten. Aber es sei dahingestellt, welche Konventionen genau man nimmt. Ich finde, man soll von oben nach unten immer restriktiver werden. Heißt wenn wir unternehmenweite Source Code Convention machen dann sollten die eher lasch sein, eher sich nur auf ganz wenige Punkte konzentrieren. Ganz wichtige Sachen. Und je weiter kleiner der Kreis an Menschen, die mit diesen Konventionen arbeiten, können wir ein bisschen strikter werden, was was die Konventionen betrifft. Was aber auch in meinen Augen nicht sein darf, ist, dass man am Ende im Unternehmen 250 unterschiedliche Source Code Conventions hat, auch wenn sie die gleiche Basis haben. Weil dann kommt es auch völlig durcheinander. Also ich finde ein paar davon sind okay, aber nicht übertreiben. Ich finde es aber genauso schlimm, wenn es nur ein ja der eine Ring der Source Code Conventions gibt und wir müssen uns alle dran halten, egal welche Sprache, egal welche Gegebenheiten wir haben. Also sollte hier schon mal ein bisschen differenzieren und vielleicht nicht nur eine Source Convention, sondern allgemeine Source Convention, dann sprachbedingte Source Conventions haben und solche Sachen.

Matthias: [00:14:57.78] Wobei ich Sagen muss, dass ich mir die Anzahl der Konventionen eigentlich egal, solange die, die auf Projektebene ausgerufen wurde die es die gilt. Also wenn ich mich um mehrere kümmern muss, dann ist es blöd wenn ich mich jetzt in der von meinem Projekt an gewisse Sachen von in der Hierarchie höher hängenden Conventions ableiten muss. Okay, aber. Also ich würde schon. Auf Projektebene habe ich überhaupt kein Problem damit, wenn jedes Projekt eigene Coding Conventions hat.

Alex: [00:15:34.59] Okay, aber jetzt ein bisschen unternehmerisch denken und nicht nur Entwickler usw.. Wenn du weniger davon hast, ja von diesen Konventionen und ich von Produkt A zu Produkt B wechsel. Je näher diese Konventionen von den beiden Produkten aneinander liegen, also je gleicher die sind, desto leichter tue ich mich.

Matthias: [00:16:03.99] Da gebe ich dir recht.

Alex: [00:16:06.09] Und es wurde für für die eine all umfängliche, für alle. Aber da würde ich würde eher nicht aufs Projekt Ebene sondern eher viel mehr aus auf den Sprache gemünzt oder. Also unternehmensweite Sprache Sprachregelungen von jede Sprache hat bestimmte Eigenheiten, bestimmte Formatierungen und bestimmte Formate. Die würde ich auch gerne einhalten. Heißt, wenn wir ein Projekt erarbeiten Mit C# haben wir andere Konventionen, als wenn wir im Projekt B arbeiten, in Java oder in Projekt C mit JavaScript, was auch immer.

Matthias: [00:16:46.47] Ja klar, dass da dann noch mal komplett andere Conventions gelten, ist eh klar.

Alex: [00:16:50.92] Ja, aber ich würde dann nicht viel weiter gehen. Ich würde dann innerhalb von JavaScript oder innerhalb von Java oder innerhalb von C. Ich hab versuchen, dass alle ungefähr gleich arbeiten.

Matthias: [00:17:05.43] Da gebe ich dir auch vollkommen recht. Ich würde auch nicht empfehlen, dass man jetzt seine eigenen Conventions irgendwie in der IDE oder so was konfiguriert, sondern ich würde mich schon an den STANDARD halten. Also das wäre schon mal eine Empfehlung und es gibt für glaube ich wahrscheinlich jede Sprache irgendwie Standards, die man sich da anschauen kann.

Alex: [00:17:26.79] Also ich war für mich nochmal kurz es muss nicht nur eine sein für alles, weil es genau keinen Sinn macht, weil an jede Sprache andere Konzepte und Formate mit sich bringt. Aber es sollte nicht allzu viele sein. Also ich würde eher, wie ich gesagt habe, bei den Sprachen bleiben, die wir verwenden und für jede Sprache eine Code Konvention haben. Das wurde mir reichen. Und natürlich, wenn du anderer Meinung bist.

Matthias: [00:17:56.40] Ja, wir können durchaus auch mal unterschiedlicher Meinung sein.

Alex: [00:17:59.53] Echt jetzt mal. Unglaublich sowas.

Matthias: [00:18:04.11] Ich sehe es halt tatsächlich eher so. Also wenn ich jetzt das, was ich X Enkel Projekte oder so was hätte, dann würden die letztendlich ja schon alle irgendwo den gleichen Coding STANDARD weil eben über irgendein Tool wie esLint oder sowas aber trotzdem hätte ich halt in meinem Projekt eine ganz spezifische Konfiguration wo ich dann zum Beispiel einzelne Regeln deaktivier, weil Reasons und da kann man jetzt wahrscheinlich auch drüber streiten, haben wir jetzt die unterschiedlichen Projekte, die gleiche die Coding Standards, obwohl sie halt einzeln unterschiedliche Regeln vielleicht deaktivieren oder es zählt es als eigener Coding Standards. Das ist halt dann auch nochmal so ein Punkt.

Alex: [00:18:50.77] Weiß ich jetzt wirklich nicht. Aber okay, ich kann, ich kann mich dir annähern und jeder kann es machen, so wie er will, solange die Unterschiede so wenig wie möglich sind.

Matthias: [00:19:02.44] Genau das sollte immer das Ziel glaube ich sein.

Alex: [00:19:06.88] Also es gibt gewisse Standards und diese Standards sollten wir verfolgen. Es gibt Standards, die weltweit gelten für Programmiersprachen, aber auch unternehmensweite Standards sollten wir einhalten und alles andere, was nicht geregelt ist. Mach, was du willst. Kann man damit gehen?

Matthias: [00:19:25.54] Kann man damit gehen, ja.

Alex: [00:19:26.91] Na gut, dann geh mal damit. Also, Leute, jetzt habt ihr es. Code Conventions sind wichtig, weil es es leichter machen, dass wir der Code von anderen Kolleginnen und Kollegen verstehen können und lesen können, weil ungefähr die gleiche Struktur immer herrscht. Das ist für mich der der wichtige Punkt. Der wichtige Punkt für dich.

Matthias: [00:19:52.54] Ja. Coding Standards? Nein. Schaut es euch echt an.. Einigt euch auf gemeinsame Regeln und ihr werdet sehen, dass es auch sehr viel andere Benefits wieder hat. Also ich habe das selber in dem Projekt gemerkt, wo wir immer das Problem hatten, dass wir extremst große Merge-Requests hatten, wo es extrem schwierig war, die eigentliche Änderung rauszusehen, weil die Leute es immer umformatiert haben. Also die haben an den Sachen gearbeitet und haben halt dann zum Beispiel statt zwei Spaces haben sie dann zwei, statt vier Spaces, haben sie zwei Tabs oder einen Tab als Einrückung gehabt und dann wurde es immer umformatiert und dann hast du einen riesigen Wust an Änderungen, die vollkommen irrelevant sind für die eigentliche Codeänderung. Und dann merkt man erst, wenn man solche Standards hat, die auch erzwungen werden von Tools wie auf einmal, die man Requests dann auch zusammenschrumpfen. Auf einmal sieht man, was ändert sich wirklich. Das ist aufwendig, halt so ein Benefit, den wir jetzt noch gar nicht angesprochen haben, der bei solchen Geschichten einfach mitkommt.

Alex: [00:21:05.50] Wir könnten bestimmt noch sehr lange über Code Konventionen reden, aber wir sollten vielleicht eine andere Praktik Methode, die wir verwenden können. Und ich würde jetzt von unserer Liste ein paar überspringen und gehen auf das Thema Design. Brauchen wir überhaupt Design? Müssen wir eine Designphase wie du erinnerst dich im Wasserfall Analysis Design blabla? Brauchen wir diese Phasen oder brauchen wir dieses dieses Design? Und wenn ja, wie soll es aussehen? Was ändert sich?

Matthias: [00:21:46.54] Wahrscheinlich kommt da der klassische Spruch ganz gut. „It depends“ Ja, also ich sag mal Design macht ab einer gewissen Anwendungsgröße mit Sicherheit Sinn. Frage ist halt, wie strikt und wie geißelnd das ganze passiert. Und wenn halt das Design und die Implementierung am Ende zusammenpassen, dann hat auch keiner was gewonnen.

Alex: [00:22:16.52] Genau da, da will ich auch mal hin. Ich mach’s kurz. Brauchen wir Design? Ja, das brauchen wir. Wir brauchen kein Design, wie wir es früher gemacht haben. Ich kann mich daran erinnern, das hatten irgendwelche super schlauen Menschen und haben monatelang darüber sinniert, wie die Anwendung Design sowohl optisch als auch zu architektonisch, was auch immer. Und dann stand fest und dann musste das einfach gemacht werden. Dat bitte nicht mehr. Was wir durchaus an Design brauchen, ist aber die am Anfang zumindest die Gruppastruktur. Wie wollen wir die Anwendung aufbauen? Welche Architektur Entscheidungen treffen? Wie soll das grob aussehen? Welche Detaillierungsgrad wir da brauchen? Ich sage da immer Am Anfang brauchen wir weniger. Und je weiter, je mehr von dem Projekt wissen, je mehr wir dran gearbeitet haben und immer mehr wissen über das, was wir tun und was am Ende rauskommen soll. Diese Designphase allein ganz, ganz vorne gibt es nicht mehr. Design wird gelebt, über die ganze, ganze Leben des Projekts. Und deswegen Design brauchen wir. Aber anders aufgeteilt und wichtig dabei sehr, sehr, sehr, sehr wichtig. Design ist Design und Implementierung ist Implementierung, also Design sagt mir, wie ich eine – wie ich meine Anwendung Architektur mäßig aufbauen kann, wie meine Anwendung auszusehen hat, aber nicht, wie ich sie zu programmieren habe.

Alex: [00:24:03.39] Das will ich damit damit meinen. Und auch wenn wir ein Design gemacht haben, dann sollen wir uns bitteschön bei der Implementierung auch dran halten. Und das, was in dem Design steht, das sehen wir auch in der Implementierung und umgekehrt. Wenn ich mir die Implementierung anschaue, erkenne ich das Design, weil sonst haben wir zwei Stück Papier, schlimmstenfalls, die doch nicht zueinander passen. Was ist jetzt die Wahrheit? Also die zwei Aspekte sind für mich in Bezug auf Design und unsere Arbeit auch ja relevant. Das müssen wir uns angewöhnen. Design so immer mitschleifen. Es lebt immer mit. Es gibt nicht erst Design, dann Implementierung und Sense – Die kennen sich sonst nicht, sondern die leben miteinander über das ganze Projekt. Und das Design wird immer von vom Grobe in detaillierter, wenn wir es brauchen nicht alles vornherein. Eben, wir implementieren das, was wir designt habe, wie wir es implementieren, bis unser Bier dann. Das hat mit dem Design an sich nichts zu tun, aber eventuell mit der Architektur. Das wäre für mich, was das Thema Design betrifft, was für mich wichtig ist, also diese Praktiken sich anzugewöhnen. Ja, was denkst du dazu?

Matthias: [00:25:26.25] Ja, ich versuche jetzt gerade nur so mental den Bogen zur Verständlichkeit an sich zu ziehen. Aber es schadet natürlich auch nicht, wenn Design verständlich ist.

Alex: [00:25:36.72] Also wir brauchen Design, weil das hilft uns zu verstehen, was wir machen können, wollen und müssen. Unter anderem also diese, diese Design. Für mich wäre es auch Design, wenn wir ein DDD Workshop machen lernen, zu was designen wir unsere Anwendung auch?

Matthias: [00:25:55.92] Also es zahlt auf die Verständlichkeit des Projekts ein, sozusagen.

Alex: [00:26:00.99] Ja, ja, ja, ja, ja, natürlich. Vor allem auch, wenn wir ein klares Design und eine klare Implementierung, die beide verständlich sind und die zueinander passen. Aber es gibt nichts Schlimmeres, um dich völlig zu verwirren. Wenn irgendwo steht, du hast ein Message Bus System in der Anwendung implementiert und du findest es nicht im Code.

Matthias: [00:26:22.93] Ja.

Alex: [00:26:24.81] Da wirst du doch kirre.

Matthias: [00:26:26.45] Ja.

Alex: [00:26:27.48] In dem Sinne hilft die Verständlichkeit, wenn die zueinander passen. Und das, was in Design steht, widerspiegelt sich in die Implementierung und umgekehrt. Macht einfach das Ganze verständlicher. Auch meine Ansicht zumindest. Mag ja sein, dass ich mich schon wieder völlig irre, aber meine Erfahrung sagt mir, dass wenn ich irgendwas lese das muss so sein, Akzeptanzkriterien irgendwas und ich das im Code nicht finden kann. Ich werd kirre. Ich weiß nicht, wie es anderen geht, aber ich kirre.

Matthias: [00:27:01.59] Aber vielleicht ist es ja da und hat nur einen schlechten Namen Alex.

Alex: [00:27:05.76] Es kann ja auch sein, aber da kommen wir noch dazu, da kommen wir noch dazu.

Matthias: [00:27:11.07] Das wäre jetzt die perfekte Überleitung.

Alex: [00:27:13.68] Kann ma gerne.Ja.

Alex: [00:27:15.09] Wenn du jetzt über Namensgebung gleich reden willst. Los fang an.

Matthias: [00:27:20.28] Ja, genau. Weil letztendlich. Es muss ja nicht heißen, nur weil ich etwas nicht finde in einem System, dass es nicht da ist. Vielleicht hat es einfach nur einen schlechten Namen. Also vielleicht heißt dein Messaging Plussystem in der Anwendung halt einfach Database.

Alex: [00:27:38.92] Los Wochos.

Matthias: [00:27:38.92] Ja oder lass es, aber „Los Wochos“ hätte noch weniger Schaden, als es Database zu nennen, Wenn es ein Messaging-System ist. Und es ist jetzt. Es klingt alles sehr lustig und so, aber ich glaube halt schon, dass die Vergabe von Namen ist a) eine verdammt schwierige Sache, um guten Namen und ganz zu schweigen ist ist noch viel schwieriger, aber auch so verdammt wichtig, weil das halt, finde ich, auf zum Thema Verständlichkeit einen riesigen Impact hat. Wenn ich schlechte Namen vergebe, macht es automatisch alles unverständlicher als es vorher war. Und das dazu. Sobald ich wie jetzt vorhin in dem Beispiel schon erwähnt, eine sehr komplexe If-Abfrage oder If-Bedingung, die, wenn ich da mit den Augen nur drüber scanne, mir sofort die mentale Last aufzwingt, einfach mit einem guten Namen weg extrahieren kann und dann steht da halt einfach getQuersummeOfDritteWurzelVonKeineAhnung, aber das hat viel weniger mentale Last für mich, als wenn ich diese Formel vor mir sehe.

Alex: [00:28:51.84] Kognitive Leistung.

Matthias: [00:28:53.61] Kognitive Leistung. Das ist das Wort, das die Ganze gesucht hat.

Alex: [00:28:58.23] Hättest gleich gefragt 🙂

Matthias: [00:28:59.61] Was will ich mit dem Mental die ganze Zeit? Naja, egal. Aber ihr wisst doch nicht, was ich meine.

Alex: [00:29:04.92] Also ja, für mich ist Namensgebung. Also alle andere Themen, die wir heute hier besprechen werden, sind wichtig. Aber für mich ist die Namensgebung, weil ich würde fast sagen das A und O der Verständlichkeit. Wenn ich meine Variablen nicht A, B, C, F und E nenne, sondern den entsprechenden Namen haben, dann kann ich beim Code lesen die kognitive Leistung, die ich einbringen kann, um zu verstehen, was da passiert, deutlich minimieren. Das muss unser Ziel sein, dass wir schneller und leichter verstehen, was da passiert und was da läuft. Ist Genauso wie der Beispiel, die du mit dem mit dem Funktion, ja komplexe Logik in eine Funktion packen, die Funktion einen entsprechenden Namen geben und dann die Funktion verwenden, anstatt diese Megalogik das gleiche mit variablen Namen. Wir merken wie gesagt Variablennamen A, B, C, n, J. Puh, viel Spaß. Es ist ein klarer Fall von Obfuscation.

Matthias: [00:30:09.06] Da hatte ich mal das Vergnügen mit einem Skript. Ich weiß leider heute nicht mehr, was das gemacht hat, aber es war auf jeden Fall sehr, sehr abenteuerlich, weil da wurden am Anfang vom Skript wurden irgendwie 30 Parameter p1 bis p30 definiert, wo irgendwelche globalen Werte von irgendwas reingespeichert worden sind und über das gesamte Skript verteilt wurden dann irgendwelche Zugriffe auf Drittsysteme gemacht und überall hast du nur p13 und du hast keine gedacht du wirst Irre. Bist die ganze Zeit, dann hast du P 13 gesehen, dann bist du hoch gescrollt, ganz hoch, wo die wo das Zeug importiert worden ist. Also Ah, okay, das ist das alles klar, dann wieder runter bis zu unten. War das schon wieder vergessen, wofür p13 stand?

Alex: [00:30:55.74] Also ja, das war bestimmt PHP.

Matthias: [00:30:59.58] Das war tatsächlich PHP damals.

Alex: [00:31:03.33] Nee, Mit PHP kann man auch super gut schreiben.

Matthias: [00:31:05.67] Ja, wie gesagt. Also den Code kann ich ja problemlos auch in Java schreiben, hindert mich keiner dran. Da weiß ich halt dann, dass vielleicht p1 ein String ist und p2 ein Date Objekt oder so, aber das wars dann auch.

Alex: [00:31:22.89] Wir machen einfach alles Objects.

Matthias: [00:31:25.38] Genau.

Alex: [00:31:27.06] Na jetzt mal ernsthaft Namen sind das A und O, die uns hilft. Ja einfach leichter zu verstehen, was da alles abgeht, was alles passiert, was der Code macht usw. vor allem auch der Beispiele, die du mit der Funktion eingebracht hast. Diese komplexe Logik in der Funktion rein zu packen. Ich muss gar nicht wissen, welche Logik genau dahinter steckt. Mir reicht zu verstehen, was es tut mit einer Erklärung, mit dem Wort, mit ein Satz kurzen Satz. Jetzt keine drei Zeilen, bitte.

Matthias: [00:32:04.65] Der kurze Einwand. Zumindest muss ich nicht in die Methode rein so lange, sich da kein Problem gerade verbergen.

Alex: [00:32:11.13] Solange ich es nicht brauche. Wenn ich es brauche, kann ich natürlich rein, aber ich muss nicht, wenn ich es nicht brauche, weil ich nur durch den Namen verstehe, was da passiert oder was ich mir auch manchmal denke. Zumindest denke ich, dass ich weiß, was da passiert. Ich hatte schon die Erfahrung, dass Namen, die andere Menschen für gut und völlig klar und verständlich und Erklärbär mäßig für mich völlig verwirrt haben. Und ich dachte, die Funktion macht ganz anders als das, was sie wirklich macht. Deswegen ist Namensgebung wirklich schwierig, wirklich schwierig, weil was für uns beide, wenn wir im Pair machen, ein guter Name ist, kann für eine dritte Person, die jetzt nicht der gleiche Kenntnisstand des Projekts hat wie wir. Häh? Sagt mir nichts. Also es ist schwierig. Und wenn man schon mal darüber redet? Es ist schwierig. Wie viel Zeit sollte man sich nehmen, um eine Variable zu benennen oder um eine Funktion zu benennen? Matthias?

Matthias: [00:33:19.26] So wenig wie möglich. So viel wie nötig. Nee, also das ist auch ganz schwer pauschal zu beantworten. Also ich verbringe teilweise schon viel Zeit mit Namen suchen und häufig ist es dann tatsächlich auch so, dass ich dann immer wieder die Variable auch refaktorier, weil ich mir dann anschaue, wie es sich dann im Code wo es verwendet wird, auch liest und dann gefällt mir das nicht. Und dann. Oder jemand anders hat noch mal einen Vorschlag, dann wird halt nochmal kurz refaktoriert, umgeschrieben, geguckt. Also es kann schon ein paar Minuten dauern.

Alex: [00:33:54.51] Okay, aber genau auf das wollte ich kommen. Heutzutag eine Variable ohne eine Funktion umzubenennen mit halbwegs aktuellen IDEs kostet nix. Deswegen kurz Gedanken der Ruhe machen – Ja. Lange darüber nachdenken, – Nein. Weil wenn ich sehe, dass es nicht passt, kann ich sie ja ändern und es kostet nichts. Deswegen würde ich nicht allzu viel. Also wie gesagt, also Gedanken machen. Ja, man darf sich Gedanken machen und kurz mal darüber sprechen, was der Name so. Aber ich hatte auch mal so halbstündige Diskussionen über wie eine Funktion oder wie eine Variable heißen soll. Eine Variable, die privat ist, in irgendeiner Klasse, ganz tief in weiß Gott was. Des lohnt sich nicht. Das ist gut, da wir ein halbwegs anständigen Namen geben und diese Name zu verändern kostet uns nichts. Ja, mit dem Refactoring Tools, die wir heutzutage haben, ist es zack, zack, erledigt. Bumm. Deswegen. Wie ich sagte, Gedanken machen ja, drüber sprechen ja. Aber bitte nicht ewig darüber diskutieren, wie eine X heißen soll.

Matthias: [00:35:15.03] Ja, ja, nee, ist nicht leicht. Es ist nicht leicht.

Alex: [00:35:18.75] Dann wir haben noch zwei, drei Punkte, wo wir noch reden möchten. Wir haben jetzt sehr viel über über die Form des Codes, über Namengebung, über Conventions, über das Design und die Implementierung auch zueinander passen und wie. Wir designen immer gemeinsam mit der Implementierung, nicht getrennt voneinander. Was ist aber, was die technische Sachen angeht? Zum Beispiel fällt mir jetzt irgendwas, das man Principle of Least Astonishment nennt oder das Prinzip – Wie kann man so was übersetzen? Du kannst besser als ich.

Matthias: [00:36:05.07] Das Prinzip der geringsten Überraschung vielleicht.

Alex: [00:36:07.77] Ja irgend so was. Also was besagt das? Code soll das machen, was wir erwarten, dass es tut? Ja, in dem Sinne, wenn ich irgendeine Get-Anweisung. – Ich bin jetzt in Java – zum Beispiel und sagt ja, get value, dann erwarte ich, dass ich ein Wert zurückbekomme. Was ich aber nicht erwarte, ist, dass gleichzeitig irgendein Status in der Klasse verändert wird. Und das hab ich aber sehr oft gesehen, dass in ein Getter irgendeine private Variable noch geändert wird. Ja, du lachst. Ich Echt! Ich habe so oft das gesehen.

Matthias: [00:36:44.61] Ja, ich glaub dir das schon. Und es ist ja nur Ausdruck meiner Überraschung.

Alex: [00:36:54.06] Ja Na dann. Und das ist das, was damit gemeint ist. Also, der Code muss das tun, was wir als Entwickler erwarten das es tut, wenn wir das lesen. Deswegen auch mal wieder den Namen Wichtig. Nicht vergessen. Und weißt du, wie schwer es ist, ein Bug zu finden, die durch sowas verursacht wird? Weil in einen Getter irgendeine Eigenschaft geändert wird, wo du nie erwarten würdest, dass da was geändert wird. Aber aus Reasons Ich – ist keine keine Bosheit von irgendjemanden oder irgendwas oder sonst irgendwas – irgendwann ist das Ding da aufgetaucht, weil zu der Zeit auch Sinn gemacht hat, keine Frage

Matthias: [00:37:35.76] Ich kenn ähnliche Sachen. Also ich habe auch irgendwann mit Schmerzen lernen müssen, dass es irgendwie vielleicht nicht so schlau ist, wenn eine Klasse von Properties gesteuert wird, die für irgendwelche magischen Mechanismen verändert werden. Nee, ja. Des

Alex: [00:37:56.22] Auch das ein wichtiger Aspekt für mich, auch für den Verständnis, um verstehen zu können, was da passiert, wenn wie gesagt Funktionen oder solche Konstrukte benutzt werden für irgendwas, was wir eigentlich nicht erwarten. Das macht, dass das Verstehen des Codes und das Verstehen von das was passiert in der Anwendung extrem schwer. Und deswegen sollten wir uns wirklich versuchen auch dran zu halten. Meine Meinung.

Matthias: [00:38:26.19] Joa, keine schlechte Meinung.

Alex: [00:38:29.01] Keine schlechte Meinung. Gut. Dann. Ich hätte noch Single level of Abstraction. Erst einmal muss man halt mal definieren, was ist. Was zum Geier ist ein Level of Abstraction? Ich kann das zwar nicht genau definieren, weil ich denke, ich bin – wie du wohl gesagt hast „it depends“, aber wenn ich zum Beispiel wenn ich eine Funktion habe in die Funktion, werden andere Methoden der Klasse aufgerufen und zwischendurch wird eine – Zehn Zeilen lang wird irgendeine Pixelberechnung gemacht und danach werden noch irgendwelche andere Methoden, die Funktion aufgerufen oder der Klasse aufgerufen. Das sind für mich klar zwei völlig unterschiedliche Levels. Der eine ist, ich rufe Funktionen oder Methoden in meine Klasse oder in andere Klassen und der andere Ich mache eine völlig Low Level Berechnung. Dann packe ich diese Low Level Berechnung lieber in eine Funktion, die nur das macht. Und dann ließt sich meine meine Funktion deutlich leichter als Das ist das für mich. Natürlich kann man das auch auf sehr viele unterschiedliche Sachen anwenden, aber für mich ist das ein Beispiel von des, was mir in meinem Werdegang immer wieder aufgetaucht ist und mich verwirrt hat. Weil du musst von von einer Verständnissebene. Ah ja, ich rufe Funktionen an, ja und ich weiß, was die mache, weil warum weiß ich, was sie machen Matthias?

Matthias: [00:40:10.03] Weil sie gute Namen haben, natürlich.

Alex: [00:40:14.47] Genau! Und auf einmal kommen da irgendwelche abstruse Berechnungen. Da muss ich wieder ein riesen kognitive Sprung machen. Und das macht es einfach komplexer zu verstehen. Schwieriger zu verstehen, was da passiert und warum da passiert und wie auch immer das ist, was für mich der Single Level of Abstraction aussagt oder die Auswirkungen, die auf mein Leben hat.

Matthias: [00:40:39.07] Klingt schlüssig.

Alex: [00:40:40.27] Was? Was würdest du jetzt darüber sagen? Würdest du meinen, das würde dir helfen? Das hilft dir, oder es ist Quark.

Matthias: [00:40:46.00] Natürlich hilfts. Ich finde nur tatsächlich, dass das ja auch durch ganz viele andere Prinzipien, über die wir jetzt schon geredet haben, ja eigentlich auch schon irgendwo abgedeckt ist. Aber es gibt halt jetzt dieses Prinzip, das da irgendwo mal postuliert wurde. Es ist auch okay.

Alex: [00:41:04.64] Okay. Und wie gesagt, alles was uns hilft, irgendwie die kognitive Leistung, die wir erbringen müssen, um irgendwas zu verstehen, zu reduzieren, dient eben dazu, unser Code und unsere Programme und unsere Anwendung verständlicher zu machen. Nicht nur der Code selber, sondern auch die Architektur kann davon profitieren. Also bevor ich zum letzten Punkt kommen wollte, ich, was los war, nicht völlig vergessen hatte. Natürlich gibt es sehr viele andere Prinzipien und Methoden, die wir auch später innerhalb von anderen Rubriken ansprechen werden, die auch dazu dienen, dass unser Code verständlicher wird, weil besser strukturiert, weil besser veränderbar, weil besser erweiterbar. Wie auch immer, ja, aber wir haben hier einfach nur ein paar davon genommen, wo unsere Meinung nach tatsächlich der Schwerpunkt des Prinzips oder der Methode eben ist, diese Verständlichkeit im Vordergrund zu haben. Hatten wir völlig vergessen, Matthias sowas zu erwähnen. Aber dann kam er zum letzten Punkt. Das ist auch ein total interessanter Punkt, wo du, Matthias, bestimmt viel zu erzählen hast. – Kommentare

Matthias: [00:42:19.90] Soll ich einen Kommentar zu abgeben, weißt du?

Alex: [00:42:24.04] Jawoll!

Matthias: [00:42:25.38] Ach ja, zweischneidiges Schwert, würde ich sagen. Ich bin da eher zwiegespalten, was Kommentare angeht. Also ich versuche sie eigentlich grundsätzlich erst mal zu vermeiden, weil ich glaube, dass es halt schon hilft, seinen Code entsprechend zu strukturieren, aufzubauen, die Benamungen richtig zu machen, dass man ganz viele Kommentare nicht braucht. Ganz schlimm finde ich Kommentare, die redundant sind. Also das ist auch wieder eine Geschichte aus der PHP Welt in den antiken PHP Zeiten, also vor PHP sieben, als es noch keine Typisierung gab, hat man sich beholfen, indem man zu docstrings über die Methoden gepackt hat, um seiner IDE im Prinzip die Typen beizubringen, die die Sprache eigentlich so gar nicht unterstützt in der Form. Und da war es dann immer ganz häufig so, da stand dann so was wie „@Param string email“ und hinten stand dann die Email und und dieser letzte Punkt, dieses die Email ist halt so redundant, in dem Fall.

Alex: [00:43:35.35] Aber, dass es kenne ich auch vom Java Docs.

Matthias: [00:43:38.53] Ja, da gibt es überall.

Alex: [00:43:40.27] Genau das gleiche.

Matthias: [00:43:41.59] Gibt überall. Das eigentlich worauf ich eigentlich hinaus wollte kam dann bei der Umstellung auf PHP sieben, als dann die Typisierung kam, weil da konntest du dann auf einmal den Typ deiner Variablen ja in der Methodendefinition mit angeben, aber die ganzen Leute hatten ihre Docstrings noch drüber, das heißt, du hattest das zweifach. Also dass diese Typisierung einmal durch das Typsystem oder Sprache und einmal durch dieses Hilfskonstrukt. Und die Leute haben das halt auch nicht entfernt. Das heißt, da ist halt dann unglaublich viel tote Dokumentation in Anführungszeichen. Das ist nämlich auch so ein Punkt bei Kommentaren. Die neigen halt leider dazu, nicht up to date zu bleiben, weil sie halt. – Wenn Sie jetzt die Implementierung an der Stelle, wo ein Kommentar steht, ändert, dann schlägt ja der Kompiliervorgang nicht fehl, nur weil da noch ein Kommentar steht, der nicht passt. Also das ist ja dem Compiler vollkommen Banane, was da für ein Kommentar steht. Und das heißt, wenn ich da Änderungen vornehmen und nicht dran denke, die Kommentare anzupassen, dann steht da halt letztendlich einfach Blödsinn und macht in meinen Augen die Verständlichkeit wieder schlechter. Und da muss man halt extrem aufpassen.

Alex: [00:44:53.71] Ja, verstehe ich. Also für mich Kommentare: auch zu vermeiden, wo es nur geht. Wir haben zu viel schlechtes über Kommentare. Wann sind Kommentare gut?

Matthias: [00:45:06.88] In meinen Augen sind sie dann gut, wenn sie eben zum Beispiel dabei helfen, eine Verwirrung zu reduzieren. Also es soll zum Beispiel heißen, ich muss in meinem Code irgendeine Anpassung machen, wo jeder, der sie sieht, da weiß ich schon, der wird sich denken, was hat der Trottel hier schon wieder für Mist gemacht? Aber ich musste das so machen, weil keine Ahnung. In der Lib, in der Version, die wir einsetzen müssen aus Grund X, y, z musste es an der Stelle so sein. Und da finde ich, ist ein Kommentar halt wertvoll, weil er dann diese diese Reaktion was hat der da schon wieder für Mist gemacht sofort entschärft, weil man sieht ah okay, da steht ja, der Grund soll möglichst nah an dieser Stelle dran sein, damit auch da wieder der Weg dahin möglichst kurz ist. Und da ist halt dann wichtig, dass wenn irgendwann dieser Hack, den ich da eingebaut habe, nicht mehr notwendig ist, dass dann auch der Kommentar entfernt wird. Das aber, und dafür gibt es in meinen Augen keine Lösung. Da hilft nur aufmerksam sein und versuchen diszipliniert zu arbeiten an der Stelle. Aber da kann ein Kommentar helfen.

Alex: [00:46:21.01] Ich erzähle aus meinem Leben ja.

Matthias: [00:46:25.12] Die Weisheiten des Alex.

Alex: [00:46:26.77] Oh Gott nee.

Alex: [00:46:28.97] Aber Kommentare, die ich auch mal selber geschrieben habe, hast du bestimmt auch mal gesehen. Funktion, Methode, Klasse irgendwas und dann irgendwo mit dem Code Schräger, schräger mal wieder Java.

Alex: [00:46:42.44] Todo: Doppelpunkt.

Matthias: [00:46:44.65] Oh, die guten Todos.

Alex: [00:46:47.42] Hast du schon mal gesehen?

Matthias: [00:46:48.68] Wir paarmal auch schon selber verbrochen

Alex: [00:46:50.50] auch mal selber verbrochen. Ja natürlich. Ich auch. Wofür soll das gut sein?

Matthias: [00:46:56.66] Gewissenserleichterung, würde ich sagen.

Alex: [00:46:59.09] Ja, da pack ein Issue in Git.

Matthias: [00:47:00.62] Ja, ja, klar. Ich weiß. Aber da ist ja der Weg so weit dahein.

Alex: [00:47:04.10] Ja ja – Tschuldigung.

Alex: [00:47:05.63] So weit weg

Matthias: [00:47:07.16] So schnell in diesen Kommentar geschrieben. Also da verstehe ich jeden. Nein. Ja und Spaß beiseite, das ist ich.

Alex: [00:47:14.48] Ich mache die jetzt auch noch.

Matthias: [00:47:16.97] Ja.

Alex: [00:47:17.51] Aber bevor ich checke, mach ich sie wieder weg und mach die. Ich muss. Zum Beispiel? Ja, ich kann verstehen. Jetzt bin ich mitten drin in mein Dings. Ich will jetzt nicht raus und ein Issue schreiben. Das verstehe ich. Aber wenn ich einchecken will, da bin ich fertig. Und da kann ich mir das. Oh, ich weiß, ich habe zwei Todos mal geschrieben. Dann mache ich die zwei Issues, mache ich die Todos weg und dann kann ich meinen Code sauberer. Was ist ein Todo, die seit drei Jahren da drin steht? Hat es keiner gemacht, weil es keiner mehr braucht. Weil es nicht wichtig ist, Weil es keiner kann, was sich keiner traut. Aber was ist ein Todo Kommentar im Code? Finde ich nicht so, wie du gesagt hast. Also sinnlose Kommentare, Kommentare, die keinen Informationsgehalt anbieten – Wie, Wie gesagt @Param String eMail – Die Email. Ist auch völlig Banane, braucht keiner. Und auch wenn wir ab und zu mal doch Kommentare nutzen, dann tatsächlich, was du gesagt hast. Wir müssen höllisch aufpassen, dass die auch zum Code passen, dass der Kommentar und der Code sich nicht widersprechen, dass die zueinander passen. Es ist nichts verwirrender, als wenn im Kommentar irgendwas steht. Und dann lese ich den Code und der mal was sagt Hä?

Matthias: [00:48:44.43] Die Variablen heißen anders. Die Methode, die aufgerufen wird, heißt anders. Eigentlich hat der Kommentar überhaupt nichts mehr da zu suchen.

Alex: [00:48:53.07] Aber gut. Also ich will Kommentare nicht verteufeln oder schlecht machen, aber man sollte sparsam damit umgehen. Es gibt bessere Möglichkeiten oder wir haben bessere Möglichkeiten zu vermitteln, was irgendwas tut und warum. Da haben wir schon etliche aufgezählt und weil wir sie haben, sollten wir diese nutzen und nicht auf Kommentare setzen. Ich denke, wir haben jetzt aber erst mal –

Matthias: [00:49:23.81] Die Verständlichkeit Haben wir, glaube ich, abgehakt jetzt.

Alex: [00:49:25.67] Es ist verständlich genug, dass Verständlichkeit wichtig ist. Deine Zusammenfassung.

Matthias: [00:49:32.00] Ja. Also letztendlich würd ich sagen, das Thema Verständlichkeit ein sehr wichtiges Thema ist, dass es – Wir werden das wahrscheinlich in den nächsten Folgen auch noch sehen, dass wir immer wieder Schnittmengen haben, also dass die Verständlichkeit in ganz viele Themen mit hineinspielt. Zumindest gerade so mein Gefühl. Und ja, wie gesagt, tut euch selbst einen Gefallen und versucht euern Code verständlich zu halten, wenn ihr es nicht eh schon macht. würde fast ausgehen.

Alex: [00:50:08.51] Noch mal kurz Wir haben über Namensgebung total wichtig, über Kommentare oder Nichtkommentare, über Design und Implementierung. Wir haben auch die eine oder andere Prinzip. Single Level of Abstraction, Principles of least Astonishment, aber auch über Source Code Convention gesprochen. Und all diese Themen spielen eine Rolle in die Verständlichkeit, in den Akt, in der Versuch, unser Code, unsere Anwendungen verständlicher für andere und für uns selbst in der Zukunft zu machen.

Matthias: [00:50:48.02] Heute hast du erfahren, warum verständlicher Code wichtig ist.

Alex: [00:50:51.47] Und was du tun kannst, um Code verständlicher zu gestalten.

Matthias: [00:50:55.13] Wenn dir diese Folge gefallen hat, empfiehlt sie gern andere Menschen, zum Beispiel deinem Team.

Alex: [00:50:59.51] Und fängt am besten schon morgen an, euren Code noch verständlicher zu machen.

Matthias: [00:51:05.30] Seid auch beim nächsten Mal wieder mit dabei, wenn wir über Änderbarkeit sprechen. Ciao.

Alex: [00:51:10.82] Bis dann. Ciao.

off: [00:51:15.01] Die Macht der Craft Arbeitet für dich.