PHP Praxis & Zukunft

Wie wirkt sich die Einführung neuer PHP-Versionen auf bestehende Projekte mit einer älteren Codebasis aus?

Stefan: Das hängt maßgeblich davon ab, wie aktuell die Infrastruktur und der Code des Projekts sind. Läuft das Projekt auf einer älteren PHP-Version oder einem veralteten Betriebssystem bzw. werden veraltete Bibliotheken verwendet, ist der Migrationsaufwand beim Upgrade auf eine aktuelle PHP-Version meist deutlich höher. Es können Inkompatibilitäten auftreten, veraltete Funktionen oder Syntax müssen angepasst und die Abhängigkeiten überprüft und gegebenenfalls aktualisiert werden.

Wenn der Code kontinuierlich an neue PHP-Versionen und andere Abhängigkeiten angepasst wurde, ist der Aufwand für ein Upgrade natürlich deutlich geringer und die Migration ist meist unproblematisch.

Sebastian: Ist die Lücke zwischen der aktuell verwendeten und der neuen PHP-Version klein, reduziert sich der Migrationsaufwand erheblich. Es müssen weniger veraltete Funktionen oder Syntaxänderungen berücksichtigt werden. Ein großer Versionssprung, beispielsweise von PHP 5 auf PHP 8, kann hingegen größere Anpassungen im Code und in den Abhängigkeiten erforderlich machen. In diesem Fall sind umfangreiche Tests notwendig.

Stefan: Projekte sollten sich am Release-Zyklus von PHP orientieren und beispielsweise im Sommer eines Jahres die im Herbst des Vorjahres erschienene PHP-Version installieren. So bleibt der Code aktuell, der Migrationsaufwand ist überschaubar und das Risiko von Inkompatibilitäten wird minimiert.

Welche Rolle spielt derzeit die asynchrone Programmierung in PHP-Projekten?

Stefan: PHP verarbeitet Requests seit jeher in einem jeweils eigenen Betriebssystemprozess. Dadurch sind die einzelnen Requests gut voneinander isoliert. Diese Isolation sorgt für Sicherheit und Stabilität, da Fehler oder Speicherlecks in einem Prozess die anderen nicht beeinflussen. Allerdings ist der Wechsel zwischen Prozessen mit einem gewissen Overhead verbunden, wodurch sich die Performance bei vielen gleichzeitigen Requests verschlechtert.

Ein Gegenentwurf zu diesem Ansatz ist die Asynchronität, wie sie beispielsweise mit Node.js populär geworden ist. Dabei wird bewusst auf Prozessisolation verzichtet, um einen höheren Durchsatz zu erreichen. Stattdessen wird versucht, möglichst wenig auf I/O zu warten, sondern stattdessen im laufenden Prozess weitere produktive Arbeit zu verrichten. Das erfordert allerdings non-blocking I/O, damit der Prozess nicht blockiert wird und deshalb die CPU direkt wieder freigibt.

Obwohl PHP grundsätzlich Asynchronität unterstützt, sind wichtige Erweiterungen wie mysqli weiterhin nicht non-blocking. Das bedeutet, dass Anwendungen, die in PHP entwickelt wurden, selbst dann nicht von den Performance-Vorteilen profitieren, wenn der Code ähnlich wie in Node.js gestaltet wird. Erst wenn zukünftig auch die relevanten Extensions non-blocking arbeiten, lässt sich dieser Ansatz sinnvoll verfolgen. Dann hat man allerdings das Problem, dass man im Falle eines Crashs nicht mehr rekonstruieren kann, in welchem Zustand sich die Anwendung genau befand, sprich welche Arbeit bereits ausgeführt wurde und welche noch nicht. Das wird bei Seiteneffekten wie dem Versand von E-Mails gerne mal zum Problem.

Welche Rolle spielt PHP in Kombination mit Microservices und welche aktuellen Entwicklungen gibt es hier?

Stefan: PHP eignet sich besonders gut für die Implementierung und Nutzung von Microservices, da HTTP-Anfragen sehr leichtgewichtig verarbeitet werden können.

Arne: Moderne Frameworks unterstützen diesen Ansatz, indem sie immer effizienter arbeiten und dafür sorgen, dass vor der Ausführung der eigentlichen Geschäftslogik möglichst wenig Framework-Code ausgeführt werden muss.

Stefan: In der Praxis beobachten wir häufig, dass Entwickler zwar Microservices mit PHP umsetzen, dabei aber auf dieselben Abstraktionsschichten zurückgreifen wie bei monolithischen Anwendungen. Dadurch wird das Potenzial von Microservices oft nicht optimal ausgeschöpft. Wir sehen, dass sich durch Cloud Computing und die zunehmende Verfügbarkeit spezialisierter Services ein klarer Trend zu kleineren, spezialisierteren Services zeigt.

Gibt es neue Frameworks oder Bibliotheken, die ihr besonders interessant findet?

Stefan: Es erscheinen regelmäßig spannende neue Frameworks und Bibliotheken, die wir uns mit großem Interesse anschauen. In der Beratung empfehlen wir dennoch meist gut erprobte und etablierte Software, um Risiken zu vermeiden.

Arne: Frameworks wie Symfony und Laravel sind bewährt, stabil und bieten ein hohes Maß an Sicherheit sowie eine große Community. Daher haben es neue Frameworks schwer, sich gegen diese etablierten Lösungen durchzusetzen.

Welche Design Patterns sind eurer Meinung nach besonders effektiv für die PHP-Entwicklung?

Stefan: Ich finde Design Patterns total wichtig, weil die die Kommunikation zwischen Entwicklern beschleunigen und vereinfachen können. Ich habe  kürzlich auf der International PHP Conference den Vortrag "Essential Design Pattern" gehalten. Die Folien dazu kann man sich übrigens unter the-fluent-developer.com ansehen. Die Patterns, die ich in diesem Vortrag vorgestellt habe, sind genau die, die nach meiner Meinung besonders wichtig für die PHP-Entwicklung sind.

Wie wichtig sind ereignisgesteuerte Architekturen für große PHP-Anwendungen und wie können sie am besten implementiert werden?

Stefan: Da die reale Welt ereignisbasiert ist, kann ich sie mit einer ereignisgesteuerten Architektur sehr gut modellieren.

Sebastian: Die Umsetzung solcher Prozesse erfolgt durch geradlinigen, leicht nachvollziehbaren Code. Dieser lässt sich nicht nur einfach implementieren, sondern auch hervorragend testen.

Stefan: Die Einführung einer ereignisgesteuerten Architektur erweist sich zudem als weniger kompliziert als zunächst angenommen. Wir bieten daher gezielte Schulungen an, um Teams bei der Umsetzung und Integration dieser Konzepte in bestehende oder neue PHP-Anwendungen zu unterstützen.

Welche Prinzipien empfehlt ihr, um Wartbarkeit und Testbarkeit über den gesamten Entwicklungszyklus sicherzustellen?

Sebastian: Ohne automatisierte Tests ist das sehr schwierig.

Stefan: Wir wollen ja nicht Endbenutzer und Benutzerinnen testen lassen.

Sebastian: Die Entwicklung sollte schrittweise und in kurzen Zyklen erfolgen, sodass Änderungen schnell und übersichtlich integriert und getestet werden können. So ist der Zustand der Software kontinuierlich überprüfbar und Fehler werden frühzeitig erkannt.

Arne: Ein weiteres wichtiges Prinzip ist die regelmäßige, automatisierte Überprüfung des aktuellen Zustands der Software. So kann sichergestellt werden, dass neue Änderungen keine unerwünschten Nebeneffekte haben. Wir bieten Schulungen an, die hierfür die Grundlage bilden.

Sebastian: Zusätzlich sollten Abhängigkeiten wie PHP kontinuierlich, so wie Stefan es vorhin vorgeschlagen hat, aktualisiert werden, um die Software auf dem aktuellen Stand zu halten.

Stefan: Ein zentraler Erfolgsfaktor ist außerdem, dass das gesamte Team einen gemeinsamen Qualitätsanspruch definiert, der von allen Beteiligten, auch außerhalb der Entwicklung, getragen wird. Dadurch wird Qualität zu einem verbindlichen Ziel, das sich im gesamten Entwicklungsprozess durchsetzen lässt und die Wartbarkeit sowie Testbarkeit nachhaltig sicherstellt.

