Ich übernehme, analysiere und modernisiere — ohne dass Production stehen bleibt. Kein Rewrite wenn es nicht sein muss. Kein Subunternehmer. Dein Team weiß jederzeit, woran ich gerade arbeite.
Ich übernehme, analysiere und modernisiere — ohne dass Production stehen bleibt. Kein Rewrite wenn es nicht sein muss. Kein Subunternehmer. Dein Team weiß jederzeit, woran ich gerade arbeite.
Einmal war Neubau die einzige vernünftige Antwort. Einmal war er es nicht — 28 Jahre, kein Rewrite, kein Feature-Freeze. Den Unterschied erkennst du nur, wenn du den Code kennst.
Projekte über Jahre, nicht Sprints. Immer als Lead. Viele laufen noch, andere habe ich sauber übergeben. Konkrete Zahlen (Last, Nutzer, Transaktionen) sag ich dir gern im Gespräch — die stehen unter NDA.
Die meisten Codebases, die ich übernehme, hat vorher jemand anderes aufgegeben.
Das Ziel ist immer dasselbe: ein System, das morgen noch läuft — ohne dass heute alles stillsteht. Was läuft, lass ich laufen und räume nach und nach auf. Was nicht mehr passt, tausche ich Schritt für Schritt aus, im laufenden Betrieb, mit Tests. Das Werkzeug wähle ich nach dem Problem — nicht nach Gewohnheit.
Seit über 20 Jahren — Banking, Logistik, Retail, öffentlicher Sektor — kenne ich die typischen Muster: warum Legacy-Projekte scheitern, wie Codebases veralten, welche Entscheidungen sich rächen. Ich rede direkt mit deinem Team, stelle die Fragen, die intern niemand gestellt hat — und schreibe Code, der auch nach mir noch lesbar ist.
Wenn wir zusammenarbeiten: Ich frag erst, bevor ich was umbaue. Wenn ich was nicht weiß, sag ich das — statt zu raten. Und ich halte Termine ein, auch wenn die Antwort „nein“ ist.
Alles hier hab ich produktiv im Einsatz — meistens über ein Jahr. Die mit Punkt nutze ich gerade aktiv in einem laufenden Projekt.
Hier schreib ich auf, wo es bei Symfony-Migrationen, Laravel-Updates und PHP Legacy oder WP-Multisite-Übernahmen immer wieder hakt.
Wenn eine Laravel-App langsam wird, fällt der Verdacht fast immer auf die Datenbank oder den Server. Meistens liegt es an keinem von beidem, sondern an der Zahl der Abfragen und der Menge geladener Objekte. N+1, unnötiges Hydrieren, teure Accessors und fehlende Indizes, der Reihe nach, mit Vorher-Nachher und einem klaren Vorgehen.
Laravel-Upgrades sind mechanisch gut machbar. Der teure Fehler ist nicht die Migration selbst, sondern der Versuch, mehrere Major-Versionen auf einmal zu nehmen. Warum ein Major pro Schritt die einzige sichere Reihenfolge ist, warum die abandoned Packages der eigentliche Blocker sind, und ein Blick darauf, was pro Version typischerweise bricht.
Eine aktuelle Framework-Version ist kein Qualitätssiegel. Ein gewachsenes Laravel ohne Tests ist genauso Legacy wie prozeduraler Alt-PHP-Code, die Fassade täuscht nur besser. Was ich in den ersten Wochen einer Laravel-Übernahme anschaue, warum das Sicherheitsnetz vor allem anderen kommt, und ein Feature-Test, der das Ist-Verhalten festhält, bevor jemand refactort.
Drei Zeilen reichen: was läuft heute, was soll laufen, ab wann. Ich melde mich innerhalb von zwei Tagen — ehrlich, mit Ja oder Nein.
