Dieser Episode beinhaltet keine Notizen

Alex: [00:00:00.06] Hallo und herzlich willkommen zu Eine neue Folge der Macht der Craft.

Matthias: [00:00:04.50] Heute starten wir mit einem neuen Thema, das uns auch wieder mehrere Folgen begleiten wird.

Alex: [00:00:09.57] Clean-Code, sauberer Code.

Matthias: [00:00:12.51] In dieser ersten Folge kriegst du mit, worum es dabei eigentlich geht und was du damit erreichen kannst.

Alex: [00:00:18.12] In den weiteren Folgen wirst du mehr über unterschiedliche Methoden und Praktiken erfahren.

Matthias: [00:00:23.73] Und heute bekommst du auch Infos darüber, was Clean Code nicht ist. Also einen kleinen Überblick und was es mit den „Four Rules“ auf sich hat.

off: [00:00:34.96] Die Macht der Craft abeitet für dich.

Alex: [00:00:42.24] Ich würde einfach anfangen, indem ich dich, Matthias, frage Was denkst du oder was ist deine Meinung nach sauberer Code.

Matthias: [00:00:53.46] Ja, also ich habe da für mich eine sehr einfache Definition gefunden, in der aus der Zeit, als ich Ausbilder war, also als ich für Auszubildende zuständig war und denen quasi das Programmieren näherbringen musste sollte. Und zwar sollte in meinen Augen damals Code nicht nur verständlich für andere ja, sage ich mal Junior- oder Seniorentwicklers sein, sondern eben auch für die Auszubildenden. Und das war so für mich die einfachste Definition von sauberen Code. Er soll ausdrücken, was er macht, soll keine – wie soll man sagen, keine Mysterien für den Leser in petto haben, sondern es soll einfach klipp und klar das, was da steht, das passiert auch. Und es sollte eben auch ein Auszubildender im, sag ich mal ersten Lehrjahr verstehen können, was da passiert. Und das war so für mich die Definition sauberer Code. Also ganz grob gesagt.

Alex: [00:01:57.50] Okay, ich glaube, das hattest du schon mal erzählt. Diese Metrik. Ja, sehr interessante Metrik. Also, ich verstehe es. Also, der Code ist gut genug. Was noch?

Matthias: [00:02:07.77] Ja, also letztendlich gehört da ja ganz viel mit rein. Also, ich persönlich bin noch ein Freund von guten Namen, also dass sowohl Klassen als auch Methoden und am Ende aber auch Variablen sinnvolle Namen haben, die ausdrücken, was der Inhalt des Ganzen ist. Und ja, aber da gibt es noch ganz viele andere Bereiche. Also wie ist der Code in dem Projekt formatiert? Machen es alle Leute gleich? Macht es jeder unterschiedlich? Und da wäre auch meine Definition sauberer – Im Sinne von Clean Code – wäre es natürlich, wenn alle das gleich machen und somit auch ja, wenn ich jetzt in irgendeiner Datei was ändern muss, ich nicht überrascht bin aufgrund der Formatierungen, die ich dort vorfinde zum Beispiel. Das ist auch so ein Punkt.

Alex: [00:02:56.43] Hm, okay, ich würde anfangen mit. Also ich glaube nicht, dass es allgemeingültige Regeln gibt, wie guter Code auszusehen hat und programmiert werden soll. Was ich aber durchaus glaube, ist, dass es gewisse Richtlinien, gewisse Methoden, gewisse Prinzipien gibt, die uns helfen können, diese Güte zu erhöhen. Das glaube ich schon. Für mich ist Clean-Code oder oder sauberer Code, wenn wir es in Deutsch halt mal sagen wollen. Eine Art Wertesystem hat für mich sehr viel mit Craft zu tun und mit diese sich drum kümmern, sich wollen, dass die Qualität, die innere Qualität der Software passt und stimmt aber auch – Es ist irgendwas, das uns bei der Arbeit hilft, die die Risikominimierung dient, die uns erlaubt, schnell und korrekt und richtig arbeiten zu können. Das ist auch eine Möglichkeit, die sich uns eröffnet. Dadurch ist technische Schulden zu vermeiden oder wenn wir technische Schulden machen, sie bewusst zu machen, also wissen, dass wir sie gemacht haben. Das ist für mich auch mein Thema, die wichtig ist in dem Zusammenhang und ja, das ist was für mich Clean-Code bedeutet natürlich auch viele andere Sachen und alles was du gesagt hast, ist auch richtig und korrekt. Aber in meinen Augen meinen mein innere ja Software Crafter würde diese Punkte hervorheben wollen.

