Yurna fängt an: ein Bot, der eigentlich nur Memes posten sollte

Es gibt in fast jedem Projekt ein Datum, das man später als Anfang bezeichnet, obwohl der eigentliche Anfang schon vorher stattgefunden hat. Bei mir ist es der 24. Februar 2020. Das ist der Tag, an dem ich das Repository angelegt habe, aus dem über die Jahre Yurna geworden ist.

Vorher gab es schon einen Bot. Den aus dem letzten Jahr, vierhundert Zeilen, eine Datei, gewachsen aus Zurufen. Er lief, aber er war an einem Punkt, an dem jede neue Idee mehr Arbeit machte als die vorherige. Und ich hatte inzwischen genug gesehen, um zu wissen, dass es anders geht.

Warum ich nicht bei null angefangen habe

Die ehrliche Antwort: weil ich es nicht gekonnt hätte. Nicht in dem Umfang, den ich mir vorstellte.

Ich wollte einen Bot mit Kategorien, mit einer sauberen Befehlsstruktur, mit Rechteprüfung, mit mehreren Sprachen, mit einer Datenbank dahinter. Ich wusste, wie man ein !ping beantwortet. Zwischen diesen beiden Punkten lag mehr, als ich mir in einem Winter selbst beibringen konnte.

Also habe ich getan, was viele in dieser Lage tun: Ich habe mir ein offenes Projekt gesucht, das ungefähr die Struktur hatte, die ich wollte, und darauf aufgesetzt. Ein Grundgerüst, das Befehle aus Ordnern lädt, das Ereignisse sauber trennt, das eine Konfiguration hat statt zwanzig Konstanten im Code.

Das war rückblickend die richtige Entscheidung — und sie hat einen Preis, den ich damals nicht sehen konnte. Beides gehört in diesen Eintrag.

Was ich davon hatte

Ich habe an einem funktionierenden Aufbau gelernt statt an einer leeren Datei. Der Unterschied ist enorm. Ich konnte einen Befehl ansehen, verstehen, wie er aufgebaut ist, und den nächsten selbst schreiben. Ein Muster nachzumachen ist ein völlig anderer Lernvorgang als sich eines auszudenken.

Ich war innerhalb von zwei Wochen an dem Punkt, an dem der alte Bot nach einem Jahr war. Und danach ging es weiter, statt langsamer zu werden.

Ich habe zum ersten Mal fremden Code gelesen, der besser war als meiner. Kleinigkeiten, über die ich vorher nie nachgedacht hatte: dass eine Funktion einen Fehler zurückgibt, statt ihn selbst auszugeben. Dass Texte nicht mitten im Code stehen. Dass man Wiederholungen erkennt und in eine Hilfsfunktion zieht.

Was es gekostet hat

Ich habe eine Zeit lang Code betreut, den ich nicht vollständig verstanden habe. Es gab Bereiche, die einfach da waren und funktionierten, bis sie es nicht mehr taten. Jedes Mal, wenn dort etwas kaputtging, war die Reparatur teurer als bei eigenem Code, weil ich erst nachvollziehen musste, was der Teil eigentlich vorhatte.

Die Herkunft bleibt lange sichtbar. Namen, Konventionen, Kommentare, Dokumentationsreste. Noch Jahre später sind mir Stellen begegnet, an denen der Ursprung durchschimmerte — in Readme-Dateien, die eine ganz andere Datenbank beschrieben, in Feldnamen, die aus einer Zeit stammten, in der etwas anderes gemeint war.

Man erbt Entscheidungen. Die Datenhaltung, die Ordnerstruktur, die Art, wie Konfiguration geladen wird — all das war vorgegeben, und einiges davon hätte ich anders gemacht, wenn ich zu dem Zeitpunkt gewusst hätte, dass man es anders machen kann.

Infobox

Wer auf einer offenen Vorlage aufsetzt, sollte zwei Dinge von Anfang an tun: Lizenz lesen und einhalten — die meisten offenen Projekte verlangen Namensnennung, manche mehr. Und regelmäßig eigene Teile ersetzen, statt nur oben draufzubauen. Sonst hat man nach zwei Jahren ein Projekt, das zu 70 Prozent aus fremdem Code besteht, den niemand mehr versteht.

Der Name kam viel später

Yurna hieß der Bot 2020 noch nicht. Er hatte einen Arbeitstitel, den ich hier nicht wiederholen möchte, weil er auf einem Wortspiel beruhte, das nur ich lustig fand.

