Viele Firmen-Anwendungen sind nie als grosses Projekt gestartet: ein Bestellformular, dann ein Kundenbereich, dann eine Schnittstelle zum ERP. Zwanzig Jahre später ist daraus ein geschäftskritisches System geworden, gebaut von einer Person, ohne Framework, ohne Tests, auf einem Server, den niemand mehr anfassen will.
Wann ist eine Eigenbau-Übernahme typisch?
- Der Entwickler, der die Anwendung über Jahre gebaut hat, geht in Pension oder ist nicht mehr erreichbar.
- Die Anwendung läuft auf PHP 5 oder 7, und der Hoster stellt diese Versionen ab.
- Jede Änderung ist riskant, weil niemand weiss, was sie noch beeinflusst.
Worauf ich bei Eigenbauten zuerst schaue
- Einstiegspunkte: Welche Skripte werden direkt aufgerufen, welche per Cronjob, welche per Schnittstelle?
- Datenbank: Schema, Beziehungen, gespeicherte Prozeduren und die Art der Abfragen. Werden Eingaben sauber maskiert oder direkt in SQL eingesetzt?
- PHP-Kompatibilität: Entfernte Funktionen und veraltete Konstrukte, geprüft mit PHPCompatibility.
- Abhängigkeiten: Eingebundene Bibliotheken, oft als kopierte Dateien statt über Composer.
- Betrieb: Server, Konfiguration, Zugangsdaten im Code, Backups.
Absichern, dokumentieren, dann modernisieren
Bei Eigenbauten beginne ich mit einer lauffähigen Kopie auf einer Testumgebung und Tests für die kritischen Abläufe. Danach folgt das PHP-Upgrade, Schritt für Schritt. Soll die Anwendung langfristig auf ein Framework, überführe ich sie Bereich für Bereich nach dem Strangler-Fig-Prinzip: Das Neue wächst um das Alte herum, bis das Alte abgeschaltet werden kann.
Quellen
- [1]Migrating from PHP 5.6.x to PHP 7.0.x, Backward incompatible changes · php.net
- [2]Migrating from PHP 7.4.x to PHP 8.0.x, Backward incompatible changes · php.net
- [3]PHPCompatibility · GitHub
- [4]Rector · Rector
- [5]Strangler Fig Application · Martin Fowler