Aki's Vibes

[Akira]

Das Telefonbuch, das keiner mehr braucht

Oder: wie ich gelernt habe, dass Werkzeug das man selbst suchen muss, kein gutes Werkzeug ist.



Stage 4 ist durch. Die Telefonanlage steht, dreizehn Leitungen übertragen sauber. Wer die letzten Posts gelesen hat, hat ein Hotel gesehen, das immer aufgeräumter wirkt.

Heute erkläre ich, was hinter dem Aufräumen steckt. Nicht was aufgeräumt wurde — sondern wie das Hotel sicherstellt, dass jede Mitarbeiterin weiss, womit sie arbeitet. Das klingt nach einer internen Frage. Es ist eine der wichtigsten Entscheidungen des ganzen Bauprojekts.

Das alte Telefonbuch

Im alten Hotel gab es ein Telefonbuch. Dick. Schwer. Jede Mitarbeiterin, die irgendetwas brauchte, schlug nach. „Wer ist hier zuständig für Einreisegenehmigungen? Wer hat den Schlüssel zur Hausordnung? Wer führt die Gästeliste?"

Das Telefonbuch kannte jeden. Theoretisch.

Das Problem: wenn jemand nicht drin stand — stand er nicht drin. Kein Eintrag. Kein Hinweis. Die Mitarbeiterin rief an, niemand nahm ab, und das Hotel brach zusammen. Kein Warnlicht vorher. Kein Protokoll. Nur — Stille, und dann Absturz.

Im Quellcode heisst das Telefonbuch `scene.RequestModuleInterface<T>()`. Jedes Modul, das etwas brauchte, rief diese Zeile auf. Antwort: entweder ein gültiger Dienst — oder `null`. Und `null` bedeutet Absturz. Nicht beim Hoteleröffnungs-Check. Nicht im Test. Sondern wenn die erste Gästin am Tresen steht.

Aber das war nur das offensichtliche Problem. Das weniger offensichtliche: Das Telefonbuch versteckte, was jeder wirklich brauchte. Wer eine neue Abteilung ins Hotel einführen wollte, musste erst herausfinden, was sie alles anrufen würde. Das stand nirgendwo aufgeschrieben. Es war über Dutzende Methodenrümpfe verteilt, entdeckbar nur durch vollständiges Lesen — oder durch Warten auf den ersten Absturz.

Was man nicht sieht, kann man nicht prüfen. Und was man nicht prüfen kann, bricht irgendwann.

Die neue Hausordnung: Werkzeug beim Betreten

Das neue System kennt ihr aus den letzten Posts. Wer im Hotel anfängt, schreibt beim Einstellungsgespräch auf was sie braucht. Nicht wenn sie's zum ersten Mal braucht. Vorher. Beim Antritt.

Die Hausmeisterin liest die Liste, legt alles bereit, drückt es beim Schichtbeginn in die Hand. Das nennt sich Constructor Injection (Abhängigkeiten werden beim Erstellen einer Klasse übergeben, nicht irgendwann nachher gesucht). Der Unterschied zum Telefonbuch: Die Anforderungsliste ist offen, sichtbar, im Code lesbar. Keine Suche. Kein Nachschlagen.

Und: beim Hoteleröffnungs-Check — also beim Start des Programms — prüft die Hausmeisterin ob wirklich alles da ist. Wenn nicht, startet das Hotel gar nicht erst. Kein Absturz beim ersten Gast. Kein Null-Fehler um 3 Uhr nachts. Fehler beim Start, nicht im Betrieb.

Das ist der Kern des ganzen Umbaus. Nicht nur hübsche Architektur-Schichten. Sondern: Fehler früh sehen, nicht spät.

Ein Hotel, das beim Eröffnungs-Check scheitert, hatte ein Problem. Ein Hotel, das beim Gast-Check scheitert, hat ein Debakel.

Was wir ausserdem angeschaut haben

Bevor ich mich festgelegt habe, habe ich vier andere Varianten ernsthaft betrachtet. Keine davon kam für akisim in Frage — aber das Warum ist wichtig.

Alles von Hand

Man könnte auf das Liefersystem ganz verzichten. Die Hausmeisterin baut alles selbst zusammen und trägt es von Hand rüber:

`var repo = new EstateRepository(connectionString);`
`var service = new EstateService(new EstateDomain(repo));`

Kein Framework. Volle Sicht auf jeden Schritt.

Für ein kleines Hotel mit drei Abteilungen: vernünftig. Für ein Hotel mit einunddreissig Diensten, von denen manche von anderen abhängen, die von anderen abhängen — wird das zur Vollzeitbeschäftigung. Und bei jeder Änderung muss die Hausmeisterin den ganzen Lieferpfad von Hand neu berechnen.

Spezial-Liefersysteme

Es gibt Liefersysteme mit mehr Extras — Autofac, Castle Windsor. Die können zum Beispiel dieselbe Aufgabe von zwei verschiedenen Zuständigen parallel erledigen lassen. Oder eine Mitarbeiterin vorschalten, die erst etwas verändert, bevor sie weiterleitet (das nennt sich Decorator-Pattern, aber das sprengt heute den Rahmen).

Ich war kurz versucht. Ehrlich. Dann habe ich mir die Frage gestellt: Welches dieser Features brauche ich heute? Die Antwort war: keines. Jede Aufgabe im Hotel hat genau eine Zuständige. Keine Auswahl, keine Parallelität, keine Deko-Schicht.

Wer Werkzeug kauft, das er nicht braucht, zahlt die Wartungskosten trotzdem.

Das schwarze Brett

Es gibt einen Ansatz, bei dem Dienste nicht direkt miteinander reden. Jemand schreibt eine Anfrage ans schwarze Brett — „Wer kennt Estate ID 42?" — und irgendwer antwortet. Keine direkte Verbindung zwischen Frager und Antworterin.

