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

Kommentare im Quellcode und Git Commit Messages - Liest die überhaupt wer?

Ein Streit, der so alt ist wie die Software Entwicklung selbst: Code ist Selbsterklärend und braucht keine Kommentare. Oder doch? Und die Git Historie ist auch eigentlich sinnlos. Warum sollte da jemand zurück gehen und sich die Commit Messages durchlesen?

Diese Fragen und Themen wie Semantic Versioning, Idiomatische Programmier-Patterns, Merge Commits, Story-Tellung und was Fynn Kliemanns Kunst mit der Git Branch-Visualisierung zu tun hat, klären Wolfgang und Andy in dieser Episode vom Engineering Kiosk.

Bonus: Warum Andy einen neuen Podcast-Partner sucht und Wolfgang lieber seinen Code angreift, anstatt Ihn zu entwickeln.

Feedback an stehtisch@engineeringkiosk.dev oder via Twitter an https://twitter.com/EngKiosk

Sprungmarken

(00:00:00) Intro

(00:01:21) Home Office: Job und Privat stark trennen?

(00:02:31) Warum macht man Sport und wie steht Wolfgang zur bayerischen Ess- und Feierkultur

(00:03:43) Karriere oder Software-Engineering Podcast und Hardcore-Tech-Thema

(00:04:38) Wie viel Kommentare hat die letzte Datei, die du in der IDE offen hattest?

(00:01:16) Wie stehst du allgemein zu Kommentaren?

(00:01:05) Was sind sinnvolle Kommentare und ist Code wirklich selbsterklärend?

(00:13:55) Komplexen code refactoren oder lieber gut kommentieren?

(00:17:40) Kommentare für kopierten Stack Overflow Code

(00:19:48) Kommentare für die Business-Domäne

(00:20:11) Algorithmen und Variablen mit einem Buchstaben

(00:21:46) Können gute Variablen und Funktionsnamen Kommentare ersetzen?

(00:23:43) Wird der Code fürs Lesen oder Schreiben optimiert?

(00:25:43) Bit-Shifting versteht doch keiner

(00:28:29) Wie komplex eigentlich die Bash-Programmierung sein

(00:33:11) TODO-Kommentare im Code oder lieber ein Ticket?

(00:36:56) Story-Telling im Code und Entwickler-Humor

(00:40:02) Kommentare in Deutsch oder Englisch und Domänen-Vokabular

(00:42:34) Wie sollten Git Commit Messages aussehen? Und warum Git Commit Messages E-Mail sein können

(00:45:39) Isolierte Git Commits für bessere Git Commit Messages

(00:46:44) Merge Commits

(00:49:59) Strukturierte Git Commit Messages und Nutzung von Prefixes wie bugfix und feature in Git Commit Messages

(00:52:13) Was ist Semantic Versioning (SemVer)?

(00:56:38) Der Linux Kernel als Vorbild für gute Commit Messages

(00:57:55) Wolfgangs Meinung zu Merge-Commits

(00:59:38) Branch-Visualisierung in Git

(01:01:30) Outro

Hosts

