Symfony seit 2008 im Einsatz

Symfony gehört zu den ausgereiftesten PHP-Frameworks und ist zugleich eines mit einer langen Lernkurve. Es bringt viele Konzepte mit, die einzeln erklärbar, im Zusammenspiel aber anspruchsvoll sind: der Dienst-Container, Ereignisse, Formulare, Doctrine als Datenbank-Anbindung, Bundles, Messenger. Das ist der Grund, warum Symfony-Erfahrung seltener ist als Erfahrung mit leichter zugänglichen Frameworks, und warum sie sich vor allem bei größeren Plattformen auszahlt.

Die eigene Symfony-Praxis beginnt 2008 mit der ersten Generation, also lange vor dem Neuaufbau, den Symfony 2 ab 2011 gebracht hat. Seitdem sind nahezu alle Hauptversionen im produktiven Einsatz gewesen. Das hilft heute vor allem bei Bestandsanwendungen: Projekte auf Symfony 3, 4 oder 5, die auf einen gepflegten Stand sollen und bei denen das Wissen um die damaligen Konventionen den Unterschied macht zwischen „rekonstruieren" und „kennen".

Der eingesetzte Werkzeugkasten bleibt bewusst nah am Standard: Doctrine für die Datenbank, API Platform für PHP-Schnittstellen samt Dokumentation, Symfony Messenger für Aufgaben, die nicht während einer Anfrage erledigt werden können, Twig für serverseitig gerenderte Oberflächen und PHPUnit für Tests, dazu statische Analyse in der automatischen Prüfstrecke. Diese Zurückhaltung ist Absicht: Je näher eine Anwendung am Framework-Standard bleibt, desto leichter kann ein anderes Team sie später übernehmen.

Der eigentliche Vorzug von Symfony zeigt sich dort, wo die Fachlichkeit komplex ist. Das Framework schreibt wenig vor und liefert stattdessen Bausteine, aus denen sich eine Architektur bauen lässt, die zur Domäne passt. Bei überschaubaren Anwendungen ist das eher Ballast; da sind Frameworks im Vorteil, die viele Entscheidungen schon getroffen haben, etwa Laravel. Wo eine Empfehlung gefragt ist, kommt sie deshalb mit Begründung und nicht als Glaubensfrage.

Häufig geht es nicht um ein Projekt von Grund auf, sondern um Verstärkung im laufenden Betrieb: eine unbesetzte Senior-Position, ein Vorhaben, das nicht vorankommt, oder ein anstehendes Versions-Update. Dann wird mit den Konventionen und Werkzeugen des vorhandenen Teams gearbeitet, nicht mit eigenen. Ebenso gehören Code-Reviews und eine zweite Meinung zu einer geplanten Architektur zum Angebot.

Die Zusammenarbeit läuft standardmäßig zu 100 % remote und damit ortsunabhängig, direkt mit Auftraggebern, als Verstärkung für Agenturen und über IT-Vermittler, gern über längere Zeiträume von mehreren Monaten. Gearbeitet wird aus dem eigenen Büro im kontorworx-Coworking-Space in Rheine, persönliche Termine vor Ort sind nach Absprache möglich, etwa für einen Architektur-Workshop mit dem Bestandsteam.