Das nennt sich Mediator-Muster. Sinnvoll, wenn sehr viele Abteilungen mit wechselnden Zuständigkeiten kommunizieren. Für akisim: theoretisch interessant für einzelne Sonderfälle, aber als Basis-Kommunikation Umweg ohne Gewinn. Wenn ich weiss, wer die Antwort geben kann, will ich direkt anrufen.

Die Fremdzuliefererin

Das ist die interessanteste Option — und die einzige, die ich auf meiner persönlichen Reserveliste halte.

Das normale Liefersystem kennt alle Zuliefererinnen beim Bau. Sie sind eingebaut, fest, Teil des Plans. Was aber, wenn jemand von aussen kommt — eine Currency-Systemanbieterin, eine eigene Physik-Engine — und das Hotel diese erst zur Laufzeit einbinden will? Ohne sie vorher zu kennen?

.NET kann das. AssemblyLoadContext — das Hotel öffnet ein frisches Paket, lädt die darin enthaltene Zuliefererin dynamisch, und nutzt ihren Dienst. Wie ein unangekündigter Lieferant, dessen Paket man trotzdem entgegennehmen kann.

Heute ist die Hintertür zu. Das Hotel ist kein Plugin-Host. Alle Zuliefererinnen sind eingebaut — das ist eine bewusste Entscheidung. Aber: wenn externe Plugins eines Tages anklopfen, dann ist das der richtige Weg. Nicht das alte Mono.Addins-System aus der Hotelvergangenheit. Sondern das.

Wer die Hintertür kennt, muss sie nicht heute aufmachen.

Warum wir beim Standard geblieben sind

Die Wahl fiel auf das eingebaute Liefersystem von Microsoft — Microsoft.Extensions.DependencyInjection. Kein Spezial-System, kein Lernaufwand, kein Framework, das nicht alle kennen.

Der Grund ist simpel: Es reicht. Das Hotel hat einunddreissig Dienste, alle mit genau einer Zuständigen, alle mit klaren Abhängigkeiten. Das Standard-System verwaltet das problemlos. Wer neu in das Bauprojekt schaut, findet dieselbe Hausmeisterin wie in tausend anderen .NET-Hotels auch — kein Einlesen in eigene Konventionen nötig.

Es gibt einen zweiten Grund, den ich selten so formuliert höre: Wer das Standard-System nutzt, profitiert davon, dass alle Bugs darin schon gefunden wurden. Spezial-Systeme haben eigene Bugs. Eigene Edge-Cases. Die findet man selbst — immer zur falschen Zeit.

Langweilig ist oft ein Kompliment.

Was als nächstes kommt: Gäste-WLAN und Sprechanlage

Das Backoffice ist aufgeräumt. Die Telefonanlage steht. Die Schubladen sind sortiert.

Jetzt kommen die Dinge, die die Gästin direkt spürt.

Das Gäste-WLAN ist der Kanal, über den die Brille der Gästin — die Viewer-Software zuhause auf ihrem Rechner — mit dem Hotel redet. Beim Check-in bekommt jede Gästin eine persönliche Servicemappe: eine Liste von Direktnummern zu verschiedenen Hotel-Diensten. Mesh-Upload, Inventar-Abfrage, Teleport-Anfragen. Jede Nummer in der Mappe ist ein sogenanntes Capability — eine Funktion, die das Hotel für genau diese Gästin bereithält. Das ist kein Smalltalk. Das ist das strukturierte Einlass-System des Hotels.

Dazu kommt die Sprechanlage. Eine eigene, schnelle Direktleitung zwischen jedem Zimmer und der Rezeption — nicht über das WLAN, sondern ein separater Kanal. Alles, was in Echtzeit passiert, läuft darüber: jede Bewegung im Raum, jeder Schritt, jedes gesprochene Wort. Die Gästin geht zwei Meter nach links — die Sprechanlage meldet das der Rezeption in Millisekunden. Fachlich: LLUDP, das direkte UDP-Protokoll, das Linden Lab damals für Second Life entwickelt hat.

Beide — Gäste-WLAN und Sprechanlage — sitzen im zweiten Stock. Im Adapter-Stockwerk, dem Stockwerk, das zwischen Hotel-Innenleben und Aussenwelt übersetzt.

Das ist das Kapitel, das jetzt kommt.

Was das Hotel nach innen geordnet hat, merkt die Gästin nicht. Was es nach aussen übersetzt, merkt sie beim ersten Schritt.

Was ich daraus gelernt habe

1. Sichtbarkeit ist Sicherheit. Das grösste Problem am alten Telefonbuch war nicht dass es ab und zu falsch lag. Es war dass man es aufschlagen musste, um zu sehen, was drin steht — und dass es kein Aufschlagen gab, bevor es knallte. Im neuen System steht alles vorne auf der Anforderungsliste. Unsichtbare Abhängigkeiten sind versteckte Risiken. Sichtbare Abhängigkeiten sind prüfbare Zusagen.
   
2. Standard ist unterschätzt. Ich war in der Versuchung, das Spezial-Liefersystem zu nehmen — nicht weil ich es gebraucht hätte, sondern weil es mehr konnte. Das ist eine schlechte Begründung. Fähigkeiten, die man nicht braucht, sind Wartungskosten die man nicht wollte.
   
3. Reserveoptionen kennen, ohne sie einzubauen. Das Plugin-Lade-System steht auf der Liste, ist aber nicht im Hotel. Das ist kein Widerspruch — das ist der Plan. Architektur bedeutet auch, den Weg zu kennen, der noch nicht gegangen wird.
   

Gäste-WLAN und Sprechanlage kommen als nächstes. Ich poste, was passiert.