Matthias: [00:04:39.93] Ich glaube auch, dass es sehr schwer ist, das tatsächlich jetzt in ein, zwei Sätzen herunterzubrechen, weil wie gesagt, andere Leute haben darüber ganze Bücher geschrieben oder widmen dem ganzen Thema ja ganze Webseiten. Und deswegen ist es auch, glaube ich, echt schwierig, da was kurzes, Prägnantes, Allgemeingültiges runter zu bringen. Und ich glaube auch, jeder bringt dann ein bisschen was anderes in den Fokus für sich selber, was ihm da am wichtigsten ist.

Alex: [00:05:06.99] Okay, dann, was wäre oder wo wäre für dich der Fokus zu setzen?

Matthias: [00:05:12.54] Also ich persönlich setze bei mir in erster Linie, also wenn ich über Clean Code spreche, dann ist für mich das im Vordergrund tatsächlich wirklich die Lesbarkeit Verständlichkeit, also dass jemand, der jetzt nicht den Code produziert hat, daher gehen kann und zum Beispiel im Zuge eines Code Reviews verstehen kann, was die Änderungen macht, dass ganz klar auch schon aufgrund zum Beispiel von Methodennamen hervor geht, was der Code, der da hinzugekommen ist, tut. Und solche Geschichten. Es steht für mich im Prinzip so im Fokus und ich meine, letztendlich haben diese ganzen wir werden das ja nachher noch in Gruppen aufteilen, aber die haben in meinen Augen auch ganz viele Querbeziehungen, also die bedingen sich gegenseitig oder begünstigen sich gegenseitig. Und ja, da hat man sehr viel Wechselwirkungen, würde ich sagen, auch unter diesen unterschiedlichen Methoden und Techniken.

Alex: [00:06:11.87] Ja, für mich ist das, was du erwähnt hast, extrem wichtig, in einem wirklich zentralen Punkt verstehen zu können Lesbarkeit, Verständlichkeit. Es gibt aber auch andere Punkte. Das widerspiegelt sich auch in die Aufteilung, die wir jetzt dann gleich machen werden. Aber für mich eine der wichtige Eigenschaften von Clean-Code ist, dass er richtig ist, dass er korrekt ist und nicht, weil ich der Meinung bin, dass es richtig ist, sondern weil ich es beweisen kann.

Matthias: [00:06:44.53] Ja, korrekt.

Alex: [00:06:46.45] Wir können durch Tests zum Beispiel beweisen, dass der Code, die wir programmiert haben oder die wir programmieren, die Erwartungen entspricht, die ich an den an der Funktionalität des Codes habe. Zum Beispiel. Das ist ein Faktor, die recht wichtig ist für für mich. Und das hilft in meinen Augen auch, zum Beispiel für die Verständlichkeit, die du gemeint hast. Weil wenn ich ein ordentliches Set an Tests habe, kann ich mich entlang der Tests runterhängen und um zu verstehen, was der Code macht, ohne den Code unbedingt lesen zu müssen.

Matthias: [00:07:20.41] Ja, ich weiß, was du meinst, aber das ist ja genau dann auch die umgekehrte Beziehung, weil die Verständlichkeit zahlt ja auch darauf ein, weil je leichter ich den Code und die dazugehörenden Tests verstehe, also verstehe, was passierte, desto eher kann ich ja feststellen, da fehlt zum Beispiel ein Test. Also ja, die Tests sind alle grün und bla bla bla. Aber es gibt halt irgendein Szenario und das habe ich nicht gedacht. Und wenn ich verstehe, was da passiert, kann ich diese Szenarien halt viel leichter herausfinden, die mir da vielleicht noch fehlen, da irgendwelche Edge-Cases oder sonstige Sachen.

Alex: [00:07:57.01] Ja.

Matthias: [00:07:57.67] Und das ist auch das, was ich meinte, dass diese Sachen sich untereinander eh dann irgendwie Wechselwirkungen auf jeden Fall haben. Wenn ich mich an das eine halte, macht es mir das andere leichter. Genauso mit der Erweiterbarkeit. Ist ja auch so, wenn ich verstehe, was da passiert und nicht raten muss. Ja, hier in diesem fünften verschachtelten if ganz unten. Wenn ich da jetzt was ende, dann könnte das passieren, was ich mir vorstelle, aber vielleicht auch nicht. Und genau diese Situationen, also dass ich in der Codebasis rate und hoffe, dass Dinge sich so verhalten, wie ich mir das wünsche. Dagegen soll oder das soll Clean Code eben vermeiden. Der saubere Code.

Alex: [00:08:44.05] Ja, auf jeden Fall abgedroschen und bisschen abgedroschen, aber immer noch richtig. Wir lesen mehr Code als wir schreiben in unsere Produktivleben. Wir lesen sehr viel mehr Code als wir tatsächlich schreiben. Und deswegen ist es super. Wie du gesagt, hast du das super wichtig, dass wir den Code verstehen, die irgendjemand anders oder wir vor zwei Wochen vor drei Stunden geschrieben haben.

Matthias: [00:09:15.19] Der Vergangenheits-Alex, wer kennt nicht?

Alex: [00:09:18.49] Wer kennt ihr nicht? Wer gibt viele, die ihn lieber nicht kennen würden?

Matthias: [00:09:25.93] Ja, gut.

Alex: [00:09:27.10] Ja, aber das ist ein ganz anderes Thema. Wenn ich den Code verstehen kann, die ich vorher produziert habe oder die irgendjemand produziert hat, tue ich mich deutlich leichter bei der Weiterentwicklung, beim Korrigieren von Bugs. Auch wenn Korrektheit so wichtig ist, wir machen alle Fehler und es ist auch okay. Wir sollen versuchen, sie zu vermeiden, aber wenn wir eins machen, ist es ja auch nicht die Ende der Welt – meistens zumindest. Und all diese Thematiken, all diese Problemen, all diese Werte vereinigen sich irgendwie in meinen Augen unter diesen Clean-Code Schirm. Was denkst du, welche sind die Gruppen oder die die Werte, auf die wir in zumindest wir Wert legen in diese, in diese Clean-Code Geschichte?

Matthias: [00:10:21.15] Ja also wir haben ja mal versucht das eben in Gruppen aufzuteilen und ich meine, wir haben vorhin schon ein paar genannt, eben zum Beispiel die Verständlichkeit und die Korrektheit, das wären jetzt zum Beispiel die jeweils so eine Gruppierung, wie wir sie eben sehen würden und wie sie, glaube ich, auch in der Literatur auch vorkommen. Was dann noch darunter zählt, ist zum Beispiel Änderbarkeit sowie die Erweiterbarkeit, also dass ich mein bestehendes System sowohl verändern kann, also dass sich das Verhalten anpassen kann, als auch, dass ich das Verhalten erweitern kann, also zusätzlich Funktionalität hinzufügen. Und das sollte in dem Fall natürlich so einfach wie möglich vonstatten gehen können, ohne dass man jetzt grundlegend das Gesamtsystem irgendwie umbauen muss. Das sind dann zum Beispiel noch so Geschichten und dann hätten wir eben zum Beispiel noch die Effizienz, also dass wir jetzt nicht unnötige Operationen in while Schleifen innerhalb von foreach-Schleifen, wo dann ganz unten mit einem IF geprüft wird, ob ich überhaupt irgendwas machen muss. Na ja, also das ist eine so klassische Memoryleaks oder so was will ich damit verhindern. Also damit beschäftigt sich der Part.

Alex: [00:11:39.40] Zum Thema Effizienz. Ist das zahlen auch Sachen für mich hinzu, die unsere Effizienz als Entwickler, die uns erlauben schneller zu entwickeln oder sicherer zu entwickeln. Zählt für mich auch dazu.

Matthias: [00:11:53.38] Was würdest du da sehen? Zum Beispiel?

Alex: [00:11:55.72] Versions-Kontrollsysteme zu benutzen?

Matthias: [00:11:58.64] Ah ja, okay, macht Sinn.

Alex: [00:12:01.39] Das gibt mir die Sicherheit. Ich kann jederzeit von Stand A nach B, ich kann mir gucken, was ich vor drei Wochen gemacht habe. Kann ich wieder zurück? Ich kann ändern, ohne Angst zu haben, dass ich der Stand von vorher nicht mehr zurückerlangen kann. Also es gibt mir Sicherheit und Effizienz. Ich kann schnell arbeiten, aber es gibt andere auch.

Matthias: [00:12:18.61] Und was ich jetzt noch vergessen habe grad war eben die oder was noch nicht gesagt worden ist vergessen wirklich habe ich es nicht. Ist halt die kontinuierliche Verbesserung. Unser Plan ist jetzt eben, dass wir für all diese Gruppierungen, die wir uns da so zurechtgelegt haben, eigene Folgen machen würden, wo wir dann ein bisschen intensiver drüber sprechen, wie wir die einzelnen Bereiche genau. Und somit wird uns dieses Thema jetzt wahrscheinlich ein bisschen länger begleiten.

Alex: [00:12:46.33] Wir wollen ja nicht allzu lange Folgen haben, wir wollen die Leute nicht überstrapazieren. Wobei es für uns alle unsere Versuche sind, immer kürzere Folgen zu zu schaffen und nicht stundenlang darüber zu sinnieren.

Matthias: [00:12:59.77] Ja, wir schauen, wo wir heute rauskommen.

Alex: [00:13:01.45] Ja, das wird schon. Das wird schon. Aber noch mal ganz kurz Ich gehe noch mal die die Gruppierung, die Einteilung, die wir gemacht haben, durch. Und wir wollen uns um Techniken und Methoden kümmern, die die Änderbarkeit zugutekommen. Heißt, der Code zu verändern. Wir wollen uns um Techniken und Methoden kümmern, die die Erweiterbarkeit oder Erweiterbarkeit des Codes zugutekommen. Helfen heißt. Wie du gesagt hast, mehr Funktionalität hinzufügen, neue Möglichkeiten, dem Code hinzuzufügen. Was dem Effizienz hatten wir ja auch, Sowohl Effizienz des Codes wie auch die Effizienz erhöhen, mit dem wir entwickeln können. Ganz wichtig, aber ganz kurz erwähnt kontinuierliche Verbesserung. Ein zentraler Aspekt, die wir in jede zweite Folge glaube ich drauf rumreiten, immer lernen, nicht vergessen. Leute.

Matthias: [00:14:14.23] Man könnte meinen, es wäre wichtig.

Alex: [00:14:16.10] Ja, ja, könnte, könnte.

Matthias: [00:14:18.19] Der Eindruck könnte entstehen.

Alex: [00:14:20.02] Ja und der wäre auch richtig. Und dann noch das Thema Korrektheit und das Thema Verständlichkeit ist gut. Das heißt, wir haben 1, 2, 3, 4, 5, 6 Stück, das heißt wir bei mindestens sechs Folgen dazu noch hängen. Zum Thema Clean Code. Aber heute, für den Anfang kümmern wir uns um zwei kleine Themen. Der erste ist Was ist eigentlich kein Clean-Code? Was sind Code-Smells? So nennt man das, wenn in Code irgendwas mit der Zeit anfängt zu stinken? Nennt man es Codes-Smells und darüber wollen wir uns unterhalten Und dann. Ein zweites Thema ist die Four Rules of Simple Design. Wir wollen die mal kurz durchgehen, mal ein bisschen erklären, was es ist, weil wir der Meinung sind, dass es als Grundgerüst durchaus hilfreich ist bei der Entwicklung. Um und für Clean-Code im Allgemeinen. So, dann fangen wir mal an mit Code Smells. Matthias.

Matthias: [00:15:31.30] Genau. Also ich meine, wenn man sich drüber unterhält, was Clean Code ist, ist es häufig vielleicht sogar leichter zu sagen Woran erkenne ich denn, dass ich überhaupt ein Problem habe? Also ab wann stinkt meine Codebasis sozusagen? Und ja, da gibt es eine ganze Reihe und die werden jetzt nicht alle im Detail durchgehen, sondern ich will einfach nur mal so ein bisschen das Verständnis, was ist denn eigentlich ist so ein Code-Smell ein bisschen schärfen und deswegen habe ich hier mal einfach so ein paar allgemeine Beispiele mitgebracht, so ein klassischer Code-Smell zum Beispiel, gerade in so Webprojekten, wo man ja gern mal, ich nehme jetzt mal als Beispiel eine PHP Anwendung und ein HTML hat was das so ein klassischer Code-Smell zum Beispiel wär, wäre wenn ich in eine Source-File zum Beispiel dann HTML und PHP mischen würde, also wenn ich mehrere Sprachen innerhalb von einer Datei verwende. Das ist so ein Anzeichen dafür. Hier könnte es ein Problem geben und.

Alex: [00:16:35.59] Da geht es auch anders.

Matthias: [00:16:37.45] Ja. Nämlich man könnte ja jetzt die beiden Teile jeweils in eigene Source-Files packen und die dann. Es gibt auf jeden Fall dann Mittel und Wege und da gibt es halt eine ganze Reihe. Also man kann zum Beispiel auch, wenn man jetzt mal ganz simpel anfängt oder es heißt simpel, aber ich habe im Interface definiert, das mehrere Methoden beinhaltet und ich habe, aber in meiner Implementierung implementiere ich nur eine wirklich und lass die andere einfach irgendwie. Ich muss sie zwar mit implementieren, aber die macht halt nichts. Das wäre auch so ein klassischer Smell, dass man da einfach versucht, das Interface zu also ja das Ganze zu umgehen. Also ich brauche nur den Teil, deswegen implementiert ich nur den Teil, den Rest lass ich weg. Das wäre auch so ein klassischer Smell, weil ich will mich natürlich auf mein Interface insofern verlassen können, dass wenn ich da was aufruft, dass da auch was sinnvolles passiert und nicht einfach nur ja nichts zum Beispiel.

Alex: [00:17:39.34] Also kann man sagen, dass das diese Codes-Smell oder nicht Clean-Code sind Teile unseres Codes, die auf eine Art und Weise geschrieben wurden, die gegen ein oder mehrere von diese Kriterien von diese Werte, die wir aufgezählt haben, vorher diese Gruppierungen.

Matthias: [00:18:02.29] Genau.

Alex: [00:18:02.77] Verstoßt oder oder entgegenwirkt. Also verstoßen ist ein so starkes Wort.

Matthias: [00:18:08.08] Ja, aber letztendlich kann man glaube ich, Code-Smells schon immer ganz gut in diese Kategorien einordnen und die Gegenmaßnahmen dazu sind halt dann möglicherweise aus einer anderen Kategorie oder vielleicht auch einfach was komplett anderes. Aber ja, genau, Aber so kann man das ganz gut zusammenfassen. Und wie gesagt, es gibt da eine ganze Reihe. Wir werden dazu vermutlich eine eigene Folge machen, wo wir wirklich nur über Code-Smells reden wollen. Und ich glaube, da werden wir dann auch deutlich tiefer ins Detail gehen und uns das mal ein bisschen genauer anschauen.

Alex: [00:18:40.86] Ja, ja, das machen wir. Ich glaube Codes-Smells habe nein eine eigene Folge verdient. Es gibt zu viele davon. Ich denke, das Ziel soll nicht sein, dass wir jetzt alle durchgehen, sondern dass wir ein paar Beispiele nennen, was wie man damit umgehen kann usw. und so fort. Was noch? Was kann man noch über Code-Smells sagen?

Matthias: [00:19:00.85] Naja, Sie Letztendlich sind Sie erst mal ein Indikator, dass man was verbessern kann. Also es ist jetzt auch kein „Nur weil ich einen Code-Smell in meiner Codebasis habe, ist Hopfen und Malz verloren“, sondern man sollte halt einfach ein Gespür dafür entwickeln. Also wenn man über solche Code Smells stolpert, wenn man die sich damit ein bisschen beschäftigt hat und ein bisschen Erfahrung hat, dann erkennt man solche Geschichten auch, wenn man über den Code geht und dann kann man eben so. Vermutlich werden wir da draufkommen, aber als zum Beispiel die Boyscout rule anwenden und ich hinterlasse einfach die Klasse, an der ich grad arbeite ein bisschen sauberer als ich sie vorgefunden habe, kann somit kontinuierlich meine Codebasis verbessern, wo wir wieder bei der anderen Kategorie kontinuierliche Verbesserung wären. Und das sieht man nun, das hat halt alles irgendwo dann auch so Wechselwirkungen.

Alex: [00:19:57.04] Hm, und was meinst du, müssen wir alle Code Smells, die in unser Code zu finden sind, immer und sofort korrigieren oder oder verändern oder anpassen oder verbessern?

Matthias: [00:20:11.41] Ich würde mal sagen, es kommt drauf an. Also sehr diplomatisch. Ja, wie immer. Na ja, also man kann da keine absolute Regel aufstellen, weil wenn es jetzt in einem Codebereich ist, der sich nie ändert und der sehr stabil läuft, dann muss ich unter Umständen diesen Code-Smell auch nicht entfernen. Vor allem, wenn es, wie soll man sagen, ein relativ komplexer Umbau wäre. Zum Beispiel. Wenn es jetzt aber an der Stelle ist, die sich im Gesamtsystem an der Stelle ist, die sich sehr häufig ändert und wo mir diese diese Entfernung des Code smells insofern Mehrwert bringen kann, dass ich das System zum Beispiel einfacher verändern kann an der Stelle, dann würde ich sagen unbedingt in dem anderen Fall, also wenn es eben nur in Teil von meinem System ist, der sich nie ändern wird und der seit zehn Jahren stabil läuft, dann muss nicht sein, dann kann man sich auch verkünsteln in meinen Augen.