Wolfgang Gassler (https://twitter.com/schafele)
Andy Grunwald (https://twitter.com/andygrunwald)

Engineering Kiosk Podcast: Anfragen an stehtisch@engineeringkiosk.dev oder via Twitter an https://twitter.com/EngKiosk

Transkript

Das Transkript wurde automatisiert per Speech-to-Text erstellt und kann daher Fehler enthalten.

Andy Grunwald (00:00:03 - 00:00:52)

Herzlich willkommen zur Episode 15 vom Engineering Kiosk. Heute dreht sich alles um Kommentare im Quelltext und Git-Commit-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 okay oder sollten diese doch eher ein Ticket im Bug-Tracker sein? Wie hilfreich sind strukturierte Git-Commit-Messages? Und lieben oder hassen wir Merge Comets? Und was hat eigentlich die Kunst von Fynn Kliemann mit der Visualisierung von Git Branches zu tun? All das und noch viel mehr klären wir in der kommenden Stunde. Viel Spaß! 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?

Wolfi Gassler (00:00:52 - 00:01:02)

Wanderer ist ja fast eine Beleidigung. Das klingt so, als wenn man auf der Ebene 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?

Andy Grunwald (00:01:02 - 00:01:22)

Ich bin im Homeoffice und da muss man halt mal ab und zu die Tür hinter sich zumachen, das Büro sein lassen und einfach mal die Pause an der frischen Natur genießen. Und da kommt man halt viel ans Nachdenken, 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 wissen?

Wolfi Gassler (00:01:23 - 00:01:34)

Ich glaube, du hast nur den Tweet von, ich glaube, Hackmack2 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 es gut funktioniert.

Andy Grunwald (00:01:34 - 00:02:21)

Ich glaube, das ist so eine Art Religionskrieg. Ich verstehe, dass man seine Arbeit und 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 ja 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.

Wolfi Gassler (00:02:21 - 00:02:25)

Wobei du ja auch einen eigenen Raum hast, ein Office, du arbeitest ja auch nicht im Bett.

Andy Grunwald (00:02:25 - 00:02:30)

Meine Wohnsituation ist bezüglich Homeoffice sehr luxuriös, das ist richtig.

Wolfi Gassler (00:02:30 - 00:02:40)

Eben, du hast es ja auch sauber getrennt eigentlich. Aber um auf deine Frage zurückzukommen. Natürlich weiß ich, warum man Sport macht, um die kardiologische Fitness zu trainieren, für was sonst.

Andy Grunwald (00:02:40 - 00:03:01)

Um einfach abends ein Bier trinken zu können. Der Körper hat Energie ausgestoßen, braucht jetzt wieder wichtige Vitamine, Gerste und Co. Wirkt ja isotonisch. Gibt's heute bei mir ein schönes Düsseldorfer original Schlüssel seit 1850. Was trinkst du da?

Wolfi Gassler (00:03:01 - 00:03:07)

Frag besser nicht. Irgendein schwindliges Weißbier mit irgendeiner No-Name-Marke her, weil das ist das Beste, was man so in Holland bekommt.

Andy Grunwald (00:03:07 - 00:03:11)

Wurde das frisch aus Bayern oder aus Franken importiert? Gute Frage.

Wolfi Gassler (00:03:11 - 00:03:15)

Es kommt auf jeden Fall aus Deutschland. Keine Ahnung, wo es genau herkommt. Leider nicht aus Österreich.

Andy Grunwald (00:03:15 - 00:03:20)

Wie stehst du so als Österreicher zur bayerischen Ess- und Feierkultur?

Wolfi Gassler (00:03:20 - 00:03:26)

Oh, jetzt bin ich gespannt. Was verstehst du unter der bayerischen Feierkultur, du als Bot-Mensch?

Andy Grunwald (00:03:26 - 00:03:31)

Oktoberfest. Da gehe ich die Stereotypen-Route. Ich kenne, glaube ich, kein zweites Fest, was in Bayern gefeiert wird.

Wolfi Gassler (00:03:31 - 00:03:40)

Wir Tiroler können natürlich nicht viel anfangen mit Bayern, weil wir schon 1809 da gegen Bayern und Napoleon gekämpft haben und seitdem ist das sowieso alles alles verloren mit unserer Beziehung.

Andy Grunwald (00:03:40 - 00:03:49)

In Geschichte war ich noch nie so richtig gut, lass uns das skippen, sonst denken noch alle deutlich wer doof. Kommen wir mal zu unserem heutigen Thema.

Wolfi Gassler (00:03:49 - 00:04:15)

Was natürlich jetzt endlich mal technisch ist, weil diese Abstimmung, die wir auf Twitter durchgeführt haben, ob wir ein Karriere-Podcast oder ein Engineering-Podcast sind, ist ja nur ganz, ganz knapp ausgegangen für Engineering-Podcast. Mir würde auch interessieren, was die anderen 30 Prozent denken, dass wir weder Software-Engineering noch ein Karriere-Podcast sind. Aber damit wir jetzt endlich wieder mehr Software-Engineering machen, kommen wir heute mal zu einem Hardcore-Tech-Thema.

Andy Grunwald (00:04:15 - 00:04:32)

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.

Wolfi Gassler (00:04:32 - 00:04:39)

Also, die Entwickler musst du mir zeigen, die gerne Comments schreiben und über Comments diskutieren. Natürlich ist das Hardcore, dieses Thema. Verstehe.

Andy Grunwald (00:04:39 - 00:04:40)

Was war deine Frage?

Wolfi Gassler (00:04:40 - 00:05:07)

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, die Dateien rauspicken, die schön viele Comments drin haben. Eine random Datei.

Andy Grunwald (00:05:07 - 00:05:12)

Ich gehe hier gerade File, Open, Resend. So, ich habe eine Datei auf.

Wolfi Gassler (00:05:12 - 00:05:14)

Mit wieviel Zeilen?

Andy Grunwald (00:05:14 - 00:05:14)

86.

Wolfi Gassler (00:05:14 - 00:05:29)

Mhm, ihr hättet 70 anzubieten. Wieviel Comments? Oh, damit, das schaut schon nach sehr vielen aus. Du fangst schon an zu zählen mit... 22. Zweiundzwanzig. Okay, ihr habt zwei. Aber ihr habt natürlich selbsterklärenden Code, muss man auch dazu sagen.

Andy Grunwald (00:05:29 - 00:05:32)

Moment, da komme ich gleich drauf zu sprechen. Aber erklär mir mal ganz kurz, was deine Datei da macht.

Wolfi Gassler (00:05:32 - 00:05:36)

Wofür ist die verantwortlich? Das ist eine gute Frage.

Andy Grunwald (00:05:36 - 00:05:40)

Zwei Kommentarzeilen und keine Ahnung, was es tut. Okay.

Wolfi Gassler (00:05:40 - 00:05:54)

Doch, doch. Das ist selbsterklärender Code. Die macht viele Mappings. Die mappt einige Felder von einem Objekt ins andere sozusagen. Ist JavaScript, ist auch dreckig, ist ja klar. Okay, das will ich gleich wieder zurücknehmen. Man kann auch schön in JavaScript coden.

Andy Grunwald (00:05:54 - 00:06:13)

Meine Datei ist in Go geschrieben. Meine Datei ist ein HTTP-Händler von einem GitHub-Server, der GitHub-Webhooks entgegennimmt. Und dieser Code schaut sich das Webhook-Event an und routet es in entsprechende Message-Queues.

Wolfi Gassler (00:06:13 - 00:06:21)

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?

Andy Grunwald (00:06:21 - 00:06:46)

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.

Wolfi Gassler (00:06:46 - 00:06:49)

Also das sind eigentlich To-Dos?

Andy Grunwald (00:06:49 - 00:07:22)

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, in was ein GitHub-User klicken muss, damit ich dieses Webhook-Event kriege. Zum Beispiel gibt es im 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 Webhook-Event getriggert. Und das habe ich halt auch ein bisschen dokumentiert, damit ich überhaupt noch weiß, was da überhaupt los ist.

Wolfi Gassler (00:07:22 - 00:07:42)

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 darüber? Und sag mir jetzt nicht, weil ich das Thema vorgeschlagen habe.

Andy Grunwald (00:07:42 - 00:07:50)

Ich beantworte die Frage gleich, aber ich möchte erst einen kurzen Test mit dir machen. Was hast du Sonntagabend gegessen als Abendessen?

Wolfi Gassler (00:07:50 - 00:07:51)

Keine Ahnung mehr.

Andy Grunwald (00:07:51 - 00:08:31)

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 ein 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 der String gesplittet wird?

Wolfi Gassler (00:08:32 - 00:08:49)

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, ja.

Andy Grunwald (00:08:50 - 00:09:11)

Ich bin mir gar nicht sicher, ob es sinnvoll ist, zu erklären, 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.

Wolfi Gassler (00:09:12 - 00:09:23)

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, das in einer eigenen Datei liegt.

Andy Grunwald (00:09:23 - 00:09:50)

Ist ja auch egal. Du hast eine Klasse, eine Funktion, irgendwas Isoliertes. Und ich finde, du solltest jetzt nicht an diese 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 in einer ganz anderen Datei sein kann. Das ist, glaube ich, so ein bisschen, ich finde, der falsche Anwendungsfall von Kommentaren.

Wolfi Gassler (00:09:51 - 00:10:06)

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 zu suchen hat. Aber ganz allgemein, der Kontext da ist natürlich vollkommen recht.

Andy Grunwald (00:10:06 - 00:10:13)

Ich bin ein Riesenfan von Kommentaren und ich bin ein Riesenfan von sinnvollen Kommentaren.

Wolfi Gassler (00:10:13 - 00:10:16)

Oh, das ist sehr schön. Genau, das ist sinnvoll.

Andy Grunwald (00:10:16 - 00:10:53)

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. Ja, 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 selbsterklärend ist. 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 Codebase hast mit 5 Millionen Zeilen? Da ist nichts mehr selbsterklärend, auch wenn du die Sprache kannst.

Wolfi Gassler (00:10:54 - 00:11:19)

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

Andy Grunwald (00:11:20 - 00:11:53)

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. 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 meist 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 Pattern in Go.

Wolfi Gassler (00:11:53 - 00:12:00)

Du würdest jetzt nicht automatisch erklären immer, dass man eben diesen Arrow Code checkt. Das meinst du damit, oder?

Andy Grunwald (00:12:00 - 00:13:25)

Genau. Oder in 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 der ganzen Sache. Also die idiomatischen Patterns sollte man dann 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 ja also so dass es echt undurchsichtig wird welches modul du da jetzt eigentlich die reinholst wenn du wenn du in solche solche gebiete gehst dann würde ich sagen pack mal irgendwo ein kommentar drauf ja damit man 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, so was sollte man dann gegebenenfalls mal einen Kommentar drüber setzen. Aber nicht, also 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's immer refactoren und dann fällt das ganze Kartenhaus zusammen.

Wolfi Gassler (00:13:25 - 00:14:07)

Für mich ist da immer ein gutes Beispiel, wenn ich jetzt in der JavaScript-Welt bin, sind solche MapReduce-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, dass er so komplex ist, finde ich, verlangt er 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.

Andy Grunwald (00:14:07 - 00:14:36)

Das ist aber jetzt ein interessanter Punkt. Würdest du dann eher sagen, okay, der Code muss gerefaktet werden, weil zum Beispiel die zyklomatische Komplexität, das ist jetzt eine Codemetrik, wie viel Level du runtergehst, 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 aufsplitten?

Wolfi Gassler (00:14:36 - 00:15:37)

Ich glaube, es ist für beides. Natürlich, wenn man sinnvoll aufsplitten kann, ist es gut, aber es wird 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 Code schreibt, was da am Ende rausbootselt und wenn man es dann im Detail haben will, muss man sich halt das einmal durchdenken, weil wenn man es, 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 da steht im Code. Also man muss sich's 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 Block, was da passiert, dann kann ich den Block sozusagen überspringen, weiß, okay, in dem Bereich wird jetzt das gemacht und sollte ich mal was ändern wollen, muss ich mich halt da dann durch diese drei verschachtelten Funktionen durchdenken, aber das muss ich eigentlich immer, weil wenn ich das jetzt aufsplitt und dann kommentiere, dann steht halt jeweils das da, was eh schon im Code eigentlich da steht.

Andy Grunwald (00:15:37 - 00:15:53)

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 und sagst okay aber die kommentare sagen zwar dass die erklären mir das hier was ich was ja eigentlich vor sich geht aber ich vertraue dir nicht deswegen schaue ich nochmal nach oder.

Wolfi Gassler (00:15:53 - 00:16:01)

Nein genau im gegenteil also wenn ich eben den code gar nicht anfassen muss angreifen muss auf österreichisch.

Andy Grunwald (00:16:01 - 00:16:02)

Ist das ein feind der code?

Wolfi Gassler (00:16:03 - 00:16:30)

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, finde ich.

Andy Grunwald (00:16:30 - 00:17:45)

Nur um das klarzustellen, immer wenn ich jemanden höre, ich brauche keine Kommentare, weil der Code ist selbsterklä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-Handler, 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 Webhook 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 3.000 oder 4.000 Byte ist, weil nicht so viele Nachrichten da durchgehen. habe ich einfach dran gepackt, weil es für mich jetzt gerade okay ist. Später, wenn da richtig Traffic drauf kommt, 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-View-Server zu bekommen. Das meine ich mit Entscheidungen, die du während des Programmierens getroffen hast.

Wolfi Gassler (00:17:45 - 00:18:39)

Ja, das ist auch ganz wichtig, 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 Block-Einträge gelesen hast und dann zu dem Schluss gekommen bist, aufgrund der fünf Block-Einträge baue ich das jetzt irgendwie komplizierter oder mache ein spezielles Konstrukt nicht, was man üblicherweise macht und mache es 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 Hilfe stellt.

Andy Grunwald (00:18:39 - 00:18:43)

Völlig richtig. Ich packe da meist dran, so dieser Code wurde inspired by...

Wolfi Gassler (00:18:43 - 00:18:46)

Hoffentlich nicht Gott oder so.

Andy Grunwald (00:18:46 - 00:20:43)

Ne, ne, also da kommt dann wirklich ein hartes Feeling und oft ist es natürlich Stickoverflow. Da muss man aber einmal ganz kurz die Lizenzcode 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 dient 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 noch zu 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 hab, ist meist diese Art von Business-Domäne. Und das ist das, was ich grad geschrieben hab. Es gibt verschiedene Webhook-Events jetzt zum Beispiel. Nehmen wir dieses GitHub-Beispiel wieder. Und da hab ich wirklich Kommentare dran gepackt, dass Webhook-Event created, someone installs a GitHub-App. Weil es könnte ja auch create sein, created, könnte ja auch pullgeküsst sein. Das seh ich ja jetzt grad hier so nicht. 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 hab. Und zwar war das das Modul Algorithmen. Und 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 Landau-Notation überall dran. Einer der besten Dokumentationen meines Erachtens.

Wolfi Gassler (00:20:43 - 00:20:46)

Nur die einzige, die du ordentlich gelesen hast.

Andy Grunwald (00:20:46 - 00:21:02)

Sehr wahrscheinlich, ja. Auf jeden Fall hatte er, so wie das ein ordentlicher Professor tut, Algorithmen in C gelehrt. Und was machen C-Programmierer? Variablennamen mit mehr als einem Buchstaben sind eindeutig verboten, weil das Alphabet hat ja 26 Variablennamen.

Wolfi Gassler (00:21:06 - 00:21:09)

Also meist auf 26 Variablen dann immer limitiert, ja.

Andy Grunwald (00:21:09 - 00:21:59)

Aber für einen klassischen Algorithmus reicht das halt, ja. So ein Bubble Sort oder so ein Merge Sort, der kommt damit locker aus. Auf jeden Fall, ich glaube, für so einen klassischen Algorithmus, ja, C und klar, ich rede jetzt nicht von C-Variablen wie IJK. Ich glaube, die sind recht standardisiert in der Programmierwelt. Aber nehmen wir mal was wie V oder C, ja, 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 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?

Wolfi Gassler (00:22:00 - 00:22:40)

Ich glaube, da sind wir wieder bei dem selbsterklärenden Code. Ich glaube, ganz viele Details können über Variablennamen und Funktionsnamen einfach sauber abgebildet werden, ohne dass man überhaupt ein 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 das heutzutage eigentlich im Normalfall kein Problem mehr.

Andy Grunwald (00:22:40 - 00:22:45)

Ja, aber ich glaube, speziell bei Zählervariablen ist das jetzt so standardisiert weltweit.

Wolfi Gassler (00:22:46 - 00:23:35)

Ja, aber wenn der Code ein bisschen komplexer ist, dann kann mir der 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 autovervollstä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 Weilschleifen. Ich habe I und J als C der Variablen. Jedes Mal fängt der Kopf sofort an zu denken, 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.

Andy Grunwald (00:23:35 - 00:23:39)

Okay. Heißt das jetzt, du bist pro selbsterklärendem Code?

Wolfi Gassler (00:23:39 - 00:23:46)

Ja, natürlich. Alles, was ich mit dem Code selber erklären kann, spare ich mir natürlich in den Kommentaren. Sonst schreibe ich alles doppelt.

Andy Grunwald (00:23:46 - 00:23:57)

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?

Wolfi Gassler (00:23:57 - 00:24:01)

Was verstehst du unter Schreiben? Also das Verändern vom Code.

Andy Grunwald (00:24:01 - 00:24:02)

Genau. Erweitern.

Wolfi Gassler (00:24:03 - 00:24:07)

Ist es nicht das Gleiche, wenn ich etwas ändern will, muss ich es zuerst lesen und verstehen?

Andy Grunwald (00:24:07 - 00:24:17)

Das ist korrekt, aber immer wenn du etwas änderst, liest du den Code, aber nicht immer wenn du den Code liest, änderst du etwas. Und deswegen will ich wissen, für was deiner Meinung nach der Code optimiert werden sollte.

Wolfi Gassler (00:24:17 - 00:24:41)

Also am liebsten ist mir der Code einfach, den ich ohne Kommentare lesen kann. Wo ich einfach den Code liese, schnell scannen kann und super schnell verstehe, um was es geht. Und jedes Mal, wenn ich irgendwo eine Variable sehe, dass ich nicht die EDE 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.

Andy Grunwald (00:24:41 - 00:25:07)

Ich habe irgendwo gelesen, dass jeder Quellcode eigentlich primär fürs Lesen optimiert werden sollte, weil jede Zeile Code drei bis fünfmal 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 Files 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 so.

Wolfi Gassler (00:25:08 - 00:25:44)

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 Codes irgendwas optimiert, dass man den Code so schreibt, dass er irgendwie performanter ist, dass man extreme, idiomatische Konstrukte verwendet, irgendwelche Spezialkonstrukte, die vielleicht einem zu 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 um eine Spur schneller ist oder so.

Andy Grunwald (00:25:44 - 00:26:46)

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 Bitshifting und alle drum und dran. Bitshifting ist zum Beispiel so ein Thema, ja hatte ich in der Uni, verstehe ich einfach nicht. Also, wenn ich da mal 10 Minuten drauf gucke und mir ein kleines Beispiel-Skript schreibe, dann verstehe ich es auch wieder. Aber ich mag einfach nicht solche komplexen Prozeduren mit Sachen, die man, nehmen wir mal jetzt zum Beispiel die Web-Entwicklung, oft einfach in der Web-Entwicklung nicht braucht, weil den Performance-Gain von Bitshifting 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 Bitshifting zum Beispiel jetzt rauslässt, um den Code einfacher lesbarer zu machen für Leute, die mit Bitshifting jetzt nicht so familiär sind.

Wolfi Gassler (00:26:46 - 00:28:09)

Ja, so ein Klassiker sind ja so mathematische Funktionen, 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 weg abstrahieren, wenn man es unbedingt braucht, dass man halt eine dementsprechende Funktion macht, die erklärt im Namen, was das eigentlich macht mit diesem Integerwert und dann im Hintergrund wird das Bitshifting gemacht. Dann habe ich das weg abstrahiert und es muss nicht jeder wieder neu machen, wenn es mal wirklich darum geht, dass sie irgendwie, keine Ahnung, einen Integerwert in zwei Unterbereiche aufteilen und da irgendwie Informationen rein speichern oder so. Aber du hast vollkommen recht und ich kann mich da auch an ein Beispiel erinnern, wobei ich natürlich jetzt mit meinem akademischen Hintergrund schon sagen muss, dass Bitshifting 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 das war schon teilweise extrem enttäuschend, wer aller Bitshifting 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, glaube ich, nicht sinnloserweise komplizierter machen, als es nötig ist.

Andy Grunwald (00:28:10 - 00:28:27)

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ückzahlproduktion erzählen, über Opportunitätskosten. Über Opportunitätskosten kann ich dir auch alles erzählen, ja?

Wolfi Gassler (00:28:27 - 00:29:57)

Genau, also da hast du eine Ausrede. Aber 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 er 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, dass 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 ich 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, da 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?

Andy Grunwald (00:29:57 - 00:30:26)

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 Codes 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?

Wolfi Gassler (00:30:27 - 00:31:03)

Das soll keine Entschuldigung sein, meiner Meinung nach, dass man jetzt keinen idiomatischen Code schreibt und gute Konstrukte, diese Spezialkonstrukte, die es in Sprachen gibt, nicht mehr verwendet. Und wenn ein Python-Programmierer jetzt Python-Code verstehen muss und schreiben muss, dann sollte er auch die Eigenheiten von Python verstehen. Ich glaube, das ist sehr wichtig. Wenn jetzt jemand aber nur Bash-Script aufruft und eigentlich PHP 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 ich voraussetzen kann auch.

Andy Grunwald (00:31:03 - 00:32:23)

Das ist ein super Beispiel gemacht. Und zwar hatten wir bei Trivago ein paar Leute, die haben Ziemlich viel automatisiert und dann 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 Makefiles ausgeführt, hast du erstmal ein Error gekriegt, weil das irgendwelche nicht supporteten Funktionen benutzt. Du musstest also dein 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, was, ich sag, ist ein bisschen Zwiespalt, ist ein kleiner Zwiespalt, weil auf der einen Seite kannst du sagen, wir haben das Tool hier im Stack und wir nutzen das jetzt. Wir nutzen das jetzt bis zum Extent, 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 deine Balance?

Wolfi Gassler (00:32:23 - 00:33:12)

Genau darum sollte man sich überlegen, wer ist die Zielgruppe und wie leicht mache ich denn das Onboarding, wenn sich jemand meinen Code anschauen will. 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 ja 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. Sind glaube ich unterschiedliche Zielsetzungen.

Andy Grunwald (00:33:12 - 00:33:34)

So, dann kommen wir zur nächsten Frage. Jetzt hast du so einen Code vor dir und du hast den irgendwann verstanden und denkst dir, da gibt es doch eine einfache Lösung. Und du packst ein To-do-Comment dran. Du packst da drüber dran, TODO needs to be refactored to make it more simple. Bist du ein Fan von TODO-Comments oder sagst du, alle TODO-Comments sollen aus dem Code raus und sollen ordentlich ins Ticketsystem eingeführt werden?

Wolfi Gassler (00:33:34 - 00:34:30)

Ich bin ja ein riesiger Fan von Programmierern, die immer sagen, das 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 To-Dos drinnen stehen, und die vergisst man dann meistens. Das Schlimmste sind immer diese Catches von Exceptions, wo ein To-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 in 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 to do frei sein.

Andy Grunwald (00:34:30 - 00:34:34)

Also du würdest dann wirklich ein Ticket erstellen lassen oder ein Ticket selbst erstellen?

Wolfi Gassler (00:34:34 - 00:34:45)

Ist etwas fertig wenn ich wenn jetzt wenn jetzt dieses post oder oder meinen task auf auf dann setzen will dann muss das dinge funktionieren und dann muss das eigentlich ohne to do es funktionieren.

Andy Grunwald (00:34:45 - 00:35:14)

Was ist denn was ist denn mit der ganz alten fahrtfinder 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 nur 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, ne Andi, wenn du sowas siehst, mach bitte lieber ein Ticket.

Wolfi Gassler (00:35:15 - 00:36:08)

Ich glaube, man kann schon to 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 to do, da fehlt jetzt was, da muss man noch was machen, mit dem bin ich eigentlich nicht sehr einverstanden, weil, Klar ist Code nie fertig, aber für mich ist ein To-Do immer irgendwas, was noch nötig ist, damit der Code funktioniert. Und wenn ich ein Exception noch nicht gecatcht habe oder catche, aber nichts damit mache, dann ist das für mich kein sinnvoller Code, der fertig ist zum Merge. Und solche To-Dos sind meiner Meinung nach sinnlos. Wenn man da jetzt irgendwas reinschreibt, okay, To-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 To-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.

Andy Grunwald (00:36:09 - 00:36:44)

Da 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 und 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 Depth hin oder her ist ja auch so ein sehr subjektives Thema. Aber Code funktioniert, ist super stabil seit 25 Jahren, arbeitet nur nicht nach der neuen Methode. Kommt ein Kommentar ran und ab geht's.

Wolfi Gassler (00:36:44 - 00:36:54)

Okay, wir wissen ja eh, dass du auf Quick und Dirty bist und am liebsten den nicht funktionierenden Code committest. Gehen wir mal auf diesen Commit und auf diesen Merge.

Andy Grunwald (00:36:54 - 00:37:00)

Bevor wir da weiterspringen, ich hab noch eine Frage. Wie stehst du denn zu Storytelling im Code?

Wolfi Gassler (00:37:00 - 00:37:04)

Was ist für dich Storytelling? Ist das jedes Kommentar, was über 800 Zeichen hat?

Andy Grunwald (00:37:05 - 00:37:11)

Ich hab die 800 zeichen jetzt gerade wie viel tweets sind das damit ich so ungefähr den den das textvolumen im kopf habe.

Wolfi Gassler (00:37:11 - 00:37:13)

Drei tweets ungefähr.

Andy Grunwald (00:37:13 - 00:38:09)

Was ich meine ist einfach mal so so so eine kleine geschichte zu erzählen so ein bisschen entwickler humor ja du scrollst durch eine klasse und irgendwie kommt ein recht komplexes konstrukt und dann steht da ein 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 Counter. Ja, das ist so eine Art Storytelling, vielleicht so ein bisschen Entwicklerhumor. Einfach mal so ein bisschen, ich mach das jetzt so, es ist Sonntagabend 9 Uhr, ich will ins Bett. Das reicht jetzt, das Gaffertape. Sagst du, geht gar nicht, wir müssen uns professionell im Code verhalten oder sagst du, auch ganz im Ernst, der nächste Entwickler kann auch ein bisschen lachen.

Wolfi Gassler (00:38:09 - 00:39:04)

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 weder 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, da Jan von Tor verlinken wir gerne, hat mal so einen Vortrag über den Trivago-Code gemacht. Da kommen auch sehr, sehr nette Geschichten und Kommentare vor. Also wer sich mal interessiert, wie so ein Code aussieht, 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 ist da für böse Kommentare.

Andy Grunwald (00:39:04 - 00:40:04)

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 einfach eine Gottklasse, war superschwer zu verstehen, superschwer zu debuggen. Er hat sich da ein paar Monate reingestürzt. Und sehr spannender Talk. Auf jeden Fall gibt's auch, wer ein bisschen auf Entwicklerhumor steht, und ich bin ein Riesenfan von Storytelling-Code. In meinem Code findest du überall Storys, ob ich grad ein Bier trinke oder nicht, ob ich angepisst bin. Also ich pack da Storys rein, wie noch und nöcher, weil ich denke, das haben wir uns alle verdient, ein bisschen Humor, ein bisschen Kontext.

Wolfi Gassler (00:40:04 - 00:40:05)

Schreibst du diesen Humor auf Englisch?

Andy Grunwald (00:40:05 - 00:40:06)

Ja.

Wolfi Gassler (00:40:06 - 00:40:08)

Was haltest du von deutschen Kommentaren?

Andy Grunwald (00:40:08 - 00:40:14)

Gar nichts. Ich hab mal in dem Code gearbeitet und zwar war ich damals, hab ich für Vodafone gearbeitet.

Wolfi Gassler (00:40:15 - 00:40:21)

Fällt dir eigentlich auf, dass wenn Deutsche mehr inklusive Code aussprechen, dass es immer wie Code klingt mit K?

Andy Grunwald (00:40:21 - 00:40:38)

Vielleicht ist es auch genau so scheiße, ich weiß es nicht. Auf jeden Fall hab ich damals eine Software für Vodafone geschrieben, und die haben wir nicht begonnen, die Software, die hab ich übernommen. Dann hab ich die Software aufgemacht und da waren überall russische Kommentare drin. Und ich musste halt immer diese Kommentare durch so einen Translator senden.

Wolfi Gassler (00:40:38 - 00:40:40)

Seitdem kannst du russisch.

Andy Grunwald (00:40:40 - 00:40:59)

Nee, ich kann's nicht. Also seitdem, sag ich, englisch und fertig. Weil auch, obwohl eine Sache 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.

Wolfi Gassler (00:41:00 - 00:41:56)

Was für mich immer extrem schwierig ist, weniger als in den Kommentaren, aber in variablen Namen, wenn du in so einem Kontext arbeitest, der rein deutsch ist, und ich habe zum Beispiel eine Codebase, die im Lebensmittelhandel unterwegs ist, und die haben einfach alles deutsche Begriffe. Und 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 Businessfeld auf Englisch überhaupt zu finden. Also da fällt es mir dann auch immer schwer, wirklich die englischen Begriffe zu suchen oder das irgendwie auf Englisch zu schreiben. Das Problem am Ende ist, dass andere Leute, inklusive mir selber, den englischen Code nicht mehr verstehen, weil man die englischen Begriffe einfach nie verwendet, sondern nur die spezialen deutschen Begriffe, irgendwelche auch Businessbegriffe, steuerlichen Begriffe. Das ist natürlich extrem schwierig. Hast du da eine Lösung?

Andy Grunwald (00:41:57 - 00:42:09)

Nee, hab ich nicht. Also, es kommt natürlich aufs Umfeld drauf an. Vielleicht hilft es auch einfach, das deutsche Fachwort dahin zu schreiben. Ich meine, auch Leute, die dem Deutschen nicht mächtig sind, die dann in der Firma und an dem Code arbeiten, kommen in das Domänen-Vokabular ja recht schnell rein.

Wolfi Gassler (00:42:10 - 00:42:17)

Wobei das dann oft so eine Mischung wird. Dann heißt es halt irgendwie Get Steuerklasse 18 oder so irgendwas.

Andy Grunwald (00:42:17 - 00:42:25)

Ich habe noch nie Steuersoftware geschrieben. Aber ja, 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.

Wolfi Gassler (00:42:25 - 00:42:46)

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, Commitmessages. Wenn du jetzt einen Code merchen willst, der voller To-Do-Comments ist und unvollständig und dirty-hacked, was schreibst du denn in die Git-Comments rein?

Andy Grunwald (00:42:46 - 00:42:47)

Fixbug.

Wolfi Gassler (00:42:47 - 00:42:50)

Wenigstens eine Bug-Nummer oder nur Fixbug?

Andy Grunwald (00:42:50 - 00:42:54)

Fixbug. Wir hatten einen Bug, der ist nicht mehr da, somit muss keiner mehr wissen, was das für ein Bug war.

Wolfi Gassler (00:42:54 - 00:42:58)

Ist so ähnlich wie die Variable x plus y oder so, oder?

Andy Grunwald (00:42:58 - 00:43:01)

Ich hab dir grad gesagt, ich bin ein Fan von Zählervariablen, i, j, k.

Wolfi Gassler (00:43:01 - 00:43:05)

Das kann man natürlich auch fortsetzen auf Git-Comments, ja.

Andy Grunwald (00:43:05 - 00:43:59)

Nein, natürlich nicht. Also ich bin ein Fan von guten Comment-Messages. Ich gebe zu, ich mach das nicht immer, weil eine sehr gut beschriebene Git-Comment-Message braucht einfach Zeit und Energie. Ich versuche schon zu zu beschreiben was ich da gemacht habe aber auch warum ich das gemacht habe und versuche sofern vorhanden immer ein ticket zu verlinken in der in der git comment message 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 und lese durch warum etwas gemacht wurde, weil ich vielleicht einfach zu oft enttäuscht wurde dass super viele leute so genauso sind wie ich und einfach zu faul sind gute git comet messages zu schreiben.

Wolfi Gassler (00:44:00 - 00:45:38)

Also ich hatte mal vor Jahren irgendwie den Vortrag gehört über Git-Comments. Und der war für mich irgendwie augenöffnend. 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, es hat Subject und dann Body, wo ich mehr reinschreiben kann und vielleicht noch irgendwo ein paar Referenzen am Ende in irgendeinem 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 Blog-Einträge, die irgendwie erklären, was man da nicht alles reinpacken kann. Wenn man sich so bei den Grundregeln haltet, man hat eine Ü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-Message? Und wie gesagt, vielleicht nur ein fix Hashtag 72 oder 270 als Stickhead zum Beispiel. Das braucht eigentlich nicht viel Zeit, ist sofort geschrieben und man hat es dann schon in der Git-Commit-Message drinnen. Wenn man dann ein Merge oder ein PR erstellt, wird das automatisch übernommen. Man hat da schon die Infos drinnen und braucht dann gar nicht mehr viel dementsprechend dazuschreiben für ein 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.

Andy Grunwald (00:45:38 - 00:46:08)

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 gefixt hast, warum du ihn gefixt 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 und dann geht Commit-Message.

Wolfi Gassler (00:46:08 - 00:46:23)

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.

Andy Grunwald (00:46:23 - 00:46:44)

Ich squash überhaupt nicht, ne. Aber ich hab ich hab schon mal gesponsert weil ich das feature mal testen wollte aber ich habe gerade gesagt ich schaue sehr sehr selten in die githistorie zurück ich sollte es viel öfter machen und ich nutze auch sowas wie git bisect nicht um bugs zu finden und und comics zu trennen und allem drum und dran.

Wolfi Gassler (00:46:44 - 00:46:47)

Du machst wahrscheinlich dann auch Merge Commits.

Andy Grunwald (00:46:47 - 00:47:02)

Ich mache Merge Commits und egal in welchem Team ich bin, ich folge einfach deren Regeln. Wenn die Fans von Merge Commits sind, okay, dann machen wir das. Wenn die Merge Commits hassen und ihre Git-Historie total clean haben wollen, dann machen wir das. Ich bin da recht leidenschaftlos.

Wolfi Gassler (00:47:02 - 00:47:31)

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-Merges oder Rebase ist auch so ein Klassiker. Sollte ja nicht wirklich jeder Developer wissen, sollte man sich also wirklich mal im Detail anschauen, wie das funktioniert, auch wenn der Andi das nie macht.

Andy Grunwald (00:47:32 - 00:47:54)

Vielleicht für den Kontext für die Hörer, die auch nicht wissen, was Merge-Commits sind. Wenn ihr zum Beispiel ein Pull-Request auf Git habt 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 Subversion der Trunk, gemerged.

Wolfi Gassler (00:47:55 - 00:47:59)

Für die jüngeren Zuhörer und Hörerinnen, was ist SVN?

Andy Grunwald (00:47:59 - 00:48:14)

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.

Wolfi Gassler (00:48:14 - 00:48:24)

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.

Andy Grunwald (00:48:24 - 00:49:30)

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 eure 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 wurde. Dann gibt's Teams, die sagen, och, 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ürd mal eure Meinung dazu interessieren, wie ihr dazu steht. Weil ich hab halt auch schon gemerkt, das führt dann wieder zu religiösen Diskussionen im Team, so was wie Tabs versus Whitespaces, Wim oder Emacs und Ähnliches. Und ich denke, wir sollten unsere Energie ...

Wolfi Gassler (00:49:30 - 00:49:35)

Was soll man denn da für Diskussionen führen? Es ist ganz klar, dass das Whitespaces sind. Braucht man gar nicht diskutieren.

Andy Grunwald (00:49:36 - 00:50:12)

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-Comets. Also, Git-Comet-Messages, super. Wir sollten alle, meines Erachtens nach, mehr Zeit drauf verbringen, gute Git-Comet-Messages zu schreiben. Kennst du die Art und Weise von Git-Comet-Messages, wo du mit einem Präfix indizierst, was das für ein Comet ist? Ein Bug-Fix, ein Feature, ein Dependency-Upgrade, ein Breaking-Change oder Ähnliches. Kennst du das?

Wolfi Gassler (00:50:12 - 00:50:22)

Ich muss zugeben, ich hab das jetzt zum ersten Mal gelesen, dass das eigentlich eine ganz gute Herangehensweise ist. Und ist ja auch nicht schlecht, wenn man so ein bisschen Kontext gibt, aber findest du es ist sehr wichtig?

Andy Grunwald (00:50:22 - 00:52:16)

Ob so super wichtig ist, weiß ich nicht. Hat es value meines Erachtens nach schon, weil du kannst nämlich Bugfixes 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 wirkliche Funktionsänderungen hat oder welche nicht und welchen ich re-verte. 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 sowieso sowas. Da gibt es aber dann auch das Tooling, was mich komplett dabei supportet. Git Pre-Comet-Hooks, Git-Comet-Message-Templates und so weiter und so fort. Die geben mir schon ein vorgefertigtes Framework, wo ich dann einfach nur Daten eingebe. Aber der Riesenvorteil ist natürlich, umso standardisierter deine Git-Comet-Messages sind, umso mehr Automatisierung kannst du draufbauen. 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 maintaint dieser Release Please, der Release Please Bot, nämlich ein Change Log für dich. Der sagt, welche Breaking Changes es gibt, welche neuen Features, welche Bugfixes, aber auch, ob du deine Versionsnummer hochdrehen musst, weil du ein Breaking Change zum Beispiel drin hattest. Oder ob das nur eine Bug-Sekretion ist oder ein Major- oder Minor-Upgrade, sofern du natürlich Semantic Versioning benutzt. 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 Text computertechnisch parsen lässt.

Wolfi Gassler (00:52:16 - 00:52:18)

Was ist ein Semantic Versioning?

Andy Grunwald (00:52:18 - 00:53:12)

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 die meiner Version, die mittlere Versionsstelle erhöht. Wenn du jetzt nur einen Bugfix hast, dann wird die letzte Versionsstelle erhöht. Und wenn du jetzt ein 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 werden muss.

Wolfi Gassler (00:53:12 - 00:53:19)

Die erste Nummer ist Major, zweite Nummer ist Minor und die dritte Nummer ist Patch Level. Habe ich das richtig verstanden?

Andy Grunwald (00:53:19 - 00:53:20)

Patch oder Bugfix, ja genau.

Wolfi Gassler (00:53:20 - 00:53:29)

Wenn sich was wirklich ändert, was Breaking sein könnte, dann sehe ich das an der ersten Zahl von so einem dreistelligen Semantic Versioning.

Andy Grunwald (00:53:29 - 00:53:46)

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-Chars hast oder ähnliches. Ja, ein paar Metainformationen. Oder vielleicht Release-Date sowas wie Alpha und Beta wird da auch nochmal drangehangen. Da gibt es dann immer so kleinere Erweiterungen.

Wolfi Gassler (00:53:46 - 00:53:53)

Verlinken wir natürlich auch in den Shownotes. Ist super einfaches Konzept, aber ist genial, weil es halt extrem weiterhilft.

Andy Grunwald (00:53:53 - 00:54:51)

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 der Programmierung, je nach verwendeter Sprache, ganz klare Regeln, wann etwas ein Breaking Change 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-Change, 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 daran packst und assignst dem ein Default-Parameter, dann können User mit dieser API einfach upgraden, ohne dass die API bricht. 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.

Wolfi Gassler (00:54:51 - 00:54:53)

Wie lange ist das eigentlich her?

Andy Grunwald (00:54:53 - 00:54:56)

März 2013 habe ich meine Arbeit verteidigt.

Wolfi Gassler (00:54:56 - 00:55:00)

Das ist jetzt fast zehn Jahre her. Der Code ist nicht mal mehr lauffähig.

Andy Grunwald (00:55:00 - 00:55:04)

Es war auf jeden Fall sehr viel Python in Version 2 involviert. Das ist richtig.

Wolfi Gassler (00:55:04 - 00:55:17)

Naja gut, das war jetzt noch kein Argument, weil ich glaube irgendwie der Großteil aller beiden Programme laufen immer noch auf 2.8 ist es glaube ich. Also das war jetzt gar kein Sonderfall. Insofern funktioniert es wahrscheinlich noch.

Andy Grunwald (00:55:17 - 00:55:31)

Ich sag mal so, ich habe damals auf jeden Fall deutlich weniger Kommentare genutzt und meine Git-Comment-Messages sahen noch schrecklicher aus. Also 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.

Wolfi Gassler (00:55:32 - 00:55:34)

Ist der irgendwo öffentlich, zugänglich?

Andy Grunwald (00:55:34 - 00:55:37)

In archivierten GitHub-Repositoren in meinem Profil, ja.

Wolfi Gassler (00:55:38 - 00:55:44)

Ah, dann werden wir den einfach auch verlinken, dass die Leute mal sehen können, wie man Git-Commit-Messages nicht schreibt.

Andy Grunwald (00:55:44 - 00:56:24)

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. Kommen wir zum eigentlichen Punkt. 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 und das Beste, die Qualität eurer Releases natürlich erhöhen. Und wenn ich sage 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 publisht da APIs, Release-Nodes und Change-Log-Nodes sind Gold wert, wenn ihr Cross-Team-technisch arbeitet.

Wolfi Gassler (00:56:25 - 00:56:54)

Vor allem, wenn man das natürlich in irgendeiner Form automatisieren kann, weil dann ist es auch kaum mehr Arbeit und geht einfach automatisch immer mit und die ganzen Dokumentationen werden auch dementsprechend upgedatet, 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?

Andy Grunwald (00:56:55 - 00:57:25)

Meines Erachtens nach das Projekt mit den besten Comment Messages ist der Linux Kernel. Der Linux Kernel ist 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 in den Comment Messages übertragen ist, ist schon sehr beachtlich.

Wolfi Gassler (00:57:25 - 00:57:30)

Liegt der Linux-Kernel eigentlich immer noch bei Linus Torvalds, seinem privaten Account?

Andy Grunwald (00:57:30 - 00:57:35)

Das weiß ich gerade nicht, ich weiß aber, dass der Linux-Kernel auf GitHub nur ein Mirror ist.

Wolfi Gassler (00:57:35 - 00:57:47)

Also ich hab's mal gerade gecheckt, es ist zumindest in seinem Account. Linus Torvalds war ja auch der Entwickler, der erste Entwickler von Git, also das muss er doch natürlich auch gute Git-Messages schreiben, Commit-Messages, hoffe ich doch mal.

Andy Grunwald (00:57:48 - 00:58:12)

Wir verlinken in den Shownotes 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-Commits? Kontra? Gibst du dir wirklich viel Zeit und Mühe für deine Git-Commit-Message oder sagst du, ach fuck it, ich bin eh der Einzige, der hier für Jahre entwickeln wird?

Wolfi Gassler (00:58:12 - 00:58:47)

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 Merge 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 Merge Commit, Und er mir erklärt hat, wie einfach das ist mit Fast Forward und wie man das sauber macht mit Repace. Ab diesem Zeitpunkt gibt es bei mir eigentlich nur mehr Pull, Repace und alles wird gerepacet und dementsprechend sauber wieder zusammen gemerged, wenn es um Branches geht.

Andy Grunwald (00:58:47 - 00:59:00)

Ich schlage gerade die Hände über dem Kopf zusammen. Wolfgang, wir haben doch die Tage festgestellt, du bist ein Kunstbanause. Also, kurz zum Kontext. Und zwar habe ich mich in den Newsletter von Fynn Kliemann eingetragen. Wer ihn nicht kennt, einfach mal googeln. Krasser Typ.

Wolfi Gassler (00:59:00 - 00:59:01)

Braucht man nicht kennen.

Andy Grunwald (00:59:01 - 00:59:12)

Finn kliemann malt auch und verkauft seine kunst und er hat ja seinen neuen kunstkatalog rausgebracht für die für die gemälde die man dabei kaufen kann habe ich den wolfgang geschickt.

Wolfi Gassler (00:59:12 - 00:59:19)

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.

Andy Grunwald (00:59:19 - 00:59:21)

Davon verstehe ich echt nix.

Wolfi Gassler (00:59:21 - 00:59:23)

Also du willst nur seine wahre kunst.

Andy Grunwald (00:59:23 - 00:59:35)

Bin ich fan weiß ich nicht ich finde es spannend was er macht. Auf jeden Fall. Erzählst du mir jetzt irgendwas von irgendwelchen Branch, von irgendwelcher Branch-Kunst und ... Sorry, mit Kunst nehm ich dich einfach nicht mehr ernst.

Wolfi Gassler (00:59:35 - 00:59:39)

Das ist halt Engineering-Kunst. Das verstehst du nicht.

Andy Grunwald (00:59:39 - 01:00:20)

Aber kommen wir doch mal zu dieser Branch-Visualisierung. Das ist ja wirklich eine tolle Sache. Ich mein, Git ist ja darauf gebaut, dass du kontinuierlich branch und merchst. 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 da raus? 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 merkt das wieder zurück. Welchen Value ziehst du aus dieser Branch-Visualisierung?

Wolfi Gassler (01:00:21 - 01:00:46)

Ich sehe das Ganze ja als Kunst an, insofern darfst du mich da jetzt weniger fragen. Aber so richtige gute Entwickler, ich zähle mich da ja nicht wirklich dazu, haben mir eben 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, was gerade offen ist an Branches. Also scheinbar hat es schon viel Mehrwert für gute Entwickler, Andi.

Andy Grunwald (01:00:46 - 01:01:20)

Ich sehe den Mehrwert, wenn man irgendwelche Git-Workflows wie GitFlow nimmt oder ähnliches, wo man Release-Branches rauszieht und auf diesen Release-Branches weiterentwickelt und so weiter. Da verstehe ich das alles. Und bei GitHub würde ich auch noch den Wert verstehen, weil GitHub selbst sogar Forks mit visualisiert. Und da sieht man, wie weit Forks von seinen eigenen Projekten weiterentwickelt werden. Aber innerhalb deines eigenen Git-Projekts weiß ich nicht. Also ich habe da jetzt noch keinen Wert daraus gesehen. Aber ich sage ja auch, dass ich viel zu selten die Git-Historie durchforste.

Wolfi Gassler (01:01:20 - 01:01:33)

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.

Andy Grunwald (01:01:33 - 01:02:23)

Und das war das Schlusswort. Wir haben uns eine ganze Zeit lang über sehr viel subjektive Themen unterhalten. Kommentare, selbsterklärender Code, Git-Comet-Messages. Natürlich ist das Thema endlos. Wir haben super viele Dinge nicht erwähnt. Wir sind nicht auf Git-Pre-Comet-Hooks eingegangen. Wir sind nicht auf Git-Comet-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 bin 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.

Wolfi Gassler (01:02:23 - 01:02:29)

Und wenn es auch nur die kunst von wie heißt der gute karl kim kim anders ist von nordkorea wie heißt.

Andy Grunwald (01:02:29 - 01:02:33)

Deiner finn klimann finn klimann ist mit kim jong-un zu vergleichen ist ein bisschen hart.

Wolfi Gassler (01:02:34 - 01:03:31)

Auf jeden Fall, wenn man vielleicht noch eine Take-Away-Message definieren sollte oder möchte, man sollte immer eine Take-Away-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 10-20% 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 für sich feststellen, bringt sich das Ganze irgendwas, zieht man irgendwas dabei raus oder ist es sowieso sinnlos. Aber ich glaube, 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.

Andy Grunwald (01:03:32 - 01:03:48)

Und wenn ihr neugierig seid, wie unser Core-Source-Code aussieht, mit viel 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 atengineeringkiosk, E-N-G-Kiosk folgen.

Wolfi Gassler (01:03:48 - 01:03:52)

Ist das dann auch schon Kunst, die wir verkaufen können? Können wir dann NFTs irgendwie drauf bauen?

Andy Grunwald (01:03:54 - 01:03:57)

Ich verstehe NFTs nicht, deswegen bin ich da raus.

Wolfi Gassler (01:03:58 - 01:04:06)

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.

Andy Grunwald (01:04:07 - 01:04:15)

Ansonsten verspreche ich euch, dass wir in Zukunft technische Themen, die mehr Hardcore, Hardcore-iger Ich weiß nicht, wie man das jetzt nennt.

Wolfi Gassler (01:04:15 - 01:04:37)

Machen als... Moment, wenn das jetzt keine Hardcore-technische Session war heute, ist es wohl ideal. Also wir sehen übrigens zur Information, die Episode wird dann etwas kürzer. 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 an die Grundsicht gegeben hat. Auf jeden Fall finde ich das schon ein sehr technisches Thema. Oder ist da jemand anderer Meinung?

Andy Grunwald (01:04:38 - 01:04:49)

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ürde ich sagen, halten wir es kurz. Vielen Dank fürs Zuhören. Bis bald.

Wolfi Gassler (01:04:49 - 01:04:55)

Und nicht vergessen, auch bei E-Mail stetisch at engineeringkiosk.dev ist natürlich möglich. Ciao.