Aki's Vibes

[Akira]

Wie ich akisim umbaue, ohne die Gäste rauszuwerfen

Oder: Was ich gerade über Software-Architektur lerne, am Beispiel von akisim

Ich bastle gerade an einem ziemlich verrückten Projekt: einem Region-Server für virtuelle Welten. Das ist die Software, die im Hintergrund läuft, wenn du dich in OpenSim einloggst und mit deinem Avatar durch eine Region spazierst. Sie verwaltet die Bäume, die Häuser, die anderen Avatare, die Physik, das Chatten – alles.

Das Projekt heißt akisim. Es startet als Fork (Abzweigung) eines bestehenden Projekts namens OpenSim, das es seit fast zwanzig Jahren gibt. Und genau da fängt das Drama an.

Das Hotel-Problem

Stell dir OpenSim als ein altes, verwinkeltes Hotel vor, an dem zwanzig Jahre lang gebaut wurde. Jeder Eigentümer hat irgendwo einen Anbau drangepappt. Die Heizung läuft durchs Dachgeschoss, das Telefonkabel führt durch den Pool, und niemand weiß mehr, warum die Klingel von Zimmer 47 das Licht in der Lobby auslöst.

Es funktioniert. Irgendwie. Aber jeder Handwerker, der reinkommt, braucht drei Tage, bis er auch nur einen tropfenden Wasserhahn findet.

So sieht der Code von OpenSim aus. Knapp hundert Teilprojekte, davon siebzehn mit doppelten Namen (Erblast eines längst entsorgten Plugin-Systems). Die Datenbank-Schicht kennt die 3D-Welt-Schicht. Die HTTP-Schicht hat statische Hilfsfunktionen, die irgendwer in dreihundert anderen Stellen im Code aufruft. Wenn du etwas änderst, weißt du nie, was woanders kaputtgeht.

Ich will das Hotel renovieren. Im laufenden Betrieb. Mit Gästen drin.

Erste Entscheidung: vier saubere Stockwerke

Statt das Chaos zu erweitern, setze ich akisim aus vier sauberen Stockwerken auf. Jedes Stockwerk hat genau eine Aufgabe, und Stockwerke reden nur in eine Richtung miteinander – von außen nach innen.

• Erdgeschoss (Domain): das Tragwerk. Hier wohnen die Konzepte – was ist ein Avatar, was ist eine Region, was ist eine Berechtigung. Reine Idee, kein Schnickschnack.
  
• Erster Stock (Application): der Concierge. Nimmt Aufträge entgegen ("dieser Avatar will da rein") und orchestriert, was passieren muss.
  
• Zweiter Stock (Adapter): die Türen und Fenster. Übersetzt zwischen drinnen und draußen – die Sprache, mit der dein Viewer redet, ist eine andere als die Sprache des Concierges.
  
• Dachgeschoss (Infrastructure): Keller-Technik in Dachgeschoss-Verkleidung. Datenbank, HTTP, Telemetrie, der ganze technische Kram.
  

Plus ein kleines Hausmeister-Büro (im Code heißt es "Composition Root"), das alles zusammenstöpselt.

Das klingt nach mehr Aufwand. Ist es auch – kurzfristig. Aber wenn jemand morgen kommt und sagt "wir wechseln die Datenbank", muss ich nur das Dachgeschoss anfassen. Das Erdgeschoss merkt davon nichts.

Die radikalste Entscheidung: das Erdgeschoss bleibt nackt

Hier wird's interessant, und das ist die Entscheidung, an der ich mich gerade selbst zur Disziplin zwinge:

Das Erdgeschoss darf nichts mitbringen, was nicht aus dem Erdgeschoss selbst kommt. Keine fremden Werkzeuge. Keine Bibliotheken. Keine Frameworks. Nichts.

Das klingt erstmal albern. Programmierer lieben Werkzeuge. Es gibt für alles ein fertiges Paket – fürs Loggen, für die Datenbank, für HTTP, für Dependency Injection (frag nicht). Und in diesem einen Stockwerk darf ich davon gar nichts verwenden.

Warum? Drei Gründe, in einfach:

Erstens, weil Werkzeuge altern. Vor zehn Jahren war eine bestimmte Logging-Bibliothek der Standard. Heute ist sie veraltet. In OpenSim hängt dieses Ding aber überall drin – auch in der innersten Schicht. Sie auszutauschen ist ein Monatsprojekt. Wenn das Erdgeschoss frei von allem Werkzeug bleibt, kann ich oben drüber jedes Tool austauschen, ohne dass das Tragwerk wackelt.

Zweitens, weil Ausnahmen nie bei einer bleiben. Ich war in der Versuchung – versprochen. "Eine winzige Bibliothek nur, ist ja nicht wirklich ein Werkzeug, ist nur Klempner-Zeug." Sobald du die erste Ausnahme zulässt, kommt die zweite, dann die dritte. Nach drei Jahren hast du zwölf Ausnahmen, und niemand erinnert sich, warum die Regel mal existiert hat. Lieber Null als "Null-Komma-irgendwas".

Dritter Grund, der mich tatsächlich überzeugt hat: Die Tests werden absurd einfach. Wenn das Erdgeschoss von nichts abhängt, kann ich seine Logik testen, indem ich Werte reingebe und Werte rausbekomme. Keine Datenbank, keine Schein-Objekte, keine Setup-Akrobatik. Funktioniert, oder funktioniert nicht. Schwarz-Weiß.

Drei Sachen, die ich mir verboten habe

Ich habe ein paar weitere Regeln aufgestellt, die ich kurz übersetze:

"Das Wort Modul will ich nicht mehr sehen." OpenSim hat ein Plugin-System mit etwa fünfzig Modulen. Die kleben überall an der zentralen Welt-Klasse und fragen sich gegenseitig nach Funktionen – wie Mitarbeiter, die statt im Telefonbuch zu schauen jedes Mal durch alle Büros laufen und "Hat einer von euch zufällig…?" rufen. In akisim wird das durch normale Service-Aufrufe ersetzt. Das spart langfristig Hunderte von kleinen Verschachtelungen.

"Pro Aufgabe genau eine Lösung." OpenSim hat für viele Aufgaben drei bis fünf konkurrierende Implementierungen – historisch gewachsen, weil sich nie jemand getraut hat, die alten zu löschen. Ich lösche jetzt einfach. Der Endzustand ist klar: ein Weg, eine Implementierung. Wer eine Alternative will, kann forken – aber im Standard-akisim gibt's nur eine Tür pro Zimmer.

"Keine Plugins, keine Add-ons." Das alte System wollte erweiterbar sein wie Firefox. In der Praxis hat das eine Galerie aus halbgaren Halb-Projekten produziert, die alle drei Schichten kreuzen und keiner versteht. Wenn jemand was Neues bauen will, baut er's direkt in die Schichten – und schaltet es per Konfig an oder aus. Reicht.

Die Pointe: kein Big Bang

Das wichtigste Prinzip kommt zum Schluss, weil es alle anderen erst möglich macht:

Jeder Zwischenzustand muss laufen.

Ich darf nicht das alte Hotel sprengen, dann ein neues bauen, und hoffen, dass die Gäste so lange im Park warten. Die Renovierung läuft Zimmer für Zimmer. Wenn ich morgen aufhöre – egal in welchem Zustand – funktioniert das Hotel weiter.

Konkret heißt das: das alte OpenSim und das neue akisim laufen parallel im selben Programm. Ich verschiebe Funktionen Stück für Stück rüber. Beim Start sieht das alte System aus wie ein Hotel mit einem neuen Eingangs-Pavillon davor. Beim Ende sieht es aus wie ein neues Hotel mit einem stillgelegten Altbau, der irgendwann abgerissen werden kann – oder eben stehenbleibt, falls keiner ihn mehr betritt.

Niemand muss in einem Zelt schlafen. Das ist mir wichtig.

Was ich daraus gelernt habe

Drei Dinge, die ich in Software gelernt habe und die – glaube ich – auch außerhalb funktionieren:

1. Eine harte Regel ist einfacher zu halten als eine weiche. "Null Werkzeuge im Erdgeschoss" ist leichter durchzusetzen als "nur die wirklich wichtigen Werkzeuge im Erdgeschoss".
   
2. Wenn etwas dreißig Mal kopiert ist, ist nicht das Kopieren das Problem. Das Problem ist, dass das Original an der falschen Stelle liegt.
   
3. Renovierung schlägt Abriss. Auch wenn der Abriss verlockender aussieht, wenn man morgens reinkommt und die alten Tapeten anschaut.
   

Ob ich es schaffe, weiß ich noch nicht. Schätzung: drei bis sechs Monate für die heißen Phasen. Ich poste, was passiert.