Der Name kam erst, als das Projekt eine Domain bekam und ich merkte, dass ein Bot mit hundert Befehlen und einer Webseite nicht mehr „mein Botprojekt" heißen kann. Ich schreibe das hier hin, weil ich es rückblickend für eine gesunde Reihenfolge halte: erst etwas bauen, das funktioniert, dann einen Namen suchen. Ich habe seitdem Leute gesehen, die drei Wochen an einem Logo arbeiten, bevor eine Zeile Code existiert.

Was am 24. Februar 2020 tatsächlich da war

Damit dieser Eintrag nicht größer klingt, als der Tag war — der Stand am Abend:

Ein Befehlsloader, der einen Ordner durchgeht und alles registriert, was er findet.
Fünf Befehle: ping, hilfe, info, würfel, avatar.
Eine Konfigurationsdatei mit Präfix und Token, letzterer diesmal in einer .env.
Ein Ereignis für eingehende Nachrichten, eines für den Start.
Kein Dashboard, keine Datenbank, keine Slash-Commands — die gab es damals noch gar nicht.

Das war's. Fünf Befehle. Wenn mir an diesem Abend jemand gesagt hätte, dass aus diesem Ordner ein Projekt mit über hundert Befehlen, einem Web-Dashboard, einer eigenen Verwaltungsschnittstelle und einer Datenbank mit über hundert Modellen wird, hätte ich das für einen Scherz gehalten.

Was ich in den ersten Wochen gelernt habe

Der Einstieg über ein bestehendes Projekt hat mir eine Sache beigebracht, die ich sonst vermutlich viel später gelernt hätte: fremden Code zu lesen, ohne ihn sofort ändern zu wollen.

Meine erste Reaktion auf jede Stelle, die ich nicht verstand, war der Impuls, sie umzuschreiben. In den meisten Fällen war das falsch. Es gab einen Grund für die Struktur, und der Grund war meistens ein Fall, den ich noch nicht kannte.

Die Technik, die dagegen hilft, ist banal und wirksam: Bevor ich etwas ändere, schreibe ich in einem Satz auf, was der Code tut. Wenn mir dieser Satz nicht gelingt, habe ich ihn nicht verstanden — und dann ändere ich ihn nicht.

Die zweite Sache war der Umgang mit Abhängigkeiten. Das Grundgerüst brachte ein knappes Dutzend fremder Pakete mit, von denen ich keines ausgesucht hatte. Jedes davon ist eine Entscheidung, die jemand anderes getroffen hat und die ich seitdem trage: Updates, Sicherheitsmeldungen, irgendwann die Frage, ob ein Paket noch gepflegt wird.

Die Lizenzfrage, die ich zu spät gestellt habe

Ein Punkt, der mir erst nach Monaten klar wurde und den ich hier ausdrücklich hinschreibe, weil ihn viele überspringen: Ein offenes Projekt ist nicht dasselbe wie ein Projekt ohne Bedingungen.

Die meisten Lizenzen verlangen, dass Urheberhinweise erhalten bleiben. Manche verlangen, dass abgeleitete Werke unter derselben Lizenz stehen. Manche verlangen Namensnennung an sichtbarer Stelle.

Ich habe die Lizenz meines Ausgangsprojekts gelesen, nachdem ich vier Monate darauf gebaut hatte. Es ist gut ausgegangen — die Bedingungen waren erfüllbar, und ich habe die Namensnennung ergänzt, wo sie hingehört. Aber es hätte auch anders kommen können, und dann wäre die Frage nicht gewesen, ob ich sie erfülle, sondern ob ich vier Monate Arbeit wegwerfe.

Seitdem ist das der erste Schritt, bevor ich fremden Code übernehme: Lizenz lesen, Bedingungen notieren, und die Notiz an eine Stelle legen, an der ich sie in zwei Jahren wiederfinde.

Was ich daraus mitnehme

Der wichtigste Satz dieses Eintrags ist wahrscheinlich der unspektakulärste: Ein Projekt fängt nicht mit einer Idee an, sondern mit einem Ordner, in dem etwas läuft.

Ich hatte die Idee für einen besseren Bot monatelang. Passiert ist erst etwas, als es ein Repository gab, in dem fünf Befehle funktionierten. Alles danach war Fortsetzung. Das ist keine besonders originelle Erkenntnis, aber sie hat sich bei mir seitdem bei jedem größeren Vorhaben bestätigt — auch bei denen, die nie über den ersten Ordner hinausgekommen sind.