Interview aus der Praxis: Silex Code langfristig warten
Kommentare

Update:
Im Gespräch mit Bob den Otter haben wir erfahren, wie sich Wiedlers Tipps in der Praxis auswirken. Den Otter und sein Team Two Kings arbeiten mit Silex an dem CMS Bolt.cm, das sich der Version

Update:

Im Gespräch mit Bob den Otter haben wir erfahren, wie sich Wiedlers Tipps in der Praxis auswirken. Den Otter und sein Team Two Kings arbeiten mit Silex an dem CMS Bolt.cm, das sich der Version 1.0 nähert. Und schon jetzt besteht viel Bedarf für Refactoring.

PHP Magazin: Wie skaliert Ihr den Bolt-Code?

Den Otter: Zwischen Version 0.7 und 0.8 habe ich eine Menge Code refactort, und ich habe so viel eigenständigen Code wie möglich in PSR-0-konforme, autoloadbare Klassen verschoben. Der meiste Code ist jetzt auch PSR-2-konform. Die Controller hingegen waren noch immer in drei großen Dateien, worüber ich nicht besonders glücklich war. Aber ich hatte noch nicht viel Zeit darüber nachzudenken, wie ich das verbessern soll.

Nachdem ich Igors Artikel [siehe unten] gelesen habe, bin ich mir recht sicher, dass dies der „way to go“ ist: Am kommenden Wochenende breche ich die Controller auf und verteile sie auf Klassen in BoltControllersFrontend, etc. Bald werden wir auch Unit- und Behaviour-Tests haben. Hoffentlich können wir diese auch automatisieren, damit die Code-Basis kontinuierlich getestet wird, etwa mit Travis.

Am Ende wird jede Erweiterung ihr eigener Namespace sein, was in Sachen Wartbarkeit sehr hilfreich sein wird. Ich schau mir aktuell ein Modell an, mit dem man sie durch Composer/Satis installieren und updaten kann.

PHP Magazin: Was sind Fehler, denen Ihr bei der Arbeit an Bolt begegnet / ausgewichen seid?

Den Otter: Ich glaube, das wichtigste vor dem Gang zu 1.0 ist gar nicht der technische Aspekt. Wenn Leute es benutzen, muss es „Klick“ machen und der Workflow muss stimmen. Da rückt der saubere Code an zweite Stelle.

[…]

Sämtliche Fehler im Code können durch erneutes Schreiben oder Refactornig ausgemerzt werden. […] Der schwere Teil ist es, die User Experience richtig hinzubekommen.

Original News: Silex Code langfristig warten

Silex, die Micro-Schwester von Symfony, ist eine kleine Bibliothek mit grundlegenden Diensten und Routes und einer ersten Struktur für Euer eigenes PHP-Framework. Der Anfang mit Silex ist recht kompakt und überschaubar. Doch das kann sich im Laufe der Zeit ändern. Schnell kommt hier ein Controller hinzu, dann da noch ein bisschen Logik, dann dort noch ein Feature. Fertig sind die Spaghetti.

Um dem Endlos-Code schon früh Einhalt zu gebieten, zeigt Igor Wiedler, wie man seine Controller in Klassen und seine Business Logic in Dienste überführt. Außerdem erweitert er den von Symfony-Urvater Fabien Potencier empfohlenen Artikel „Scaling a Silex code base“ um einen Vergleich von Silex zu Symfony2 und er räumt mit der landläufigen Annahme auf, Silex sei etwas für kleine, und Symfony etwas für große Projekte:

Zwar bietet Symfony2 Full Stack schon eine Menge Konfiguration und Struktur ab Werk, während man da bei Silex freier ist. Dennoch kann man auch auf Grundlage des Microframeworks beliebig große Projekte aus dem Boden stampfen. Dabei sollte man sich an selbst auferlegte Konventionen halten, damit die Architektur auch dann noch wartbar bleibt, wenn das Projekt und das damit beschäftigte Team größer werden.

Wie sind Eure Erfahrungen? Ist bei Euch schon einmal ein Projekt erheblich größer geworden als anfangs geplant? Oder war es eine bewusste Entscheidung, mit einem schlanken Framework zu beginnen, um die Freiheiten einer leichten Basis zu nutzen? Ihr könnt gerne das aktuelle Quickvote nutzen, um Eure Entscheidung zur idealen Framework-Größe zu teilen.

Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -