Software-Entwicklung ist keine Momentaufnahme, sondern eine ständige Evolution. Wer lange an einem Projekt arbeitet, begegnet zwangsläufig seinem früheren Ich – und schüttelt oft den Kopf über den Code von damals. Doch statt diese "Altlasten" zu verstecken, gehe ich offen damit um. Denn Legacy Code ist auch ein Zeichen dafür, dass ein System lebt, wächst, Geld verdient und neue Chancen mit sich bringt.

Konfrontation mit dem früheren Ich

Ich arbeite seit vielen Jahren am Code von Vionity. Und jeder Dev kennt das: Man schaut in seinen zwei Monate alten Code und denkt sich: "Wer zum Teufel hat das geschrieben? Und vor allem warum?"

Rewrites über Rewrites. Das ist okay und ein Teil des Prozesses, genau wie Side-Projects. Nur so kann man lernen! Viel schlimmer ist es, wenn man die Probleme, die durch schlechten Code auftreten, weg ignoriert oder seine Architektur-Entscheidungen von 2015 nicht doch hinterfragt und künftig besser macht. Das tu ich in jedem Fall!

Vionity ist anfänglich für wenige Kunden mit ein paar Nodes geplant worden. Heute sind es hunderte Server und dutzende Services, die alle miteinander kommunizieren müssen. Ich gebe zu: Manche Architektur-Entscheidungen von damals waren nicht optimal für diese Skalierung. Aber hey, immerhin war das Design robust genug, dass ich heute einfach eine weitere Vionity-Instanz in den Load-Balancer Pool werfen kann, wenn es mal eng wird!

Der Vionity-Hybrid: WHMCS als Motor, Microservices als Turbo

Man muss dazu wissen: Vionity ist im Kern ein WHMCS Wrapper – und WHMCS ist bekanntermaßen speziell. Es hat zwar ein relativ durchdachtes Datenbankdesign, von dem ich anfänglich viel abkupfern konnte, aber bei einigem muss ich reingrätschen; erst recht, wenn der Gesetzgeber wieder auf neue Ideen kommt.

Unsere Strategie ist Transformation: Nach und nach werden die Engines von WHMCS abgeschaltet und von eigenen Micro-Services ersetzt, die in der Legacy-Datenbank wie gewünscht weitermutieren. Von der alten Basis ist heute für den Kunden nichts mehr zu sehen. Von der Verwaltung vom VPS, bis zum Dedicated Server, über die Domain, seine Kontakte und den DNS, den Transaktionen - alles läuft über Vionity. Die einzig öffentlich sichtbare WHMCS-Stelle ist die generierte Rechnung. So heben wir uns von anderen Hostern ab, ohne jemals die Datenbasis zu verlieren!

Natürlich führt das dazu, dass Vionity architektonisch ein Hybrid ist. Da gibt es Bereiche von 2019, die seitdem nie wieder angefasst wurden, weil sie einfach stabil laufen. Da heißt eine Methode dann eben historisch bedingt vionity_login() statt meiner heutigen Convention vionityLogin().

Mein heutiger Standard: TDD, Domains & Container-Magic

Doch mein heutiger Anspruch an neuen Code ist ein ganz anderer. Ich entwickle strikt App- und Domain-basiert und setze auf Test Driven Development (TDD), um Regressionen sofort zu erkennen. Business-Logik landet nicht mehr wild im Code, sondern wird sauber in Services gekapselt, ohne dabei Eloquent unnötig zu ersetzen.

Wir nutzen Filament für das Backend und Spatie Laravel-Data für echte Typsicherheit. Wo es nötig ist, spielt der Laravel Container seine Stärken aus: Über Contracts laden wir modulares Verhalten, je nachdem, welches Produkt im Webinterface gerade gefordert ist. Auch auf Datenbank-Ebene sorge ich heute für klare Verhältnisse durch Multi-Database Setups, um eine saubere Separation of Logic zu gewährleisten und große Stats-Tabellen lasttechnisch vom Core zu trennen.

Risk Management: Wenn der Hotfix wichtiger ist als das Lehrbuch

Prepaid-Hoster ist mittlerweile an einem Punkt, wo es finanziell recht schnell weh tun kann, wenn das gesamte Webinterface ausfällt. Risk-Management ist daher Teil meiner Jobbeschreibung.

Man muss als Architekt abwägen: Schreibe ich den perfekt gekapselten Code nach Lehrbuch, oder muss ich einen Hotfix deployen, weil ein spezifischer CPU-Typ gerade in allen Systemen Stress macht? Manchmal hat man nicht die Zeit, dieses Pflaster sofort in produktionsreifen High-End-Code zu überführen. Wichtig ist nur, dass man den Unterschied kennt und die technischen Schulden im Blick behält.

Next Level: Die PPH Cloud

All diese Erfahrung – der Umgang mit Legacy, die Skalierung und die modernen Architektur-Patterns – nehme ich mit in das nächste große Projekt: Die PPH Cloud (pph-cloud.com). Das wird eine zweite VPS Plattform, in der ich all diese Learnings bündle. Dort ballern wir eine Software raus, die ein echtes Erdbeben in der IT erzeugen könnte! (Man darf ja träumen).