#15 Source Code Kommentare, Git Commits Messages, Merge Commits und Branch-Visualisierungs-Kunst

Herzlich willkommen zur Episode 15 vom Engineering Kiosk. Heute dreht sich alles um Kommentare im Quelltext und geht Comment Messages. Wie sinnvoll sind Kommentare? Ist der Code nicht selbsterklärend? Kann eine gute Namensgebung von Variablen und Funktionen Kommentare ersetzen? Sind To-Do-Kommentare im Code ok oder sollten diese doch eher ein Ticket im Bugtracker sein?

Wie hilfreich sind strukturierte Git-Commit-Messages? Und lieben oder hassen wir Merge-Commits? Und was hat eigentlich die Kunst von Finn Kliemann mit der Visualisierung von Git-Branches zu tun? All das und noch viel mehr klären wir in der kommenden Stunde. Ich komme gerade frisch vom Sport, energiegeladen und wollte dich einfach mal fragen, als sportlicher Wanderer, der du ja bist und Österreicher, weißt du eigentlich, warum man Sport macht?

Wanderer ist ja fast eine Beleidigung. Das klingt so, als wenn man auf der Ebene so dahin spazieren würde. Ich bin es gar nicht gewöhnt, solche philosophischen Fragen von dir zu hören. Seit wann bist du auf dem Philosophie-Trip? Ich bin im Homeoffice und da muss man halt mal...

ab und zu die Tür hinter sich zumachen, das Büro, Büro sein lassen und einfach mal die Pause an der frischen Natur genießen. Und da kommt man halt viel ans Nachdenken. Ja, damit man halt mal ein bisschen vom Job abschaltet. Und da stelle ich mir immer die Frage, was möchte ich eigentlich mal vom Wolfgang? Ich glaube, du hast nur den Tweet von, ich glaube, Hackmac2 heißt er, einer unserer Twitter-Hörer, der irgendwie geschrieben hat, man muss das Homeoffice...

wirklich stark trennen zwischen Job und Privatsphäre, damit das gut funktioniert. Ich glaube, das ist so eine Art Religionskrieg. Ich verstehe, dass man seine Arbeit, sein Privatleben komplett trennen möchte und das sollte man zu einem gewissen Grad auch tun und es hilft natürlich, wenn du die Wohnmöglichkeit hast, dass

du einen eigenen Raum für deine Arbeit hast, damit du wirklich abschalten kannst. Das ist komplett richtig. Ich muss zu meiner Verteidigung aber sagen, ich war schon immer so ein bisschen Workaholic und ich habe auch immer zugesehen, dass ich das liebe, was ich tue. Und wenn man das so sieht, dann ist die Arbeit auch nicht wirklich schlimm. Da muss man natürlich ein bisschen aufpassen. Burnout und Co. ist immer ein Thema.

Aber man hat ja Spaß, was man tut. Und solange man wirklich das liebt, denke ich, kann das auch mal ein bisschen verschmilzen. Ja, wobei du ja auch einen eigenen Raum hast, dein Office. Du arbeitest ja auch nicht im Bett. Meine Wohnsituation ist bezüglich Homeoffice sehr luxuriös. Das ist richtig. Eben, du hast es ja auch sauber getrennt.

Aber um auf deine Frage zurückzukommen, natürlich weiß ich, warum man Sport macht, die kardiologische Fitness zu trainieren. Für was sonst? Um einfach abends ein Bier trinken zu können. Der Körper hat Energie ausgestoßen. Ich brauche jetzt wieder wichtige Vitamine, Gerste und Co. Das wirkt ja isotonisch. Düsseldorfer Original Schlüssel seit 1850. Was trägst du da?

Frag besser nicht irgendein schwindeliges Weißbier mit irgendeiner No-Name-Marke, weil es das Beste, was man so in Holland bekommt. Wurde das frisch aus Bayern oder aus Franken importiert? Das ist eine gute Frage. Es kommt auf jeden Fall aus Deutschland. Keine Ahnung, wo es genau herkommt. Leider nicht aus Österreich. Wie stehst du so als Österreicher zur bayerischen Ess- und Feierkultur? Jetzt bin ich gespannt, was verstehst du unter der bayerischen Feierkultur, du als Bot-Mensch?

Da gehe ich die Stereotypenroute. Ich kenne, glaube ich, kein zweites Fest, was in Bayern gefeiert wird. Wir Stiroler können natürlich nicht viel anfangen mit Bayern, weil wir ja schon 1809 da gegen Bayern und Napoleon gekämpft haben und seitdem ist das sowieso alles verloren mit unserer Beziehung. In Geschichte war ich noch nie so richtig gut. Lass uns das skippen, sonst denken noch alle Leute, ich wäre doof.

Kommen wir mal zu unserem heutigen Thema. Was natürlich jetzt endlich mal technisch ist, weil diese Abstimmung, die wir auf Twitter durchgeführt haben, ob wir ein Karrierepodcast oder ein Engineeringpodcast sind, ist ja nur ganz, ganz knapp ausgegangen für Engineeringpodcast. Mir würde auch interessieren, was die anderen 30 Prozent denken, dass wir weder Software Engineering noch ein Karriere-Podcast sind.

Damit wir jetzt endlich wieder mehr Software Engineering machen, kommen wir heute mal zu einem Hardcore-Tech-Thema. Moment mal, also ganz im Ernst, wenn das ein Hardcore-Tech-Thema ist, dann muss ich mal zusehen und jetzt hier einen Aufruf starten. Liebe Hörer, ich suche in Zukunft einen neuen Podcast-Host. Ich möchte nicht mehr mit Wolfgang einen Podcast aufnehmen, wenn er dieses Thema, was wir jetzt besprechen, als Hardcore-Tech bezeichnet.

Also die Entwickler musst du mir zeigen, die gerne Comments schreiben und über Comments diskutieren. Natürlich ist es hardcore, dieses Thema. Verstehe. Was war deine Frage? Also ich habe jetzt eine Aufgabe für dich. Du entwickelst ja an diesem Source Control Ding. Das ist korrekt. Mach mal die letzte Datei auf, an der du was gemacht hast.

und erklär mir oder sag mir, wie viele Zeilen Code du drin hast und dann erklärst du mir, wie viele Comments du in diesem Fall geschrieben hast. Ich mache das selber mit einem Code von heute. Und du darfst jetzt nicht da irgendwelche Dateien rauspicken, die schön viele Comments drin haben. Eine random Datei. Ich gehe hier gerade File, Open, Resend. So, ich habe eine Datei auf. Mit wie vielen Zeilen? 86. Ihr habt 70 anzubieten. Wie viele Comments?

Und damit, das schaut schon nach sehr vielen aus. Du fangst schon an zu zählen mit 22. 22. Okay, ihr habt zwei. Aber ihr habt natürlich selbst erklärenden Code, muss man auch dazu sagen. Moment, da komme ich gleich drauf zu sprechen. Aber erklär mir mal ganz kurz, was deine Datei da macht. Wofür ist sie verantwortlich? Das ist eine gute Frage. Zwei Kommentarzeilen und keine Ahnung, was es tut. Okay.

Doch, doch, selbst erklärende Code. Die macht viele Mappings. Die mappt einige Felder von einem Objekt ins andere sozusagen. Ist JavaScript, ist auch dreckig, ist eh klar. Na okay, das will ich gleich wieder zurücknehmen. Man kann auch schön in JavaScript. Meine Datei ist in Go geschrieben. Meine Datei ist ein HTTP-Händler von einem GitHub- Server der GitHub Webhooks entgegen nimmt und dieser Code schaut sich das Webhook Event an.

und routet es in entsprechende Message-Queues. Und weißt du das jetzt, weil das in den Kommentaren drin steht, weil du dir erinnern kannst, wie du es geschrieben hast oder weil der Code selbsterklärend ist? Das sehe ich, weil das HTTP-Händler-Interface von Go implementiert wird und eine riesen Switch-Funktion drin ist, wenn die Aktion Create oder Suspend oder ähnliches ist. So viel Code mit solchen Strukturen habe ich hier nicht, deswegen weiß ich das sehr genau.

Und ich muss auch zugeben, die ganzen Kommentare dokumentieren eigentlich alle Webhook-Funktionen von GitHub, die ich noch nicht implementiert habe. Also das sind eigentlich To-Dos. Nee, To-Dos sind es nicht. sondern es sind Gründe, warum ich das jetzt zurzeit noch nicht implementiert habe. Und ob ich das jemals implementiere, weiß ich nicht, deswegen ist es bei mir jetzt kein To-Do.

Und ab und zu aber auch, was ein GitHub-User klicken muss, damit ich dieses Webhook-Event kriege. Zum Beispiel gibt es ein Webhook-Event New Permission Accepted. Wenn du eine GitHub-App installiert hast und sie fragt mehr Rechte an in deiner Organisation. dann musst du auf Accept drücken und dann wird ein Webfunk-Event getriggert. Und das habe ich halt auch ein bisschen dokumentiert, damit ich überhaupt noch weiß, was da überhaupt los ist.

Okay, wenn du jetzt so viele Kommentare geschrieben hast, wie stehst du denn allgemein zu Kommentaren? Das ist ja ein extrem trockenes Thema und irgendwie jedes Mal, wenn man über Kommentare diskutiert, es gibt sehr viele Meinungen, aber niemand findet es irgendwie richtig cool. Jeder weiß, dass es wichtig ist.

Warum machen wir jetzt eine eigene Episode drüber? Und sag mir jetzt nicht, weil ich das Thema vorgeschlagen habe. Ich beantworte die Frage gleich, aber ich möchte erst einen kurzen Test mit dir machen. Was hast du Sonntagabend gegessen? Keine Ahnung mehr. Woher weißt du dann, was deine 70 Zeilen lange Datei da gerade macht, ohne zwei, drei, vier Minuten darüber zu scrollen? Vielleicht erkennst du die Datei an der Struktur, aber...

Du hast da bestimmt eine Funktion drin, die irgendwie so String-Mapping macht. Nehmen wir mal ein Beispiel. Du kriegst einen String rein, an dem dritten Slash trennst du den String auf. Dann, wenn in dem ersten Teil ein Punkt ist, nimmst du von dem zweiten Teil die letzten drei Zeichen weg und returnst das Ganze. Und du willst mir sagen, solche Funktionen behältst du dauerhaft im Kopf. Ohne Kommentare, die anhand eines Beispiels zeigen, wie das Ding gesplittet wird.

Also ich glaube, die einzelnen Funktionen sind eigentlich wirklich sehr selbsterklärend. Aber du hast natürlich vollkommen recht. Man hat keine Ahnung, in welchem Kontext. dieser Teil verwendet wird, was der im Großen und Ganzen so macht. Und da wären ein paar Zeilen am Anfang, die das erklären, sicher sinnvoll. Ich bin mir gar nicht sicher, ob es sinnvoll ist,

in welchem Kontext diese Klasse zum Beispiel verwendet wird, weil das ist ja eigentlich nicht die Verantwortung der Klasse. Und das kann sich auch immer ändern. Da sind wir ja schon wieder bei dem Thema, wie up-to-date sind denn deine Code-Kommentare? Nehmen wir mal, du hast jetzt eine Java-Klasse oder ... In JavaScript gibt es ja keine Klassen. Das ist ja Prototyp-basiert.

Ja, es ist in dem Fall sehr spezifisch. Das ist keine klassische Klasse, die mehrfach verwendbar ist. Also es ist eigentlich nur so ein Subblock. kann man sagen, dass in einer eigenen Datei liegt. Ist ja auch egal, du hast eine Klasse, eine Funktion, irgendwas Isoliertes. Und ich finde, du solltest jetzt nicht an dieser Klasse oder Funktion schreiben, wie

Und in welchen Kontexten das verwendet wird. Weil das kann sich immer ändern. Und die Person, die dann diese Klasse oder Funktion nutzt, wird bestimmt nicht dann die Code-Kommentare in der Klasse ändern. Weil der Caller ändert sich ja. Der dann in einer ganz anderen Datei sein kann. Das ist, glaube ich, so ein bisschen...

der falsche Anwendungsfall von Kommentaren. Gebe dir vollkommen recht. In dem Fall, wie gesagt, ist es eine sehr spezifische Klasse, die ein spezielles Mapping macht und dieses Mapping sollte man vielleicht erklären, warum es dieses Mapping gibt, was dieses Mapping eigentlich da... da zu suchen hat. Aber ganz allgemein, der Kontext, da hast du natürlich vollkommen recht. Ich bin ein Riesenfan von Kommentaren und ich bin ein Riesenfan von sinnvollen Kommentaren.

Das ist sehr schön. Genau, was ist sinnvoll? Das ist jetzt ein höchst subjektives Thema. Nehmen wir mal als Beispiel, ich zähle eine Variable hoch, dann muss ich nicht als Kommentar increment i haben. Also das bedeutet, die Kommentare sollen natürlich nicht... genau das sagen, was der Code sagt. Das bedeutet aber nicht, das, was du da gerade gesagt hast, 70 Zeilen, zwei Kommentarzeilen, weil der Code selbst erklären.

Code ist nicht selbsterklärend. Das magst du vielleicht bei deinem Projekt mit 400, 500, vielleicht 1000 Zeilen Code sagen. Das liest man ja auch in 10 Minuten. Aber was ist denn, wenn du mal eine Code-Bate hast mit Fünf Millionen Zeilen. Da ist nichts mehr selbsterklärend, auch wenn du die Sprache...

Also ich glaube schon, dass das Code grundsätzlich selbsterklärend sein sollte und so geschrieben sein sollte, dass man eben nicht jedes If erklären muss, was denn dieses If dort macht, weil das If erklärt ja schon, was du da überprüfst. Du musst nicht schreiben, A ist... wir überprüfen jetzt, ob A größer gleich B ist, sondern das sollte der Code natürlich schon möglichst mit sauberen variablen Namen automatisch

von sich geben und sich selbst eben beschreiben. Also das, was der Code wirklich macht, Ich starte jetzt hier eine For-Loop oder eine Do-While oder ähnliches. Das muss man nicht kommentieren. Das ist genauso wie, diverse Sprachen haben diverse idiomatische Methoden, wie man die Sprache verwendet.

In Go ist das ein klassisches, wenn du eine Funktion aufrufst, dann returnt die meisten irgendeine Value zurück und ein Error und danach checkst du nach dem Funktionsaufruf, ob der Error nicht gleich Nil ist. Und wenn er nicht gleich Nil ist, dann reagierst du halt auf den Error. Das ist so ein klassisches idiomatisches Patterning-Go. So, endlich mal ohne dem Andi. Das heißt für mich endlich kein Hochdeutsch-Zwang. Und damit willkommen im sogenannten Werbeblock.

Aber keine Sorge, es wird kein Promo-Monolog, ganz im Gegenteil, ich wollte einfach mal Danke sagen. Danke, dass du zuhörst, lachst, mitdenkst und vielleicht auch noch was dabei lernst. Weil genau das treibt uns eigentlich an. Wir machen das, weil uns das Ganze Spaß macht und weil wir selber jedes Mal was mitnehmen für uns. Wenn du also die Mischung aus Schmäh, manchmal Tiefgang und vor allem Neugier gefällt,

Dann du uns doch einen kleinen Gefallen. Schnapp dir jetzt mal deinen Messenger deiner Wahl und schick einer Freundin oder Kollegin den Link zu deiner Lieblings-Episode. Weil so wächst die Community und mehr Leute haben einen Spaß am Ende.

Und übrigens, dieser Slot da kann auch deine Bühne sein. Die richtige bezahlte Werbung, die liest dann natürlich der Andi auf mehr oder weniger Hochdeutsch oder was mit dem Roboter immer so redet. Also Werbung für dein Produkt, eine Firma oder sonst was cooles. Und falls du ein gemeinnütziges oder Open-Source-Projekt hast, dann noch besser. Schick uns einfach eine Mail, wenn es zu uns passt. Nehmen wir das gern kostenlos mit.

Und jetzt zurück zum Podcast, natürlich wieder mitten, Andi. Du würdest jetzt nicht automatisch erklären immer, dass man eben diesen Arrow-Code checkt. Das meinst du damit, oder? Genau, oder ein Python-List-Comprehension. Das gehört einfach zur Sprache und die Autoren dieser Software haben diese Sprache aus irgendeinem Grund gewählt und dann nutzen die auch die Features. Also die idiomatischen Patterns sollte man da nicht dokumentieren, kommentieren. Außer, Achtung, außer...

Es wird hacky und es wird echt komplex. Was sind Beispiele für hacky oder komplexe Lösungen? Zum Beispiel Python. Python ist eine wundervolle Sprache, sehr dynamisch. Und in Python hast du ein sogenanntes Import-Statement. halt um andere Klassen, Methoden, Module zu importieren. Und du kannst echt...

dreckige Sachen machen mit dem Import Statement. Du kannst es dynamisch überschreiben. Also so, dass es echt undurchsichtig wird, welches Modul du da jetzt eigentlich dir reinholst. Wenn du in solche Gebiete gehst, dann würde ich sagen, pack mal irgendwo einen Kommentar drauf, damit man ein bisschen von der Magie, die da angewendet wird, versteht. Oder wenn es wirklich hart kommt an, es gibt ein paar C++ Features oder ein paar C-Makros.

da wo es richtig richtig dreckig wird wo echt komplexer kram gemacht wird sowas Sollte man dann gegebenenfalls mal einen Kommentar drüber setzen. Aber primär, warum? wir das einsetzen und was es denn macht und warum diese Lösung jetzt gerade gewählt wurde. Weil sonst kommt der nächste Entwickler und will es immer refactoren und dann fällt das ganze Kartenhaus zusammen. Für mich ist da immer ein gutes Beispiel, wenn ich jetzt in der JavaScript-Welt bin.

Functions, die achtfach verschachtelt sind und dann laufen irgendwelche Map-Funktionen, die wieder Funktionen aufnehmen, anonyme Funktionen und dann irgendwas umschreiben und wieder reducen und das ist achtfach verschachtelt, dann ist das einfach meiner Meinung nach

extrem schwierig und unmöglich zu verstehen. Und das ist zwar idiomatischer Code, Und man kann sich ihn durchdenken, aber dadurch, der so komplex ist, finde ich, verlangt der einfach nach einem Kommentar, was man denn so im Gesamten vielleicht macht oder vielleicht, dass man sogar eben sauber aufsplittet und dann die jeweiligen Unterbereiche dementsprechend auch kommentiert.

Das ist aber jetzt ein interessanter Punkt. Würdest du dann eher sagen, okay, der Code muss gerefactored werden, weil zum Beispiel die zyklomatische Komplexität, das ist jetzt eine Codemetrik, wie viel Level du runter gehst, if, if, if, if, umso höher die zyklomatische Komplexität, also wie viel.

Mögliche Pfade gibt es durch den Code, umso höher diese Metrik, umso schwerer ist diese Methode zu verstehen oder diese Funktion zu verstehen. Würdest du jetzt sagen, okay, das ist jetzt ein guter Anwendungsfall für Kommentare oder das ist einfach ein guter Anwendungsfall für die Tonne und da muss man leider ein bisschen mehr auf.

Ich glaube, es ist für beides. Natürlich, wenn man sinnvoll aufsplitten kann, ist es gut, aber es wird auch einfach ganz oft idiomatisch so geschrieben und da hast du halt drei verschachtelte Ebenen, die gar nicht so kompliziert eigentlich sind, aber wenn man sie das erste Mal liest, ist es halt echt schwierig, bis man sich da mal durchgedacht hat.

Das ist jetzt wirklich nicht Aufwand, dass man drüber einfach eine Zeile kurz schreibt, was da am Ende rausburzelt. Und wenn man es dann im Detail haben will, muss man sich halt das einmal durchdenken. Wenn man schlussendlich dann einzeln kommentiert, passiert es ja ganz oft, dass man dann wirklich eben den einzelnen Schritt immer nur kommentiert, der ja eh schon dasteht im Code. Also man muss es sich dann am Ende eh immer durchdenken. Da bringt das Kommentar gar keinen Mehrwert.

Wenn ich aber ein globales Kommentar sozusagen schreibe für diesen ganzen Blog, was da passiert, dann kann ich den Blog sozusagen überspringen, weiß, okay, in dem Bereich wird jetzt das gemacht. Sollte ich mal was ändern wollen, muss ich mich halt da dann durch diese drei verschachtelten Funktionen durchdenken. Aber das muss ja nicht immer, weil wenn ich es jetzt aufsplitt und dann kommentiere, dann steht halt jeweils das da, was eh schon im Code eigentlich dasteht.

Du sagtest gerade, du musst dich eh durch den Code durchdenken. Vertraust du den Kommentaren nicht? Also liest du immer dann den kompletten Code, der ausgeführt wird und sagst, okay, die Kommentare sagen zwar das Die erklären mir das hier, was hier eigentlich vor sich geht, aber ich vertraue denen nicht, deswegen schaue ich nochmal nach.

Nein, genau, im Gegenteil. Also wenn ich eben den Code gar nicht anfassen muss, angreifen muss auf österreichisch. Ist das dein Feind, der Code? Eben nicht, ja. Also für dich anfassen, damit du es auch verstehst. dann kann ich das direkt überspringen. Aber wenn ich dann natürlich in dem Bereich was ändern muss, muss ich mich durchdenken. Aber wenn ich nichts ändern will, dann kann ich das, wenn ein Kommentar dort steht, einfach schnell überspringen, weiß, okay, da wird das.

in einer idiomatischen Weise abgehandelt und abgearbeitet, aber da brauche ich jetzt nicht näher drauf eingehen. Also so für gewisse Strukturen, dass ich so sehe, wo sind die groben Blöcke, das kann schon auch sehr hilfreich sein.

Nur um das klarzustellen. Immer wenn ich jemanden höre, ich brauche keine Kommentare, weil der Code ist selbst erklärend, dann schreien bei mir die Alarmglocken. Der Grund ist ganz einfach. Wir haben gerade festgestellt, wir wollen nicht kommentieren, was der Code macht.

Wir wollen die Entscheidungen, die wir während des Programmierens getroffen haben, dokumentieren. Und wir wollen die Spezifika der Problemdomäne dokumentieren. Und was meine ich damit? Ich meine zum Beispiel mit den Entscheidungen während des Programmierens, zum Beispiel Performance-Entscheidungen. Nehmen wir diesen Webhook-Händler, den ich gerade beschrieben habe. Ich nehme ein Webhook-Event an und pumpe es in eine Message Queue.

Ich brauche aber nicht alle Daten, die ich von dem Webbook kriege. Also habe ich da einen Kommentar. Hallo? Ich mache das jetzt hier gerade einfach so. Ich nehme mir alle Daten und pumpe die in die Message Queue, weil das ist für mich gerade okay. Performance-technisch habe ich noch kein Problem damit. weil die Message-Size dann 3000 oder 4000 Byte ist, weil nicht so viele Nachrichten da durchgehen, habe ich einfach dran gepackt, weil das für mich jetzt gerade okay ist.

Später, wenn da richtig Traffic draufkommt, dann kannst du natürlich das Webhook-Objekt nehmen, das ummappen, nur auf die Daten, die du brauchst, um die Message-Size deutlich kleiner zu haben, um mehr Performance vom Message-Queue-Server zu machen.

Das meine ich mit Entscheidungen, die du während des Programmierens getroffen hast. Ja, das ist ja ganz wichtig, wenn man externe Quellen mit Also wenn man externe Quellen konsultiert hat, jetzt ganz klassisch Stack Overflow oder solche Dinge und man dann irgendeinen Code reinkopiert oder eben irgendwo gelesen hat, dass etwas Performance Vorteile hat und das dann eben so oder so macht. dass man diese Quellen eben auch in den Kommentaren mit reinschreibt.

damit, wenn jemand anderer sich das durchliest, dass er auch auf die Quellen zugreifen kann. Weil der hat ja keine Ahnung, dass du fünf Blog-Einträge gelesen hast und dann zu dem Schluss gekommen bist, aufgrund der fünf Blog-Einträge. Baue ich das jetzt irgendwie komplizierter oder mache ein spezielles Konstrukt nicht, was man üblicherweise macht und mache...

jetzt aber schon, weil es einfach Performance-Vorteile hat. Also ich glaube, dass man da Auch jedem anderen, der dann den Code lesen muss oder sich selber, wie es ja so oft ist, drei Wochen später oder drei Monate später oder drei Jahre später.

dass man sich da selber einfach wieder die Hilfestellung... Völlig richtig. Ich packe da meist dran so, dieser Code wurde inspired by... Hoffentlich nicht Gott oder so. Nee, nee, also da kommt dann wirklich ein hartes Spilling und oft ist es natürlich Stack Overflow.

Da muss man aber einmal ganz kurz die Lizenzkole rausholen, auch wenn ihr Code von GitHub kopiert. Achtet bitte darauf, dass ihr den nutzen dürft. Ich muss gerade zugeben, ich weiß gar nicht, wie die AGBs von Stack Overflow sind. Wie lief das eigentlich? Aber das wird bestimmt eine Frage sein, die wir in der Episode hier nicht klären werden. Aber was ich eigentlich meine ist, du hast jetzt gerade gesagt,

Wenn ich Code von Stack Overflow kopiere, der dann super performant ist, aber ich habe genau das andere Beispiel genannt. Ich sage, wir brauchen diese Performance hier gerade nicht. Und deswegen habe ich da einen Kommentar dran gepackt. der sagt, aktuell unter meinen aktuellen Bedingungen und in meinem Frame und in meinen Requirements brauche ich diese Performance nicht. Hier kannst du noch etwas rausholen, wenn du möchtest.

Ja, aber nicht heute, weil heute ist Sonntag 21 Uhr und ich möchte das Ding einfach nur als Fliegen kriegen. Und das sind so die Art von Kommentaren, die ich meine. um zu ein bisschen vielleicht auch zu dokumentieren, warum ich das gemacht habe. Jetzt kann man vielleicht darüber streiten. ob das ein Kommentar im Code sein soll oder eine Nachricht in der Git-Comment-Message. Aber dazu kommen wir gleich. Die zweite Art von Kommentaren, die ich dann da habe, ist meist diese Art von Business-Domäne.

Das ist das, was ich gerade geschrieben habe. Es gibt verschiedene Webhook-Events jetzt zum Beispiel. Nehmen wir dieses GitHub-Beispiel wieder. Und da habe ich wirklich Kommentare dran gepackt, das Webhook-Event created. Someone installs a GitHub-App. Weil es könnte ja auch Create sein. Created könnte ja auch ein Pull gekostet sein. Das sehe ich ja jetzt gerade hier.

In meinem Studium war das immer ganz lustig. Und zwar hatte ich einen unglaublich guten Professor, bei dem ich dann auch im Endeffekt meine Bachelorarbeit geschrieben habe. Und zwar war das das Modul Algorithmen. Da ging es natürlich um die Landau-Funktion, Notation, Big O, O von N, wer ein bisschen sich zurückerinnert, wer Redis-Fan ist.

Schaut mal die Dokumentation, da steht die Landownersation überall dran. Einer der besten Dokumentationen meines Erachtens. Nur die einzige, die du ordentlich gelesen hast? Sehr wahrscheinlich, ja.

Auf jeden Fall hatte er, so wie das ein ordentlicher Professor tut, Algorithmen in C gelernt. Und was machen C-Programmierer? Variablennamen mit mehr als einem Buchstaben sind eindeutig verboten, weil das Alphabet hat ja 26 Variablennamen. Also man ist auf 26 Variablen dann immer limitiert, ja. Aber für einen klassischen Algorithmus reicht das halt. So ein Bubble-Sort oder so ein Merge-Sort, der kommt damit locker auf.

Auf jeden Fall. Ich glaube, für so einen klassischen Algorithmus ja C und klar, ich rede jetzt nicht von Zählervariablen wie IJK. Ich glaube, die sind recht standardisiert in der Programmierwelt. Aber nehmen wir mal was wie V oder C für Content oder für Value. Ich sehe halt mehr und mehr Programmiersprachen, die gehen da ein bisschen zurück. Zum Beispiel Go ist auch so eine Baustelle. Bytebuffer werden oft B genannt.

Händler werden oft H genannt und so weiter. Also auch das Naming ist bei Go halt auch nicht immer wieder so geil. Vielleicht, weil die Jungs da auch mal ... Ob es aus der C-Ecke kam, wo dann beim JavaScript natürlich die ganze Sache ein bisschen anders aussieht. Wie siehst du das mit ordentlichen Variablen und Funktionsnamen? Können die Kommentare ersetzen? Ich glaube, da sind wir wieder bei dem selbsterklärenden Code.

können über Variablen-Namen und Funktionsnamen einfach sauber abgebildet werden, ohne dass man überhaupt einen Kommentar wirklich schreiben muss. Und ich glaube, dass die IJK-Variablen eigentlich nicht so ideal sind. Weil man kann da auch längere Variablen verwenden. Warum muss man immer das IJK verwenden, wenn das ein Index ist, der mitläuft? Und warum kann man da nicht einfach Index Position oder sowas hernehmen?

Es kann mir heute eigentlich niemand mehr erklären, dass irgendwas aus Performancegründen gemacht wird. Sogar wenn es interpretierte Sprachen sind, dann ist es heutzutage eigentlich im Normalfall kein Problem mehr.

Ja, aber ich glaube, speziell bei Zählervariablen ist das jetzt so standardisiert weltweit. Ja, aber wenn der Code ein bisschen komplexer ist, dann kann mir das schon wieder helfen, wenn ich drei Zählervariablen habe, damit ich nicht jedes Mal schauen muss, was ist jetzt I, was ist jetzt J, in welcher Schleife bin ich gerade, dann benenne ich das halt einfach um, weil die paar Zeichen heutzutage in jeder IDE wird Auto vervollständigt.

Das kostet mir genau null Zeit und Der Code ist einfach wesentlich einfacher zu verstehen, als wenn ich jedes Mal, man muss sich ja immer vorstellen, jedes Mal, wenn ich I oder J liese, fängt das Gehirn an, den Kontext aufzurufen. Einfach zum Beispiel zwei Weil-Schleifen, I und J als C der Variablen. Jedes Mal fängt der Kopf sofort denken an, ist I jetzt die äußere oder die innere Schleife?

Und das muss ich jedes Mal, wenn ich I und J liese im Code, muss mein Kopf den Kontext aufrufen und checken, wo ist I und J. Also solche Dinge, finde ich, kann man einfach verhindern. Okay. Heißt das jetzt, du bist pro selbsterklärenden Code? Ja, natürlich. Alles was... was ich mit dem Code selber erklären kann. Spare immer natürlich in den Kommentaren, sonst schreibe ich alles doppelt. Du hast gerade gesagt, dass du im Kopf immer umschalten musst.

Da kommt mir eine andere Frage in den Sinn. Für was sollte der Code deiner Meinung nach optimiert werden? Fürs Lesen oder fürs Schreiben ändern? Was verstehst du unter Schreiben? Also das Verändern vom Code. Genau, erweitern. Ist es nicht das Gleiche? Wenn ich was ändern will, muss ich es zuerst lesen und verstehen? Das ist korrekt.

aber also immer wenn du was änderst, liest du den Code, aber nicht immer wenn du den Code liest, änderst du was. Und deswegen will ich wissen, für was deiner Meinung nach der Code optimiert werden sollte. Also am liebsten ist mir der Code einfach, den ich ohne Kommentare...

lesen kann, wo ich einfach den Code lies, schnell scannen kann und super schnell verstehe, um was es geht. Und jedes Mal, wenn ich irgendwo eine Variable sehe, dass ich nicht die IDE brauche, die man irgendwie checkt, wo ist die Variable definiert worden, was ist das eigentlich für Variable, wo ist sie überschrieben worden. sondern dass ich das halt wirklich im Kontext

möglichst einfach verstehe, sobald ich es lesen kann. Ich habe irgendwo gelesen, dass jeder Quellcode eigentlich primär fürs Lesen optimiert werden sollte, weil jede Zeile Code drei bis fünf Mal mehr gelesen wird.

als verändert. Und nach meiner eigenen Erfahrung, zum Beispiel bei Source Control, in der Tat, ich springe sehr viel zwischen den pfeile es hin und her und lese einfach den Code, was mache ich denn da nochmal, damit ich weiß, mit welchen Daten ich hier eigentlich arbeite und Co. Also ich würde die Frage vielleicht eher so stellen und vielleicht

ist das mit Schreiben auch ursprünglich so gedacht, dass man quasi für das Ausführen des Code irgendwas optimiert, dass man den Coach so schreibt, dass er irgendwie performanter ist, dass man extreme, idiomatische Konstrukte verwendet, irgendwelche

Spezialkonstrukte, die vielleicht einem so bekannt sind, die gut funktionieren. Aber wenn dann halt niemand den Code lesen kann, dann ist halt die Frage, ob das wirklich so viele Vorteile bringt, dass das dann vielleicht bei der Ausführung Da sprichst du eine super Sache an und zwar, ich habe auch schon mal Programmierer in meiner Karriere erlebt, die haben sich für super klug gehalten und haben den Code...

fürs Ausführen optimiert und haben dann so smarte Geschichten gemacht wie Bit-Shifting und allem drum und dran. Bit-Shifting ist zum Beispiel so ein Thema, ja, hatte ich in der Uni, verstehe ich einfach nicht. Wenn ich da mal zehn Minuten drauf gucke und mir ein kleines Beispiel Skript schreibe, dann verstehe ich es auch wieder. Aber ich mag einfach nicht solche komplexen Prozeduren.

Sachen, die man, nehmen wir mal jetzt zum Beispiel die Web-Entwicklung, oft einfach in der Web-Entwicklung nicht braucht, weil der Performance-Gain von Bit-Shifting, wenn man mit DNS, HTTP und Co. arbeitet, ist in der Regel vernachlässigbar. Und dann würde ich zum Beispiel bevorzugen, dass man das Bit-Shifting zum Beispiel jetzt rauslässt.

einfacher lesbarer zu machen für Leute, die mit Bitshifting jetzt nicht so familiär sind. Ja, so ein Klassiker sind ja so mathematische Funktionen irgendwie, dass man was dividiert oder so und dann das über Bitshift löst.

Da bin ich auch der Meinung, dass das nicht viel Sinn macht. Es gibt natürlich schon Anwendungsfälle, wo man BitShifting intelligent verwenden kann. Aber auch da ist dann die Frage, kann man das nicht wegabstrahieren, wenn man es unbedingt braucht, dass man halt eine dementsprechende Funktion macht, die erklärt im Namen, was das ist.

eigentlich macht mit diesem Integer-Wert und dann im Hintergrund wird das BitShifting gemacht. Dann habe ich das wegabstrahiert und es muss nicht jeder wieder neu machen. Wenn es mir wirklich darum geht, dass ich irgendwie, keine Ahnung, einen Integer-Wert in zwei Unterbereiche aufteile und da irgendwie

Aber du hast vollkommen recht und ich kann mich da auch... Wobei ich natürlich jetzt mit meinem akademischen Hintergrund schon sagen muss, dass Bit-Shifting eigentlich so eine Grundlage ist, die jeder Informatiker verstehen sollte. Also ich habe da auch mit vielen Leuten diskutiert, weil wir das ja mal bei Trivago auch in einem Bereich eingesetzt haben.

Und es war schon teilweise extrem enttäuschend, wer aller Bitschäftigen nicht mal annähernd verstanden hat und sogar mit Bitweisen-Operationen schon. irgendwie an der Wand stand. Leider, muss man sagen. Also ein bisschen Grundlagen, finde ich, gehören schon auch dazu. Aber wie gesagt, man kann das alles weg abstrahieren und man braucht es da wenig sinnloserweise komplizierter machen, als es nötig ist.

Ich muss mich entschuldigen. Ich habe eine Ausrede. Ich habe keine Informatik studiert. Ich habe Wirtschaftsinformatik studiert. Verstehst du? Ich kann dir etwas über Stückzahlproduktionen erzählen, über Opportunitätskosten. Über Opportunitätskosten kann ich dir auch alles erzählen, ja. Genau, also da hast du eine Ausrede. Und du hast schon den Punkt. Also mir fällt da noch ein anderes Beispiel ein. Ich hatte einen Kollegen, der wirklich sehr gut in Bash-Programmierung war.

Und der hat halt dementsprechend auch Bash-Programme geschrieben, so dass sie niemand verstanden hatte. Und das haben halt nur Hardcore-Bash-Programmierer verstehen können, aber dadurch das einfach... Bash so ein Standard ist, den halt jeder so irgendwie versteht und auch eingesetzt hat. war dieser Code halt von anderen Leuten, die jetzt keine Bash-Profis sind.

einfach extrem schwer zu verstehen und nicht zu verändern. Das war ja das große Problem. Und wenn jemand mal verstehen wollte, was passiert denn eigentlich in dem Code, war nicht kompliziert, war nicht sehr lang, dann hat jeder normale Entwickler sofort aufgegeben, weil da waren einfach Konstrukte drin. die auch in meinem Leben noch nie in irgendeinem Bash-Code

gesehen habe. Und wie gesagt, das ist zwar cool und das ist auch alles okay und der Bash-Code ist wahrscheinlich sehr schön und idiomatisch, aber man muss sich halt auch überlegen, wer liest denn diesen Code? Schreibe ich den dann besser so, dass die Leute den verstehen, damit sie was lernen bei dem Code oder schreibe ich ihn so, dass er super schön ist und jeder sofort aufgibt.

Das ist natürlich so eine Gratwanderung, weil einerseits will ich vielleicht, dass die Leute auch was lernen, dass sie mal diese speziellen Konstrukte nachschlagen. Aber auf der anderen Seite, wenn dann jeder aufgibt und sofort sagt, um Gottes Willen, das brauche ich gar nicht probieren, irgendwie das zu verstehen, dann...

geht das halt auch am Ziel vorbei. Also da sollte man schon überlegen, wer ist denn die Zielgruppe? Wer liest denn meinen Code in Zukunft? Ich bin halt immer so ein Fan davon, dass man versucht, seinen Code so einfach wie möglich zu halten, weil er in der Regel geändert wird, weil Softwareentwickler werden bezahlt, um Code zu ändern. Und wenn viele Leute nicht verstehen, was da vor sich geht, dann haben die vielleicht auch Angst, den Code zu ändern.

Und dann hast du da auf jeden Fall irgendwann so ein paar Dateien. Da traut sich einfach keiner mehr ran. Weil die wissen nicht, hat das Seiteneffekte? Welches Kartenhaus bricht dann zusammen? Das soll keine Entschuldigung sein, meiner Meinung nach, dass man jetzt keinen idiomatischen Code schreibt und gute Konstrukte, Spezialkonstrukte, die es in Sprachen gibt, nicht mehr verwendet. ein Python-Programmierer, jetzt Python-Code.

verstehen muss und schreiben muss, dann soll der auch die Eigenheiten von Python verstehen. Ich glaube, das ist sehr wichtig. Wenn jetzt jemand aber nur Bash-Script aufruft und eigentlich BHP den ganzen Tag programmiert, dann kann ich halt dem nicht zutrauen oder

einfach voraussetzen, dass der die Spezial-Bash-Konstrukte von der neuesten Bash-Version versteht. Also ich glaube, da gibt es schon auf jeden Fall Unterschiede, was sie voraussetzen kann auch. Da hast du ein super Beispiel gemacht. Und zwar hatten wir bei Trivago... hatten wir ein paar Leute, die haben ziemlich viel automatisiert und dann richtig, richtige Make-Gurus. Die haben gute Make-Files geschrieben, die haben gefühlt ein ganzes Haus gebaut, wenn du irgendeinen Make-Command.

abgefeuert hast. Auf jeden Fall haben die auch Features genutzt von Make und von Bash. aus einer neueren Version. Und Mac OS X zum Beispiel, wenn du mit einem Mac arbeitest, liefert von Haus aus eine recht alte Bash-Version mit. Ich weiß nicht, warum sie es einfach nicht updaten. Verstehe ich nicht, weiß ich nicht, ist aber auch egal. Hast du eins dieser Make-Files ausgeführt, hast du erstmal einen Error gekriegt, weil das irgendwelche nicht supporteten Funktionen benutzt.

Du musstest also deinen Bash updaten. Und da ging es dann genau in diese Richtung. Da wurde Magie gemacht, die du erst verstanden hast, wenn du dich richtig mit dem Tool auseinandersetzt. Ich sage, es ist ein bisschen Zwiespalt, es ist so ein kleiner Zwiespalt, weil auf der einen Seite kannst du sagen, wir haben das Tool hier im Stack und wir nutzen das.

Wir nutzen das jetzt bis zum Extend, damit wir kein anderes Tool einführen müssen, weil da kommt natürlich auch eine andere Komplexität und so weiter und so fort. Auf der anderen Seite sagst du, dieses Feature wird jetzt oft nicht von Bash so genutzt, deswegen kennen das sehr viele Leute nicht, deswegen soll ich es nicht verwenden. Wo ist da deine Balance? Genau darum sollte man sich überlegen, wer ist die Zielgruppe und wie leicht ist die Zielgruppe.

Mache ich denn das Onboarding, wenn sich jemand meinen Code anschauen will? Vor allem, ich glaube, das ist ja ganz wichtig, wenn man Open Source entwickelt. dann will man ja den Einstieg auch einfach machen. Und dann muss ich halt auch wissen, auf wen ziele ich ab? Auf irgendwelche Juniors, die die Sprache lernen? Will ich nur die absoluten Pros?

an Bord haben, was will ich denn eigentlich machen? Und ich glaube, dementsprechend muss man sich halt auch überlegen, wie schreibe ich Code? Ich kann natürlich auch sagen, ich will einfach Leute, die den Code verstehen und die die Sprache gut können und ich will da alle Möglichkeiten nutzen. Fairpoint.

Ist auch vollkommen okay. Aber muss man dann halt auch im Klaren sein, dass vielleicht der Junior nicht so schnell reinkommt. Dafür lernt er vielleicht viel auf der anderen Seite. Muss man sich halt einfach überlegen. Das sind, glaube ich, unterschiedliche Zielsetzungen. So, dann kommen wir zur nächsten Frage. Jetzt hast du so einen Code vor dir? Und du hast ihn irgendwann verstanden. Und dann denkst du dir, Da gibt es doch eine einfache Lösung. Und du packst ein To-Do-Kommend drin.

Du packst da drüber dran, To-Do needs to be refactored to make it more simple. Bist du ein Fan von To-Do-Comments oder sagst du, alle To-Do-Comments sollen aus dem Code raus und sollen ein ordentliches Ticketsystem eingeführt werden?

Ich bin ja ein riesiger Fan von Programmierern, die immer sagen, es geht einfacher und ich kann das besser und schneller und am besten an einem Wochenende kann ich eine bessere, schnellere und kürzere Lösung schreiben. Am liebsten sind mir die CEOs, die das dann meinen. Aber das ist wieder ein anderes Thema. Auf jeden Fall.

um auf deine Frage zurückzukommen. Ich finde es schrecklich, Code zu haben, wo so viele Do-Do's drinnen stehen und die vergisst man da meistens. Das Schlimmste sind immer diese... Catches von Exceptions, wo dann Do-Do drinnen steht, was man mit der Exception, wenn man sie gecatcht hat, dann macht, sieht man ja auch sehr gerne. finde ich schrecklich. Entweder man schreibt sinnvollen Code

Oder man setzt irgendwas in einen Kommentar, aber es ist meiner Meinung nach, Code ist keine To-Do-Liste. Das kann mal, wenn man was Work in Progress hat und dann einer Klasse schreibt, dass man für sich selber das irgendwie reinschreibt. Aber meiner Meinung nach, wenn man dann wirklich was committet. was auch fertig ist zum Merchen. Das muss meiner Meinung nach du-frei sein.

Du würdest dann wirklich ein Ticket erstellen lassen? Oder ein Ticket selbst erstellen? Ist etwas fertig, wenn ich jetzt dieses Post-it oder meinen Task auf Done setzen will? dann muss das Ding ja funktionieren. Und dann muss das eigentlich ohne Do-Dos funktionieren. Was ist denn mit der ganz alten Pfadfinder-Regel? Ich baue jetzt ein neues Feature, lese mir ein bisschen Code von anderen Klassen durch und sehe, da ist ein Bug, da kann etwas...

optimiert werden. Da ist halt irgendwas, was geändert wird oder werden sollte. Was aber jetzt gerade nicht in den Scope von meinem Feature fällt. Da packe ich dann ein To-Do-Comment dran und committe das. Einfach so nach dem Motto, hey, dass man das schneller findet, weil es gibt ja auch IDE-Support für To-Dos und ähnliches. Oder sagst du, nee, Andi, wenn du sowas siehst, mach bitte lieber ein Ticket.

Ich glaube, man kann schon Do-Do-Comments in dem Sinne reinschreiben, dass man reinschreibt, okay, Performance ist nicht ideal oder da könnte man das und das noch verbessern. Aber dieses klassische Do-Do, da fehlt jetzt was, da muss man noch was machen, mit dem bin ich eigentlich nicht sehr einverstanden.

Klar ist Code nie fertig, aber für mich ist ja immer irgendwas, was noch nötig ist, damit der Code funktioniert. Und wenn ich Exception noch nicht gecatcht habe oder catche, aber nichts damit mache, dann ist das für mich kein sinnvoller Code. der fertig ist zum Merch. Und solche To-Dos sind meiner Meinung nach sinnlos. Wenn man da jetzt irgendwas

reinschreibt, okay, Do-Do-Performance ist nicht ideal, könnte man in Zukunft einmal ändern. Das ist dann was anderes. Aber das würde ich ja nicht so als klassisches Do-Do bezeichnen, sondern einfach halt in die Funktion, in die Kommentare von der Funktion reinschreiben.

Weil wenn sich jemand damit beschäftigt, sieht er das auch und kann sich dann dementsprechend drauf stürzen, wenn er das unbedingt ändern will. Weiß ich nicht. Ich meine, To-Do-Kommentare sagen ja nicht immer, ein Feature ist incomplete, sondern stell dir mal vor, du machst jetzt gerade eine Migration von Design-Pattern A auf Design-Pattern B. du entdeckst eine Stelle im Code, die nach dem alten Prinzip arbeitet, die aber super funktioniert, dann ist das

Für mich ein To-Do-Kommentar, was jetzt nicht wirklich super dringend ist. Ja, Technical Debt hin oder her ist ja auch so ein sehr subjektives Thema. Aber Coach funktioniert, ist super stabil seit 25 Jahren, arbeitet nur nicht nach der neuen Methode. Kommt ein Kommentar ran und ab geht's. Okay, wir wissen ja eh, dass du auf Quick und Dirty bist und am liebsten den.

den nicht funktionierenden Code committest. Gehen wir mal auf diesen Commit und auf diesen Merge. Bevor wir da weiterspringen. Ich habe noch eine Frage. Wie stehst du denn zu Storytelling im Code? Was ist für dich Storytelling? Ist das jedes Kommentar, was über 800 Zeichen hat? Ich habe die 800 Zeichen jetzt gerade. Wie viele Tweets sind das? Da habe ich so ungefähr das Textvolumen im Kopf. Drei Tweets ungefähr.

Was ich meine, ist einfach mal so eine kleine Geschichte zu erzählen. So ein bisschen Entwicklerhumor. Ja, du scrollst durch eine Klasse und irgendwie kommt ein recht komplexes Konstrukt. Dann steht da im Kommentar, willkommen. Wenn du dir gerade darüber nachdenkst, diesen Code zu ändern, empfehle ich dir, dies sein zu lassen. Dieser Code ist stabil. Er funktioniert. Du verstehst ihn zwar nicht, aber er ist stabil und er funktioniert.

Und darunter Zeit darauf verwendet, diesen Code versucht zu refactoren, 25 Stunden. Darunter dann, wenn du auch einer davon bist, der das versucht hat, bitte erhöhe den Count. Ja, das ist so eine Art Storytelling, vielleicht so ein bisschen Entwicklerhumor. Einfach mal so ein bisschen, ich mache das jetzt so, es ist Sonntagabend, 9 Uhr, ich will ins Bett.

Ja, das muss jetzt hier, das reicht jetzt, das Scuffer-Tape. Sagst du, geht gar nicht, wir müssen uns professionell im Code verhalten oder sagst du, ach ganz im Ernst, der nächste Entwickler kann auch ein bisschen lachen. Ich bin ja immer offen für Humor, gar keine Frage.

Aber man muss natürlich auch guten Humor haben. Das ist gar nicht so leicht, jemanden zum Lachen zu bringen. Und der andere kann natürlich auch einfach meinen, oder die andere, um Gottes Willen, was ist denn das für ein arrogantes Arschloch da, was wieder glaubt, alles perfekt machen zu können. Also da muss man aufpassen, aber ein bisschen Humor ist immer gut. Da kann ich übrigens auch empfehlen, einen...

Vortrag von einem Ex-Kollegen von uns bei Trivago, schon lange her, Jan von Thor, verlinken wir gerne, hat mal so einen Vortrag über den Trivago-Code gemacht. Da kommen auch sehr, sehr nette Geschichten. Kommentare vor, also weil sich mal interessiert. von einer Hotelpreissuchmaschine mit hunderten Entwicklern.

Denjenigen kann ich auf jeden Fall diesen Vortrag empfehlen, dass man mal auch sieht, wie sowas abgeht und was es da für böse Kommentare gibt. Der Vortrag ist in der Tat ganz gut, weil Jan da beschreibt, wie er

den sogenannten Snapshot Refact. Der Snapshot, müsst ihr wissen, war eine riesige Gottklasse in unserem PHP-Framework damals. Der war verantwortlich dafür, welche Parameter mit welchen Werten befüllt werden, ab wann es einen Default-Wert gibt, ab wann der User-Wert genommen wird etc. Und das Ding wurde einfach überall rumgereicht. Es war halt einfach eine Gottklasse, war super schwer zu verstehen, super schwer zu debuggen. Er hat sich da ein paar Monate reingestürzt.

Und sehr spannender Talk. Auf jeden Fall. Gibt es auch, wer ein bisschen auf Entwicklerhumor steht und ich bin ein riesen Fan von Storytelling-Code. Also in meinem Code findest du überall Storys, ob ich gerade ein Bier trinke oder nicht, ob ich angepisst bin. Also ich packe da Storys rein wie noch und nöcher, weil ich denke, das haben wir uns alle verdient, ein bisschen Humor, ein bisschen Kontext. Schreibst du diesen Humor auf Englisch? Ja. Was haltest du von deutschen Kommentaren?

Gar nichts. Ich habe mal in dem Code gearbeitet und zwar war ich damals... Fällt dir eigentlich auf, dass wenn Deutsche mir inklusive Code aussprechen, dass es immer wie Code klingt mit K? Vielleicht ist es auch genauso scheiße, ich weiß es nicht. Auf jeden Fall habe ich damals eine Software für Vodafone geschrieben und die haben wir nicht begonnen, die Software, die habe ich übernommen. Dann habe ich die Software aufgemacht und waren überall russische Kommentare.

Und ich musste halt immer diese Kommentare durch so einen Translator senden. Seitdem kannst du Russisch? Nee, ich kann's nicht. Also seitdem sag ich Englisch und fertig. Weil auch ...

Obwohl eine Sache hat, einen Vorteil hat deutsche Kommentare. Man merkt recht schnell, in welchem Charset die Datei gespeichert wurde und wann man UTF-8-Probleme hat. Das ist mir auch öfters schon passiert. Was für mich immer extrem schwierig ist, weniger jetzt in den Kommentaren, aber in variablen Namen, wenn du in so einem Kontext arbeitest, der rein deutsch ist, Und ihr habt zum Beispiel eine Codebase. die im Lebensmittelhandel unterwegs ist. Und die haben einfach alles deutsche Begriffe.

Erstens habe ich keine Ahnung, ob es da überhaupt englische Begriffe gibt, weil das sind teilweise Eigennamen, eigene Erfindungen und irgendwelche super Spezialausdrücke. die teilweise extrem schwierig sind, in dem speziellen Business-Feld auf Englisch überhaupt zu finden. Also da fällt es mir dann auch immer schwer, wirklich die englischen Begriffe zu suchen.

irgendwie auf Englisch zu schreiben. Das Problem am Ende ist, dass andere Leute, inklusive mir selber, in englischem Code nicht mehr verstehen, weil man die englischen Begriffe einfach nie verwendet, sondern nur die speziellen deutschen Begriffe, irgendwelche auch Businessbegriffe, steuerlichen Begriffe. Das ist natürlich extrem schwierig. Hast du da eine Lösung? Nee, habe ich nicht. Also...

Das kommt natürlich aus dem Umfeld drauf an. Vielleicht hilft es auch einfach, das deutsche Fachwort dahin zu schreiben. Ich meine auch Leute, die in den Deutschen nicht mächtig sind, die dann in der Firma und an dem Code arbeiten, kommen in das Domain-Vokabular ja recht schnell rein. Wobei das dann oft so eine Mischung wird. Dann heißt es halt irgendwie ... Get Steuerklasse 18 oder so irgendwas.

Ich habe noch nie Steuersoftware geschrieben, aber so stelle ich mir das vor und ich glaube, so würde ich es dann auch machen. Ich habe jetzt keine gute Meinung, wie man das lösen kann. Falls jemand da draußen eine gute Lösung hat, wie man in solchen Bereichen am besten mit diesen Fremdwörtern umgehen kann. Nur hey damit bitte. Aber kommen wir zurück auf meine eigentliche Frage, Commit Messages. Wenn du jetzt deinen Code Merchant willst, der Follow-to-do-Comments ist und

unvollständig und dirty-hacked. Was schreibst du denn in die Git-Comments rein? Fixed Bug. Wenigstens eine Bug-Nummer oder nur Fixed Bug? Fix Bug. Wir hatten einen Bug, der ist nicht mehr da. Somit muss keiner mehr wissen, was das für ein Bug war. Ist so ähnlich wie die Variable x plus y oder so, oder? Ich habe dir gerade gesagt, ich bin ein Fan von Zählervariablen, IJK. Das kann man natürlich auch fortsetzen auf Git-Comments.

Nein, natürlich nicht. Also ich bin ein Fan von guten Comment Messages. Ich gebe zu, ich mache das nicht immer, weil eine sehr gut beschriebene Git-Comet Message braucht einfach Zeit und Energie. Ich versuche schon zu beschreiben, was Ich gebe aber auch zu, dass ich... sehr selten und sehr wahrscheinlich viel zu selten, ich sollte es eigentlich öfter machen, nicht in die Git-Historie gucke. Also ich schaue mir oft nicht vorhandene Git-Comet-Messages an.

lese die durch, warum etwas gemacht wurde. Weil ich vielleicht einfach zu oft enttäuscht wurde, dass super viele Leute genauso sind wie ich und einfach zu faul sind gute Git-Comet-Messages. Also ich hatte mal vor Jahren irgendwie den Vortrag gehört über Gitcomments. Und der war für mich irgendwie Augenöffnen.

Und zwar das Eigentliche, was mir so geholfen hat, ist, dass man einfach aufhören muss, Git-Commit-Messages als Einzeiler zu verstehen. Und das ist, wenn man klassisch auf einem Command-Line arbeitet, hat man irgendwie die Angewohnheit, alles in einer Zeile zu schreiben. Und dann werden die Git-Commit-Messages auch dementsprechend kurz. Wenn man sich einfach das mal vor Augen führt, das via E-Mail zu gestalten und sagt, das hat Subject.

und ein Body, wo ich mehr reinschreiben kann und vielleicht nur irgendwo ein paar Referenzen am Ende in irgendeiner Art von Footer, zum Beispiel die Backnummer im Footer, dann schreibt man schon automatisch mehr, weil ja E-Mail schreibe ich auch selten an Einzeiler.

Und ich glaube, es gibt viele Artikel und... Und Blog-Einträge, die irgendwie erklären, was man da nicht alles reinpacken kann. Wenn man sich so ein paar Grundregeln haltet, man hat da Überschrift, die alles zusammenfasst, dann in den nächsten Zeilen hat man einfach eine Auflistung. Was hat man denn wirklich geändert oder was ändert diese Commit-Messive? Und wie gesagt, vielleicht nur ein Fix. Hashtag 72 oder 270 als Ticket.

Ist sofort geschrieben und man hat es dann schon in der Git-Commit-Message drinnen. Wenn man dann einen Merch oder einen PR erstellt, wird das automatisch übernommen. Man hat da schon die Infos drinnen und braucht dann gar nicht mehr viel, dementsprechend dazuschreiben für einen Pull-Request.

Also ich finde, das ist eine so simple Sache, man muss sich einfach nur überlegen oder vielleicht selber zwingen, eine Zeile ist zu wenig. Da bedarf natürlich auch ein bisschen Vorarbeit. Also das bedeutet natürlich auch, dass deine Git-Commits selbst

recht isoliert sind. Du solltest jetzt nicht 35 Features in einen Commit packen. sondern commit early, commit often. Auch nur dann kannst du nämlich auch ordentlich beschreiben, welchen Bug du gefixst hast, warum ihn du gefixst hast und so weiter und so fort. Wenn du jetzt natürlich ein ganzes... Formular mit E-Mail-Logik und so weiter und so fort schreibst, dann ist das gegebenenfalls ein bisschen zu viel, weil sonst schreibst du ja auch ein halbes Buch in deine Gitcommitment.

Aber du hast die Möglichkeit, mehr zu schreiben. Also ich glaube, man darf da keine Angst haben, ein bisschen mehr zu schreiben. Man kann ja auch die Commit-Messages dann squashen und nochmal zusammenfassen. Das ist ja auch nochmal was, was man machen kann. Du schüttelst schon den Kopf, Andi. Ich sehe schon, du squashst nie. Ich squash überhaupt nicht, ne. Aber ich hab schon mal gesquashed, weil ich das Feature mal testen wollte. Aber ich hab ja gerade gesagt,

Ich schaue sehr, sehr selten in die Git-Historie zurück. Ich sollte es viel öfter machen und ich nutze auch sowas wie Git-Bisect nicht, um Bugs zu finden und Comets zu trennen und allem drum und dran. Du machst wahrscheinlich dann auch Merch Committee. Ich mache Merch-Commits und

Egal in welchem Team ich bin, ich folge einfach deren Regeln. Wenn die Fans von Merch-Commits sind, okay, dann machen wir das. Wenn die Merch-Commits hassen und ihre Git-Historie total clean haben wollen, dann machen wir das. Ich bin da recht leidenschaftlos. Wer jetzt übrigens keine Ahnung hat, von was wir reden. die ganzen Special Git Commands. Wir können da auch einen Vortrag verlinken von einer Trivago-Kollegin, der Melanie, von einem Vortrag, die...

geht da sehr in die Tiefe, was man denn alles mit Git Cooles machen kann, weil es gibt wirklich viele coole Sachen, die man mit Git machen kann. Auch eben zum Beispiel schöne Fast-Forward-Merches. Oder Rebase ist auch so ein Klassiker. Das sollte eigentlich wirklich jeder Developer wissen. Sollte man sich also wirklich mal im Detail anschauen, wie das funktioniert, auch wenn der Andi das nicht macht.

Vielleicht für den Kontext für die Hörer, die auch nicht wissen, was Merge Commits sind. Wenn ihr zum Beispiel einen Pull-Request auf GitHub oder ein Bitbucket macht, dann ist das ja so eine Art Änderungsvorschlag an existierendem Code. Den reviewt dann irgendjemand und irgendwann wird er in die Hauptentwicklungslinie, dem Main Branch, dem Master Branch, damals in Subversioned Trunk, gemerdet.

Für die jüngeren Zuhörer und Hörerinnen, was ist SVN? Subversion, der Nachfolger von CVS, einem Versionskontrollsystem, einem zentralen Versionskontrollsystem. Und das war auch der Hauptpunkt, warum Git... eigentlich das ganze System fast abgelöst hat in der Softwareentwicklungswelt. Weil es dezentral ist. Aber ich glaube, mehr braucht man nicht wissen. Es ist nichts, was man unbedingt mal verwendet haben muss. Auch wenn es viele Firmen gibt, die das noch verwenden.

Leider. Zurück zu Merge-Commits. Angenommen, ihr habt einen Pull-Request mit 5 Commits. Und der wird gemerged. Dann wird die Hauptentwicklungslinie um 6 Commits erweitert. Weil ihr habt nämlich Euro 5 Commits. Und einen sogenannten Merge Commit, der den einen Branch in den anderen Branch überführt. Und es gibt Teams.

die sagen, ich will aber, ich will aber, ich will aber, ich will aber eine cleane, saubere Git-Historie und ich möchte keine Merge-Commits da haben, weil diese Merge-Commits selbst haben jetzt nicht so super viel Value eigentlich, weil der eigentliche Value ist ja dein Change, der in den fünf vorherigen Commits schon gemacht hat.

Dann gibt es Teams, die sagen, ach, mir Wumpe gehört dazu. Manche Leute sagen, das stört so ein bisschen den Leseflow von einer Git-Historie. Da bin ich recht leidenschaftlos. Mich würde mal eure Meinung dazu interessieren, wie ihr dazu steht, weil... Ich habe halt auch schon gemerkt, das führt dann wieder zu religiösen Diskussionen im Team, sowas wie Tabs versus Whitespaces.

BIM oder EMAX und ähnliches und ich denke, wir sollten unsere Energie Was soll man denn da für Diskussionen führen? Es ist ganz klar, dass das Whitespaces sind. Da braucht man gar nicht diskutieren. Kommen wir zurück zu meinem initialen Aufruf. Ich suche einen neuen Podcast-Host. mit dem ich zukünftige Folgen aufnehme.

Wenn ihr interessiert seid, einfach mal melden. Aber kommen wir mal zu weiteren Git-Commits. Also Git-Commit-Messages, super. Wir sollten alle, meines Erachtens nach, mehr Zeit drauf verbringen. Gute Git-Commit-Messages. zu schreiben. Kennst du die Art und Weise von Git Comment Messages, wo du mit einem Prefix indiziert was das für ein

ein Bugfix, ein Feature, ein Dependency-Upgrade, ein Breaking-Change oder ähnliches. Kennst du das? Ich muss zugeben, ich habe das jetzt zum ersten Mal gelesen, dass das eigentlich eine ganz gute Herangehensweise ist. Und ist auch nicht schlecht. wenn man so ein bisschen Kontext gibt. Aber findest du, es ist sehr wichtig? Ob es so super wichtig ist, weiß ich nicht. Hat es Value meines Erachtens nach schon?

weil du kannst nämlich Bugpixes ganz klar von neuen Features unterscheiden. Du kannst Dokumentations-Pull-Requests von Dependency-Upgrades besser unterscheiden. Und da kannst du, glaube ich, auch sehr schnell herausfinden, welcher Commit jetzt hier eigentlich relevant ist.

der wirklich eine Funktionsänderung hat oder welche nicht und welchen ich reverte. Also ich finde das schon gut. Habe es mal auch irgendwie versucht zu folgen, habe es aber irgendwie nicht durchgezogen in meinen privaten Projekten. Auf der Arbeit machen sowas. Da gibt es aber dann auch Tooling, was mich komplett dabei supportet, Git, Pre-Commit-Hooks, Git-Commit-Message-Template.

Und so weiter und so fort. Also die geben mir schon ein vorgefertigtes Framework, wo ich dann einfach nur Daten eingebe. Aber der Riesenvorteil ist natürlich, umso standardisierter deine Git-Comment-Messages sind, umso mehr Automatisierung kannst du.

Nehmen wir mal als Beispiel. Es gibt ein wunderschönes Projekt, das nennt sich Release Please von Google. Und Release Please ist ein Gitterbot, der schaut sich deine aktuellen Comets an. Und wenn du deine Comets... strukturiert machst, also Feature, Fix, Documentation, Dependency Upgrade und so weiter und so fort, dann maintained dieser Release Please, der Release Please Bot, nämlich ein Change Log für der sagt, welche Breaking Changes es gibt, welche neuen Features, welche Bugfixes, aber auch

ob du deine Versionsnummer hochdrehen musst, weil du einen Breaking Change zum Beispiel drin hattest oder ob das nur eine Bugstückversion ist oder ein Major oder Minor Upgrade, sofern du natürlich Semantic Versioning Das bedeutet also, umso mehr Standard in deinen Messages drin ist, umso mehr Arbeit kannst du dir natürlich vom Computer auch abnehmen lassen, weil sich dann nämlich menschlich lesbarer Textcomputer technisch parsen lässt. Was ist ein Semantic Questioning?

Semantic Versioning ist ein Versionsschema, wo deine Software in der Regel drei oder mehr kleine Versionsnummern hat. Eine zum Beispiel ist 1.0.0. Da ist die Major-Version die 1, nämlich Version 1. Wenn du jetzt aber ein neues Feature addest, dann würdest du die nächste Version als 1.1.0 releasen. Und wenn du nochmal ein Feature-Release hast, dann würdest du die nächste Version als 1.2.0 releasen. Also bei neuen Features wird die Miner-Version, die mittlere Versionsstelle erhöht.

Wenn du jetzt nur einen Bugfix hast, dann wird die letzte Versionsstelle erhöht. Und wenn du jetzt einen Breaking Change hast, dann wird die erste Versionsstelle, die Major-Versionsstelle erhöht. Wenn du dieser Struktur folgst, können User bereits sehen, ob die einfach upgraden können, ob das neue Features enthält oder wirklich Breaking Changes, wo dann gegebenenfalls auch etwas anderes angepasst wird.

Die erste Nummer ist Major, zweite Nummer ist Minor und die dritte Nummer ist Patch Level. Habe ich das richtig verstanden? Patch oder Bugfix, ja genau. Wenn sich was wirklich ändert, was Breaking sein könnte. dann sehe ich das an der ersten Zahl von so einem dreistelligen Semantic Versioning. Das ist korrekt.

Es gibt auch noch ein paar Modifikationen dieser ganzen Thematik, dass du zum Beispiel nach den drei Versionsnummern noch ein Minus und dann irgendwie ein Teil deines Git-Shars hast oder ähnliches, ja, ein paar Metainformationen oder vielleicht Release-Dates, sowas wie Alpha und Beta wird da auch nochmal drangehangen. Da gibt es dann immer so kleinere Erweiterungen. Verlinken wir natürlich auch in den Shownotes. Ist super einfaches Konzept, aber ist genial, weil es halt extrem weiterhilft.

Und das Gute ist ja, je nach verwendeter Sprache kannst du auch deinen Source-Code analysieren lassen zu deinem letzten Release. Und weil es gibt einfach in deiner Programmierung, je nach Verwendung der Sprache, ganz klare Regeln, wann etwas ein Breaking Changes ist und wann nicht. Nehmen wir mal zum Beispiel Golang. Golang hat Funktionsparameter, Golang hat aber keine Default Values für Funktionsparameter.

Das bedeutet jetzt also, du hast eine Public Facing API und fügst einen neuen Funktionsparameter hinzu. Das ist ein Breaking Chain. weil deine API nicht mehr kompatibel ist, weil Golang ja keine Default-Parameter hat. Wohingegen zum Beispiel eine Sprache wie PHP Default-Parameter hat, Wenn du jetzt ein neues Funktionsargument dran packst und assignst dem einen Default-Parameter, dann können die User mit dieser API einfach upgraden, ohne dass die API bringt.

Und das kannst du natürlich auch untersuchen lassen. Jetzt ein bisschen Eigenwerbung. Das ist das Thema, worüber ich meine Bachelorarbeit geschrieben habe. Software Repository Mining, falls du mal googeln möchtest. Superspannend. Wie lange ist das eigentlich her? März 2013 habe ich meine Arbeit verteidigt. Das ist jetzt fast zehn Jahre her, der Code ist nicht mal mehr lauffähig.

Es war auf jeden Fall sehr viel Python in Version 2 involviert, das ist richtig. Naja gut, das wäre jetzt noch kein Argument, weil ich glaube irgendwie der Großteil aller beiden Programme laufen immer noch auf zwei Punkte. 8 ist es, glaube ich. Also das war jetzt gar kein Sonderfall. Insofern funktioniert es wahrscheinlich noch. Ich sage mal so, ich habe damals auf jeden Fall deutlich weniger Kommentare genutzt und meine Git-Comment-Messages sahen noch schrecklicher aus.

Eins können wir mit Sicherheit feststellen, ich werde den Code auf jeden Fall nicht mehr verstehen oder werde sehr lange brauchen, mich dann neu einzuarbeiten. Ist der irgendwo öffentlich, zugänglich?

In archivierten GitHub-Repositores in meinem Profil, ja. Ah, dann werden wir den einfach auch verlinken, dass die Leute mal sehen können, wie man Git-Commit-Messages nicht schreibt. An eurer Stelle würde ich das jetzt nicht tun. Ich würde lieber eine Folge Game of Thrones oder ähnliches auf Netflix gucken. Aber ich überlasse euch wie ihre Zeit verpampert.

Wenn ihr ein paar Regeln und ein bisschen Struktur in euren Git-Commit-Messages einbaut, dann könnt ihr durch Automatisierung eine ganze Menge Arbeit ersparen. das Beste, die Qualität eurer Releases natürlich erhöhen. Und wenn ihr sagt von Releases, heißt das natürlich nicht nur im Open-Source-Bereich, sondern auch wenn ihr eine größere interne Entwicklungsabteilung habt und ihr published da APIs. Release Notes und Change Log Notes sind Gold wert, wenn ihr Cross-Team-technisch arbeitet.

Vor allem, wenn man das natürlich in irgendeiner Form automatisieren kann, weil dann ist das auch kaum mehr Arbeit und geht einfach automatisch. immer mit und die ganzen Dokumentationen werden auch dementsprechend abgedatet. Also das ist wirklich Gold wert, weil da braucht man dann gar nicht mehr dran denken und alles geht automatisch.