Alex: [00:21:11.70] Was für mich wichtig ist in diesem Zusammenhang ist. Entfernt alle, die ihr entfernen könnt, ohne übermäßiges Zusatzaufwand zu generieren. Das wäre für mich die erste Regel. Also das, was einfach zu korrigieren ist, kann man einfach korrigieren. Ist, was kompliziert oder schwieriger zu zu korrigieren ist. Dann kann man bewerten, so wie du es gerade gemacht hast, wie viel Mehrwert ich von der von der Änderung hab oder nicht. Was aber ganz schlecht ist, ist sich überhaupt nicht drum zu kümmern. Es gibt Tools, die man über den Quellcode laufen lassen kann, die dir dann Codes-Smells und andere Informationen geben. Aber wenn du zu also ich erwähne ich so was schon mal erlebt habe, also eine Anwendung, die wir über Jahre entwickelt haben, die dann fünf Jahre nach Start sagen wir okay und jetzt wollen wir eine diese Tools zum Einsatz bringen von Tschak, Tschak, Tschak, wir basteln awng rum und lassen das Tool laufen und dann kommen auf einmal 20.000 Meldungen. Und das ist wirklich keine Übertreibung. Je größer die Quellcode Basis ist, desto mehr Meldungen kommen raus. Und wenn du so was hast, also ich ich für mich war, was soll ich jetzt damit machen? Da fängst du schon gar nicht mehr an, dich damit zu beschäftigen, weil bei 20.000 Probleme Du kannst die hier nicht lösen, das ist so overwelming so überfordernd, dass du es nicht mehr herauskriegen. Deswegen von vornherein klein anfangen wenig machen. Bei jeder Check-In, bei jede paar Commits mal gucken: „habe ich irgendwelche Code-Smells produziert?“ Habe ich irgendwas produziert, die ich verbessern kann? Entweder gucken Pair-Programming, Code Reviews, irgendwelche Tools einsetzen, das hilft ungemein. Aber es ist wie gesagt ein kontinuierlicher, kontinuierlicher Prozess und nicht einfach am Ende – Zack – , weil dann kommt die große Keule und das kriegt man dann nicht mehr gebacken. Das ist für mich ein ein Aspekt, die, die man berücksichtigen muss und vor allem nicht vergessen darf.

Matthias: [00:23:24.98] Da bin ich absolut bei dir. Das passiert halt wirklich klassischerweise, wenn man zu einem relativ späten Zeitpunkt in einem Projekt versucht, diese zum Beispiel statische Code Analysen oder so was einzuziehen und dann zum Beispiel auch kein einheitlicher Coding-Standard im Team vorherrscht. Oder der Coding-Standard, den man definiert hat, widerspricht den Regeln, die aus dem Tool kommen und dann Konflikten, die natürlich alle Dateien. Ja, habe ich auch alles schon erlebt, aber auf der anderen Seite muss man halt auch sagen, ja, diesen Schmerz wird man haben, wenn man später in dem Projekt so was reinzieht. Aber in meinen Augen sollte es kein Grund sein, es nicht zu tun, sondern man muss sich dann in meinen Augen viel mehr eine Strategie zurechtlegen, wie ich das sinnvoll integrieren kann. Also man kann bei diesen Tools klassischerweise zum Beispiel auch bestimmte Regeln erstmal ausschalten. Also wenn man jetzt sagt, manche Regeln sind einem erst mal nicht so wichtig, kann man die auch über eine Konfiguration ausmachen und man schaltet dann nach und nach die Regeln immer weiter mehr dazu, weil ganz darauf verzichten ist in meinen Augen auch keine Option, weil dann ja, wird es ja auch nicht besser. Ich gebe dir vollkommen recht, diese tausenden von Meldungen, die überfahren ein erst mal und dann muss man einfach in meinen Augen eine gewisse Strategie entwickeln, wie man damit umgeht.

Alex: [00:24:52.77] Ja, es.

Matthias: [00:24:53.27] Ist trotzdem Nutzen.

Alex: [00:24:54.65] Hast du völlig recht. Ich wollte damit nicht sagen, wenn man es nicht von Anfang an macht, macht man es lieber nicht. Das wollte ich nicht sagen. Ich wollte nur darauf hinaus. Es wäre für euch besser und einfacher, wenn ihr es von vornherein mit einplant.