Welche Werkzeuge oder Ansätze gibt es, um Code modern und zukunftssicher zu machen?

Stefan: Arne und ich sind ja gesetzlich verpflichtet, jetzt hier PHPUnit zu nennen (lacht).

Sebastian: Ohne Tests gibt es eben keine Absicherung dafür, dass zukünftige Änderungen nicht unbemerkt Fehler verursachen. Und ja, da muss ich wohl PHPUnit als Test Framework nennen.

Werkzeuge wie PHPStan oder Psalm analysieren den Code ohne ihn auszuführen und helfen dabei, Programmierfehler wie beispielsweise Typinkonsistenzen frühzeitig zu erkennen.

Arne: Mit PHP-CS-Fixer oder PHP_CodeSniffer lässt sich sicherstellen, dass der Code einheitlich formatiert ist. Das erleichtert die Zusammenarbeit im Team und macht den Code für andere Entwickler:innen besser verständlich. Rector ist ein Werkzeug, um bestehenden Code automatisiert zu modernisieren. Es kann beispielsweise alte Syntax durch neue Sprachfeatures ersetzen oder Code an aktuelle Best Practices oder gar neue Framework-Versionen anpassen. So bleibt der Code auch bei neuen PHP-Versionen kompatibel und profitiert von Verbesserungen der Sprache.

Stefan: Wir sind überzeugt, dass die genannten Open Source-Werkzeuge eine ebenso gute, wenn nicht sogar bessere Wahl als kommerzielle Produkte darstellen.

Jenseits von Werkzeugen möchte ich aber vor allem Best Practices empfehlen: Clean Code und die SOLID-Prinzipien sorgen dafür, dass Software klar strukturiert, verständlich und flexibel bleibt. Dadurch wird der Code leichter wartbar, anpassbar und kann auch in Zukunft effizient weiterentwickelt werden. So bleibt die Codebasis modern und zukunftssicher.

Durch die Integration von KI in unsere Entwicklungsumgebungen erweitert sich unser Werkzeugkasten derzeit erheblich. So können wir beispielsweise die IDE darum bitten, uns den aktuell angezeigten Code zu erklären, zu optimieren oder zu modernisieren. Diese neuen Möglichkeiten sind äußerst spannend, allerdings bleibt abzuwarten, inwieweit sie sich im praktischen Einsatz tatsächlich bewähren werden.

Wie können Entwickler technische Schulden in Legacy-Projekten gezielt und effizient abbauen?

Arne: Zunächst gilt es, ungenutzten Code systematisch zu identifizieren und zu entfernen. Werkzeuge können helfen, Code zu finden, der nicht mehr ausgeführt wird, während Gespräche mit Stakeholdern das "Sunsetting" von Features ermöglichen, die nicht mehr benötigt werden. Dies reduziert nicht nur Komplexität, sondern schafft auch mentalen Freiraum für das Team.

Stefan: Der Abbau technischer Schulden gelingt durch kleine, überschaubare Änderungen. Kritische Hotspots können durch Logfiles identifiziert werden, um den Code beispielsweise für ein Upgrade auf eine neue PHP- oder Framework-Version vorzubereiten. Schaut auf die Deprecations und die Warnings und versucht die wegbzubekommen. Einzelne Teile der Anwendung lassen sich schrittweise durch neu entwickelte, moderne Komponenten ablösen.

Sebastian: Automatisierte Tests sichern dabei Stabilität und minimieren Risiken durch Regressionen.

Stefan: Durch diese Kombination aus gezielter Bereinigung, schrittweiser Modernisierung und robusten Prozessen entsteht eine nachhaltig wartbare Codebasis. Die Wartungskosten sinken, die Systemstabilität steigt, und Teams gewinnen Zeit, um sich auf neue Anforderungen zu konzentrieren – ein klarer Return on Investment für jedes Unternehmen.

Wie geht ihr im Rahmen einer Modernisierungsstrategie mit veralteten PHP-Frameworks und -Bibliotheken um?

Stefan: Sollte es für das eingesetzte Framework einen offiziellen Migrationspfad geben, empfiehlt es sich, diesen als Grundlage für die Modernisierung zu nutzen.

Sebastian: Spezialisierte Werkzeuge wie Rector und automatisierte Refactorings sowie KI-gestützte Funktionen in modernen Entwicklungsumgebungen helfen dabei, wiederkehrende Anpassungen effizient und fehlerarm durchzuführen.

Arne: Bei Bibliotheken sollte immer zuerst geprüft werden, ob eine bestimmte Bibliothek weiterhin benötigt wird. Vielleicht bietet eine neuere PHP-Version ihre Funktionalität direkt in der Sprache an, oder die Funktionalität an sich wird schon gar nicht mehr gebraucht, die Existenz der Bibliothek aber einfach vergessen. Dann sollte sie entfernt werden, um die Codebasis zu verschlanken. Ist die Bibliothek nach wie vor relevant, gilt es zu bewerten, ob eine Aktualisierung möglich ist.

Stefan: Falls ein Wechsel auf eine alternative Bibliothek erforderlich wird, empfiehlt es sich, bei diesem Wechsel auf Branch-by-Abstraction zu setzen. Insbesondere dann, wenn bislang noch keine konsequente Isolation der Abhängigkeiten durch Dependency Inversion umgesetzt wurde.

Welche Vorgehensweisen oder Frameworks sind für eine schrittweise Modernisierung besonders hilfreich?

Stefan: Es ist wichtig, vorausschauend zu handeln und notwendige Anpassungen frühzeitig zu erkennen. Indem wir geplante Veränderungen rechtzeitig in unsere Entwicklungsprozesse integrieren, schaffen wir die Voraussetzung, diese in einem angemessenen Zeitrahmen und ohne unnötigen Zeitdruck umsetzen zu können. So lassen sich größere Risiken und aufwendige Nachbesserungen vermeiden.

Sebastian: Um die Auswirkungen von Änderungen zuverlässig einschätzen zu können, führen wir die bestehenden Tests des Projekts zunächst in einer separaten Umgebung mit der neuen PHP- oder Framework-Version aus. So stellen wir sicher, dass mögliche Probleme frühzeitig erkannt werden, ohne das laufende Produktionssystem zu beeinträchtigen.

Sollte das Projekt über keine ausreichende Testabdeckung verfügen, können sogenannte Characterization Tests als temporäre Absicherung eingesetzt werden. Diese Tests helfen dabei, das aktuelle Verhalten der Software in verschiedenen Umgebungen zu vergleichen und so sicherzustellen, dass durch die vorgenommenen Änderungen keine unerwünschten Nebenwirkungen entstehen.

Wie unterscheidet sich die PHP-Entwicklung in Cloud-Umgebungen von klassischen Server-Umgebungen?

Arne: Auch in klassischen Serverumgebungen lassen sich Container problemlos betreiben, und umgekehrt kann Software in der Cloud weiterhin ganz traditionell in einer virtuellen Maschine installiert werden. Der entscheidende Vorteil der Containerisierung liegt jedoch darin, dass Container deutlich ressourcenschonender und flexibler als virtuelle Maschinen sind. Denn für sie muß keine Hardware emuliert werden und es wird im Container kein vollständiges Betriebssysteme benötigt. Dadurch kann die Anwendung schneller starten sowie effizienter skaliert werden. Deshalb setzt sich der Einsatz von Containern zunehmend durch, unabhängig davon, ob sie auf Bare Metal, in VMs oder in der Cloud laufen.

Stefan: Software, die in der Cloud betrieben werden soll, sollte stärker modularisiert werden, um die Flexibilität und Skalierbarkeit der Cloud optimal zu nutzen. Ein modularer Aufbau erleichtert es, einzelne Komponenten unabhängig voneinander zu entwickeln, zu testen und bei Bedarf auszutauschen oder zu erweitern. In der Cloud stehen zudem zahlreiche spezialisierte Services zur Verfügung, etwa für Datenbanken oder Message Queues, die gezielt eingebunden werden können. Das beschleunigt die Entwicklung und vereinfacht die Wartung, kann aber im Gegenzug die operativen Kosten erhöhen.

Der Übergang zur Containerisierung kann sich für das Team anfangs als sehr herausfordernd und mitunter schmerzhaft anfühlen, da viele technische und organisatorische Probleme bereits zu Beginn des Projekts sichtbar werden. Schwierigkeiten, die beim Betrieb der Software in Containern auftreten, müssen früh adressiert werden, was den Einstieg zwar aufwendiger macht, aber langfristig für mehr Stabilität und Transparenz sorgt.

Welche PHP-spezifischen Best Practices empfehlt ihr für Continuous Integration und Deployment?

Sebastian: Die Industriestandards für CI/CD sind grundsätzlich unabhängig von der eingesetzten Programmiersprache. Die Prinzipien und Best Practices, wie automatisierte Builds, kontinuierliche Tests und wiederholbare Deployments, gelten für alle modernen Softwareprojekte gleichermaßen.

Arne: Um sicherzustellen, dass der Softwarestand eines Projekts jederzeit reproduzierbar ist, sollten die Dateien composer.lock und composer.json in die Versionsverwaltung eingecheckt werden. In der composer.json muss die benötigte PHP-Version ebenso konfiguriert und damit dokumentiert werden wie die benötigten PHP-Erweiterungen.

Stefan: Mit PIE (PHP Installer for Extensions) arbeitet das PHP-Projekt aktuell an einer Lösung, die bisherige Lücke beim Management von PHP-Extensions zu schließen. Während Composer Abhängigkeiten auf Extensions zwar deklarieren, aber nicht selbst installieren kann, ermöglicht PIE erstmals einen modernen, Composer-ähnlichen Workflow für die Installation und Verwaltung von PHP-Extensions.

Welche PHP-spezifischen Herausforderungen ergeben sich beim Einsatz von Kubernetes?

Stefan: Mit Kubernetes werden Container orchestriert, beispielsweise werden Container neu gestartet, deren Prozess gecrasht ist.

Arne: Container sind darauf ausgelegt, genau einen laufenden Prozess zu kapseln, der während der gesamten Lebensdauer des Containers aktiv bleibt. Wird dieser Hauptprozess beendet, wird auch der Container gestoppt und entfernt.

Stefan: Da der PHP-Interpreter nicht als dauerhaft laufender Prozess konzipiert ist, eignet er sich nicht als Hauptprozess für einen Container. Wie auch bei Betriebskonzepten ohne Container liegt die Lösung in der Verwendung des FastCGI Process Managers (PHP-FPM): dieser kann als langlebiger Prozess in einem Container ausgeführt werden und delegiert die Ausführung von PHP-Code für ankommende Requests an den PHP-Interpreter, der die Requests in separaten Prozessen verarbeitet.

Vor diesem Hintergrund wird deutlich, weshalb der Betrieb einer PHP-Anwendung in einem Container unter Kubernetes etwas andere Herausforderungen hat als beispielsweise bei einer Node.js-Anwendung, die ihren eigenen dauerhaft laufenden Serverprozess mitbringt.

Welche Rolle spielt Infrastructure as Code (IaC) bei PHP-Projekten in DevOps-Umgebungen?

Arne: Infrastructure as Code (IaC) ist unabhängig von der verwendeten Programmiersprache und spielt eine zentrale Rolle bei der Automatisierung von Installation und Konfiguration von Entwicklungs- und Betriebsumgebung. Das Ziel ist dabei, die für die Ausführung der Software benötigte Umgebung jederzeit reproduzierbar und zuverlässig aufbauen zu können.

Stefan: Auf einem klassischen Server wird die Skalierung einer PHP-Anwendung zunächst durch die Anpassung der PHP-FPM-Konfiguration erreicht, etwa durch das Erhöhen der Anzahl der Worker-Prozesse. Wenn die Anforderungen weiter steigen, erfolgt die horizontale Skalierung, indem zusätzliche Server mit weiteren PHP-FPM-Instanzen bereitgestellt werden. Spätestens an diesem Punkt wird Infrastructure as Code (IaC) unverzichtbar, da die manuelle Verwaltung und Konfiguration der Infrastruktur zu aufwendig und fehleranfällig wird.