CakePHP ist das Framework, mit dem wir Systeme bauen, die über Jahre laufen. Nicht weil es modern ist, sondern weil es die Kontrolle über Datenmodell, Routing, Authentifizierung und Deployment an einer Stelle lässt. Wer den Code schreibt, kann ihn auch noch in drei Jahren ändern, ohne die Hälfte neu zu bauen.
Die Arbeit beginnt nicht mit dem ersten Controller. Sie beginnt mit der Frage, welche Daten wirklich zusammengehören, welche Prozesse nicht zerbrochen werden dürfen und wo die Grenze zwischen eigener Logik und Fremdsystemen liegt. Erst dann entsteht Code.
Architektur vor Code
Bevor Zeilen entstehen, wird das Datenmodell festgelegt. Welche Entitäten existieren, welche Beziehungen wirklich nötig sind und welche Prozesse nicht über mehrere Systeme verteilt werden dürfen. CakePHP 5 gibt die Werkzeuge dafür: Table Classes, Behaviors, Middleware und eine klare Request-Response-Kette. Wir nutzen sie, statt sie zu umgehen.
Plugins werden nur gebaut, wenn die Logik wiederverwendbar sein muss. APIs entstehen dort, wo Fremdsysteme angebunden werden müssen, nicht als Selbstzweck. Internationalisierung wird von Anfang an mitgedacht, wenn mehrere Sprachen oder Währungen relevant sind.
- Datenmodell und Migrations als Grundlage
- Middleware für Authentifizierung, Logging und Querschnittslogik
- RESTful Schnittstellen nur dort, wo sie gebraucht werden
- Dokumentation im Code und in der Architekturentscheidung
Bestehende Systeme verstehen, bevor sie geändert werden
Viele CakePHP-Applikationen sind über Jahre gewachsen. Der ursprüngliche Entwickler ist nicht mehr erreichbar, die Dokumentation fehlt oder stimmt nicht mehr mit dem Code überein. Bevor etwas geändert wird, wird der tatsächliche Zustand erfasst: Datenmodell, kritische Pfade, externe Abhängigkeiten und Stellen, an denen Logik in Views oder Controllern steckt, die dort nicht hingehört.
Erst danach wird entschieden, was migriert, was neu gebaut und was bewusst belassen wird. Eine vollständige Migration auf CakePHP 5 ist nur dann sinnvoll, wenn der Nutzen die Kosten rechtfertigt. Manchmal ist eine gezielte Stabilisierung der bessere Weg.
- Bestandsaufnahme von Datenmodell und kritischen Pfaden
- Code-Review mit Fokus auf Wartbarkeit und Risiken
- Gezielte Migration oder Stabilisierung statt pauschaler Neuaufbau
- Übergabe nur, wenn der Kunde den Code selbst weiterführen will
Der Entwickler bleibt verfügbar
Systeme, die jahrelang laufen sollen, scheitern selten an der ersten Version. Sie scheitern, wenn Änderungen teuer werden, weil niemand mehr den Code kennt oder die Architektur nicht mehr zur Realität passt. Deshalb bleibt die Verantwortung bei der Person, die das System gebaut hat. Änderungen werden dort vorgenommen, wo sie hingehören, nicht als Workaround in der Oberfläche.
Updates, Sicherheits-Patches und kleinere Erweiterungen bleiben planbar. Größere Änderungen werden vorher besprochen, weil sie die Architektur betreffen können. Der Kunde spricht mit der Person, die den Code geschrieben hat, nicht mit einer Eskalationskette.
- Direkte Ansprechbarkeit ohne Übergabe an Dritte
- Änderungen im Kontext der ursprünglichen Architektur
- Sicherheits-Updates und CakePHP-Releases nach Prüfung
- Dokumentation der Entscheidungen, nicht nur des Codes