Matthias: [00:25:09.98] Immer nur meistens hat man halt tatsächlich nicht diesen Luxus, dass man von vorne anfängt, sondern meistens hat man ja bestehende Systeme, mit denen wir arbeiten. Ich meine, das haben wir ja in zig anderen Folgen auch schon gehabt, wo wir über Refactorings, Legacy Code und wie die Folgen alle heißen geredet haben. Und das, die haben ja alle dasselbe Problem. Also ganz häufig ist es ja Legacyanwendung, keine Tests, keine statische Codeanalyse, all das fehlt. Und da muss ich dann natürlich gucken, dass ich kontinuierlich diese Codebasis verbessern kann und eben von diesem Zustand wegkomme, dass nichts verständlich ist, nichts funktioniert. Aber was man halt wirklich sagen muss, das kann ein sehr langwieriger, schmerzhafter Prozess sein.

Alex: [00:25:58.14] Eine weitere Möglichkeit, das zu tun, ist eine einfache. Ein einfaches Set an Regeln nennt sich The Four Rules of Simple Design. Die hat Kent Beck mal postuliert, schon vor etlichen Jahren. Und die sind recht easy und die helfen wirklich, um sich an diese diese Clean-Code schon erst mal heranzutasten, um zu arbeiten. Und ich gehe jetzt einfach die die vier Regeln mal durch. Es ist erstens: alle Tests laufen. Zweitens: Der Code ist sprechend. Also der Code spricht zu uns und sagt uns, was es tut. Der dritte wäre: keine Duplikation und das vierte wäre: so wenig Elemente nutzen wie möglich. Das sind relativ einfache Regeln. Die sind auch in einer Reihenfolge 1-2-3-4. Das heißt, das die Tests grün sind ist wichtiger, als dass wir keine Duplikation haben. Weil Tests ist eins, Duplikation ist drei und wenn man versucht, diese Regeln zu folgen, hilft einen einfacher Code zu schreiben, zu strukturieren. Natürlich sind nicht die einzige Regeln. Wir lernen eine ganze Menge von Methoden und Praktiken, die wir nutzen können, aber das ist eine, die ich finde, recht hilfreich. Und was bedeutet das aber? Die erste Regel ist ja Alle Tests sind grün oder alle Tests funktionieren. Das bedeutet, wir müssen Tests schreiben. Es geht nicht ohne. Und das ist für mich die die zentrale Aussage von Diese erste Regel ohne Test. Automatisierte Tests läuft nichts. Und das ist ein sehr wichtige Bestandteil. Wir haben oder Ich habe viele Jahren, ich bin ja alt viele Jahren so programmieren, dass Testen – ja, ja, dass das passiert. Das machen wir dann, dass am Ende wird alles zamgeschmissen und es gibt die Test-Woche.

Matthias: [00:28:10.29] Hm.

Alex: [00:28:11.37] Dann wird die Anwendung getestet und Qualität wird – Es wird versucht einfach Qualität am Ende rein zu schieben. Und das funktioniert nicht immer so gut, wie wir es uns erhoffen. Deswegen Tests. Tests ist das A und O, wenn wir eine gute Test-Suite haben – ja – ohne geht Clean-Code in meinen Augen gar nicht, oder sehr schwer. Tells Intention? Der Code ist sprechend, der spricht zu uns. Das ist der Fall in so Sachen wie. Wie du schon sie erwähnt hast naming, wie, wie ich heißen meine Funktionen, meine Methoden, meine Variablen, all diese Sachen. Wenn ich Variablen habe, die ABC heißen und weiß Gott was die machen solche Sachen. Also das hilft sehr beim Lesen des Codes zu verstehen, was es tut. Und deswegen sollten sollte mein Code einfach zu mir sprechen und mir sagen, was es tut. Am besten, es soll sich wie wie eine Geschichte lesen, ein Code, ein bisschen übertrieben, aber ich hoffe, ihr versteht was. Oder du verstehst, was ich meine. Na klar. No Duplikation Ist doch klar. Also bin ich mein Code. Copy Paste – pfui pfui, igitt – mit Vorsicht zu genießen. Aufpassen, wenn ich den gleichen Code an drei Stellen wiederholen muss, ist – ja – wahrscheinlich könnte ich das besser machen, wenn ich eine Funktion extrahiere oder was auch immer. Und fewer Elements. Das ist eine die wogegen ich gerne verstoße, aber der besagt, wenn ich muss nicht von Anfang an anfangen und sagen okay, ich strukturiere jetzt mein Problem in 25 Klassen. Hm. Weil es jetzt mir erscheint, dass ich diese 25 Klassen brauche und dann fangen wir klein an und wenn wir am Ende diese 25 Klasse wirklich brauchen, dann ist es okay, wenn sie da sind. Das bedeutet nicht, dass wir alles in eine Klasse reintun können, weil dann verstoßen wir gegen andere Methoden und andere Prinzipien, die wir auch erfüllen wollen. Und wenn ich nur eine Funktion mit 2000 Zeilen habe. Das ist natürlich machbar, aber der Verständlichkeit nicht besonders zuträglich. Hm, immer versuchen, so wenig Elemente zu nutzen wie möglich. Da ist Abwägen selber wieder subjektiv. Haben wir ja vorher erwähnt, wie gut ein Code ist. Ist das eine subjektive Meinung?