Aber wenn du jetzt schon sagst, deine Bachelorarbeit ist kein gutes Beispiel und man soll die Zeit nicht verplempern, wenn jetzt unsere Zuhörer und Zuhörerinnen die Zeit nicht verplempern wollen und gute Beispiele anschauen wollen, hast du irgendwelche Tipps von guten Beispielen?

Meines Erachtens nach das Projekt mit den besten Comment Messages ist der Linux-Kernel. Eine sehr komplexe Software mit noch mehr komplizierten Hardware-Treibern und Co. Die Comment-Messages, die da geschrieben werden, enthalten wirklich sehr viele Details in einer sehr kurzen Form. Also da muss man den Entwicklern mal wirklich ein Lob aussprechen. Die Menge an Informationen, die die in den Comment Messages übertragen ist, ist schon sehr beachtlich.

Liegt der Linux-Kernel eigentlich immer noch bei Linus Torvalds, seinem privaten Account? Das weiß ich gerade nicht. Ich weiß aber, dass der Linux-Kernel auf GitHub nur ein Mirror ist. Also ich habe es mal gerade gecheckt. Es ist zumindest in seinem Account.

Dino Storwald war ja auch der Entwickler, der erste Entwickler von Git. Also da muss er doch natürlich auch gute Git-Messages schreiben, Commit-Messages, hoffe ich doch mal. Wir verlinken in den Show Notes auch ein paar Beispiel-Commit-Messages vom Linux-Körner. Einfach mal zu sehen, wie sowas... aussehen kann. Wolfgang, jetzt machst du dich die ganze Zeit über mich lustig, über meine Git-Commit-Messages. Wie verhält sich das denn bei dir? Bist du pro Merge-Commit?

Contra, gibst du dir wirklich viel Zeit und Mühe für deine Git-Commit-Message oder sagst du, ach fuck it, ich bin nicht der Einzige, der hier für Jahre entwickeln wird? Nein, ich probiere natürlich sowieso alles in dem Team zu entwickeln und mir hat einmal ein Kollege vor vielen, vielen Jahren, danke Tim.

gezeigt, wie hässlich denn so ein Merch-Commit aussieht, wenn man da so die Branches visualisiert darstellt. Und nachdem ich das verstanden habe, was das einfach künstlerisch für eine Grausamkeit ist, so ein Merch-Commit, Und er mir erklärt hat, wie einfach das ist mit Fast Forward und wie man das sauber macht mit Rebase. Ab diesem Zeitpunkt gibt es bei mir eigentlich nur mehr Pull, Rebase und alles wird gerepaced und dementsprechend sauber wieder.

zusammengemerged, wenn es um Branches geht. Ich schlage gerade die Hände über dem Kopf zusammen. Wolfgang, wir haben noch die Tage festgestellt, du bist ein Kunstbanaus. Also, kurz zum Kontext. Und zwar habe ich mich in den Newsletter von Finn Kliemann eingetragen. Wer ihn nicht kennt, einfach mal googeln. Krasser Typ.

Braucht man nicht kennen. Finn Kliemann malt auch und verkauft seine Kunst. Und er hat ja seinen neuen Kunstkatalog rausgebracht für die Gemälde, die man da bald kaufen kann. Habe ich dem Wolfgang geschickt. Ich bin ja wirklich enttäuscht, dass du auf so einen Influencer reinfallst. Und jetzt erzählst du mir noch bald, dass du NFTs kaufst von ihm. Nee, davon verstehe ich echt nichts. Also du bist nur seine wahre Kunst. Bin ich Fan, weiß ich nicht. Ich finde es spannend, was er macht.

Auf jeden Fall. Du erzählst mir jetzt irgendwas von irgendwelchen Branch, von irgendwelcher Branch Kunst und, sorry, mit Kunst nehme ich dich einfach nicht mehr ernst. Ja, das ist halt Engineering Kunst. Das verstehst du nicht. Aber kommen wir doch mal zu dieser Branch-Visualisierung. Das ist ja wirklich eine tolle Sache. Ich meine, Git ist ja darauf gebaut, dass du kontinuierlich branchst und mercht. Welchen Zweck?

ziehst du aus der Branch Visualisierung, außer wenn du dein Git Repository mit der New Yorker U-Bahn vergleichen möchtest. Welchen Wert und welchen Value ziehst du darauf? Und wir sprechen jetzt nicht von irgendwelchen Git-Merge-Modellen wie Git-Flow oder sowas. Wir nehmen jetzt den klassischen GitHub-Flow. Du hast einen Main-Branch, man brancht raus für Feature oder Bug-Fixes, macht Pull-Requests und mercht das wieder zurück. Welchen Value ziehst du aus dieser Branch Visualisierung?

Ich sehe das Ganze ja als Kunst an. Insofern darfst du mich da jetzt weniger fragen. Aber so richtige, gute Entwickler, ich zähle mir da ja nicht wirklich dazu, haben mir immer erklärt, bei sehr großen Projekten mit extrem vielen Branches,

Hilft schon die Visualisierung, um einfach zu sehen, woher die Dinge stammen, wie was zusammengeflossen ist? Hat das schon viel Mehrwert für gute Entwickler, Andi? Ich sehe den Mehrwert, wenn man irgendwelche Git-Workflows wie Git-Flow nimmt oder ähnliches, wo man Release-Branches rauszieht und auf diesen Release-Branches weiterentwickelt und so weiter. Da verstehe ich das. Und bei GitHub...

Würde ich auch noch den Wert verstehen, weil GitHub selbst die sogar Forks mit visualisiert und da sieht man, wie weit Forks von deinen eigenen Projekten weiterentwickelt werden. Aber innerhalb deines eigenen Git-Projekts Weiß ich nicht. Also ich habe da jetzt noch keinen Wert draus gesehen. Aber ich sage ja auch, dass ich viel zu selten die Githistorie durchforste.

Also das war jetzt eine klare Anforderung an alle guten Entwicklerinnen da draußen. Bitte sendet uns gute Gründe, warum man so eine Visualisierung brauchen kann, damit der Andi das dann auch versteht und ich vielleicht auch. Und das war das Schlusswort. Wir haben uns eine ganze Zeit lang über sehr viel subjektive Themen unterhalten. Kommentare, selbsterklärender Code, Git-Comment-Messages. Natürlich ist das Thema endlos. Wir haben super viele Dinge nicht erwähnt.

Wir sind nicht auf Git Pre-Commit Hooks eingegangen. Wir sind nicht auf Git-Commit Message Templates eingegangen. Wir sind nicht auf was gutes oder schlechtes Naming jetzt ist und ob man jetzt C oder V als Variablen-Namen nehmen kann und ob es da ein Für und Wider gibt. Das Tolle an der Programmierung ist, es ist ein sehr subjektiver Sport und auch eine sehr subjektive Arbeit.

Man hat ein Problem und es gibt 25 Lösungen und ich glaube, so lassen wir das mal stehen. Ich finde aber schön, Wolfgang, dass wir langsam mal mehr und mehr und mehr Themen finden, wo wir einfach mal aneinander rattern. Einfach mal einen gesunden Streit, finde ich klasse. Und wenn es auch nur die Kunst von, wie heißt der gute Karl? Kim, Kim, Anna, es ist von Nordkorea. Wie heißt deiner? Finn Kliemann. Finn Kliemann jetzt mit Kim Jong-un zu vergleichen, ist ein bisschen hart. Auf jeden Fall.

Wenn man vielleicht noch eine Takeaway-Message definieren sollte oder möchte, man sollte immer eine Takeaway-Message mitnehmen von irgendeiner Episode. dann wäre meine Take-Away-Message oder mein Wunsch, dass man sich vielleicht bei allen Comments, egal ob es jetzt in dem Git, commit ist oder in dem Code, dass man einfach versucht, vielleicht mal überall

mehr zu schreiben oder vielleicht einfach mal 20 Sekunden mehr über ein Comment oder eine Git-Commit-Message nachdenkt. Und ich glaube, das ist wirklich nicht viel Zeit, die man da investiert. uns vielleicht einfach mal ausprobiert, da ein bisschen mehr Zeit zu investieren. Und dann kann man ja auch für sich feststellen, bringt sich das Ganze irgendwas, zieht man irgendwas dabei raus oder ist es sowieso sinnlos?

Einfach mal auszuprobieren, ein bisschen mehr Zeit zu investieren, das schafft, glaube ich, jeder von uns und ich glaube langfristig. kann es nur zu einem besseren Outcome führen eigentlich. Und wenn ihr neugierig seid, wie unser Core-Source-Code aussieht, mit vielen Kommentaren, mit wenig Kommentaren, Wolfgang und ich werden in den nächsten paar Tagen mal ein paar Bilder von unserem Source-Code twittern, einfach auf.

at Engineering Kiosk, ENG Kiosk folgen. Ist das dann auch schon Kunst, die wir verkaufen können? Können wir dann NFTs irgendwie drauf bauen? Deswegen bin ich da raus. Okay, also wir schauen uns das noch an, ob wir an dieses Code als NFT, also Code mit C geschrieben, ob wir das mit NFTs vielleicht irgendwie dann verkaufen können. Ansonsten verspreche ich euch, dass wir in Zukunft

technische Themen, die mehr Hardcore, Hardcoriger, ich weiß nicht, wie man das jetzt nennt, machen. Moment, wenn das jetzt keine Hardcore-technische Session war heute, ist wohl ideal. Also wir sehen übrigens...

Zur Information, die Episode wird dann etwas kurzer. Wir nehmen jetzt schon eine Stunde 40 auf. Ihr könnt dann ausrechnen, was wir alles rausgeschnitten haben, was da sonst noch alles drin war, was da Andi von sich gegeben hat. Auf jeden Fall finde ich das schon ein sehr technisches Thema.

Oder ist da jemand anderer Meinung? Lasst uns einfach mal wissen und lasst uns auch mal bitte wissen, wie ihr zu Kommentaren steht. Ich bin gespannt, was für Meldungen kommen. Ansonsten würden wir sagen, halten wir es kurz. Vielen Dank fürs Zuhören. Bis bald. Und nicht vergessen, auch bei E-Mail stetisch at engineeringkiosk.