Matthias: [00:30:50.34] Ja, absolut.

Alex: [00:30:51.60] Aber dies wäre für mich eine der Regeln. Die massig, – paar Regeln, Regeln in Anführungszeichen. Eine der Möglichkeiten, ja Hilfestellung, Hilfestellung klingt super – die man sich ja für den Anfang halt mal einfach nehmen kann. Das ist auch eine der Regeln. Wenn man in den Coderetreat, wenn man sich an unsere erste Folge erinnert, auch fast immer dabei ist bei den Sessions. Versucht, die Four Rules zu folgen und das hilft immer qualitativ besseren Code zu schreiben, einfach einfacher zu verstehen usw. und so fort. Das ist für mich was die, was die mir bringen in mein Doing. Also nicht weil die da sind, muss man sie nutzen. Aber ich finde, die bringen was. Und deswegen schlage ich vor, sie auch mal zu verwenden. Was? Was denkst du darüber?

Matthias: [00:31:52.70] Ich find die die Regeln auf jeden Fall eine super Sache. Vor allem, wie du schon gesagt hast, einfach auch um ja eine gewisse Unterstützung bei dem ganzen Thema zu haben, dass man sich einfach an den Prozess gewöhnen kann, wie man zu einem guten Design kommt. Und ich stimme da im Prinzip vollkommen zu. Also Passes the tests ist natürlich jetzt sehr allgemein. Also da steht jetzt zum Beispiel auch nichts davon, dass es meine Tests sein müssen. Also es heißt nur die Tests von dem Gesamtsystem müssen grün sein. Also da könnte man jetzt so argumentieren, aber ist natürlich nicht so. Also ich will natürlich für jeden neuen Code, den ich schreibe, will ich auch eigene Tests haben, keine Frage. Und was ich interessant finde ist, dass also ich würde die Punkte zwei, drei und vier. Ja, also wenn man sich jetzt mal so den Red Green Refaktor-cycle anschaut beim TDD würde ich Punkt zwei drei und vier ja voll in den Refaktorbereich sehen. Also ich programmiere, bis meine Tests grün sind und danach gucke ich Refactoring mäßig. Was kann ich verbessern, was kann ich irgendwo rausziehen, was kann ich irgendwo vereinfachen? Und wenn ich dann irgendwann zufrieden mit meiner Arbeit bin, dann kann ich sagen Jo passt. Für mich ist das jetzt clean Code. Idealerweise hat mein Team noch dieselbe Vorstellung von Clean Code wie ich und dann sind erst mal alle glücklich. Ich meine, es ist ja eh so ein Ding. Also auch für euer Team da draußen mögen ganz andere Kriterien erstmal wichtig sein als jetzt für dich und mich. Und wichtig ist es also in meinen Augen. Ist das Wichtigste, dass man als Team da eine Meinung hat. Was bedeutet für uns sauberer Code? Und auch als Team versucht, diesen Zustand irgendwo zu erreichen, eben durch kontinuierliche Verbesserung und und und. Wie gesagt, diese vier Regeln finde ich, sind erst mal ein super, eine super Hilfestellung um da anzufangen. Find ich spitze.

Alex: [00:34:05.51] Wunderbar. Dann.

Matthias: [00:34:10.68] Soll das auch mal reichen für den Anfang, würde ich sagen, oder?

Alex: [00:34:13.13] Ja, ja, ja. Beschäftigt euch damit, wenn du Zeit dazu hast. Four Rules. Clean-Code im Allgemeinen. Wir werden noch einiges darüber erzählen in den nächsten Wochen und Monaten. Anfangen werden wir mit dem Thema Verständlichkeit.

Matthias: [00:34:35.13] Sei also auch nächstes Mal wieder mit dabei.

Alex: [00:34:37.62] Und vergiss nicht, andere Menschen von unserem Podcast zu erzählen. Wir sehen uns.

Matthias: [00:34:44.08] Bis dann.

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