am 7. Juli 2009
A.d.R. Wem dieser Artikel gefällt, sollte den hervorragenden Blog von Ralf Eggert besuchen.
Die Diskussion über den Einsatz von PHP Frameworks ist so alt wie die Welt. Jeder PHP Entwickler, der bei drei nicht auf dem Baum ist, hat sicher schon mal sein eigenes Framework geschrieben bzw. seine eigene lose Klassensammlung, die er selber dann als Framework bezeichnet. Viele haben sogar mehr als eines verbrochen geschrieben.
Ich selber habe in den letzten 10 Jahren, in denen ich intensiv in PHP entwickelt habe, auch mehrere „Frameworks“ für unterschiedliche Projekte geschrieben. Oftmals kamen die dann nur in einem oder maximal zwei Projekten zum Einsatz, weil am Ende des Projektes die Erkenntnis in mir wuchs, dass das Framework doch nicht so toll und flexibel ist, wie ich vorher dachte.
Heute bin ich nicht mehr bereit, meine kostbare Entwicklungszeit in ein eigenes Framework zu investieren, das außer in meinem Unternehmen sonst nirgends mehr eingesetzt wird. Wie der eine oder die andere weiß, beschäftige ich mich derzeit beruflich sehr mit dem Zend Framework. Somit könnt ihr leicht erraten, dass dieses Framework derzeit meine erste Wahl ist.
Immer wieder verfolge ich teilweise sehr energisch geführten Diskussionen über den Einsatz eines Open Source PHP Frameworks und immer wieder höre ich die selben Gründe, die gegen den Einsatz eines PHP Frameworks sprechen. Diese Gründe möchte ich in diesem Beitrag einmal sammeln und danach diskutieren.
1. Bevor ich mich in fremden Programmcode einarbeite, schreibe ich das schneller selbst.
Der Klassiker schlechthin! Ich möchte den PHP Entwickler sehen, der eine komplexe MVC-Komponente schneller schreibt, als er sich in eine vorhandene einarbeitet. Ok, dies setzt natürlich voraus, dass diese Komponente des Frameworks auch gut dokumentiert ist und es auch ausreichend Beispiele für den Einsatz gibt. Es setzt aber auch voraus, dass man in der Lage ist, sich in fremden Programmcode einzuarbeiten. Wer dauerhaft als PHP Entwickler seine Brötchen verdienen möchte, sollte dazu in der Lage sein. Und hat man sich erst einmal eingearbeitet, dann gewinnt man am Ende viel Zeit für die eigentlichen Kundenprojekte.
2. PHP Frameworks sind voller Bugs, man schaue nur auf die langen Listen mit Bugfixes bei jedem Release.
Zuerst einmal: es gibt keine Software ohne Bugs! Es gibt nur Software, in der noch nicht alle Bugs gefunden wurden. Eine lange Liste an Bugfixes spricht nicht unbedingt gegen ein Framework, sondern sogar dafür. Denn je mehr Entwickler dieses Framework einsetzen, desto schneller werden Bugs gefunden. Zudem sind viele Bugs auch eher Erweiterungswünsche. Und auch dein eigenes Framework wird unzählige Bugs beinhalten. Diese hat nur noch niemand gefunden, weil es außer dir niemand nutzt… 
3. Da der Programmcode des PHP Frameworks öffentlich zugänglich ist, mache ich meine Anwendung unsicher. Schließlich können die Hacker den Programmcode des Frameworks auch einsehen.
Unsichere PHP Anwendungen entstehen sicherlich nicht aus dem Einsatz eines PHP Frameworks. Die meisten PHP Frameworks unterstützen den Entwickler sogar dabei, die eigene Anwendung sicherer zu programmieren. Viele Sicherheitsprobleme resultieren aus nicht ausreichend gefilterten und validierten Eingaben der Anwender. Und diese Fehler machen unkundige Entwickler egal, ob sie ein frei verfügbares Framework einsetzen oder nicht.
4. Das Framework XYZ ist völlig überladen, ich brauche nur 2 oder 3 der 40 Komponenten.
Wenn das Framework über eine solide Architektur verfügt, dann sollte es kein Problem sein, dass du dich nur auf die Komponenten konzentrierst, die du wirklich brauchst. Bei einem Full-Stack-Framework kann dies jedoch etwas schwieriger werden. Ein Beispiel: Entfernt man z.B. beim Zend Framework alle require_once() Aufrufe und setzt stattdessen Autoloading ein, werden auch keine Komponenten im vorauseilenden Gehorsam geladen, auch wenn man sie nicht braucht. Und wer nur Zend_Controller und Zend_View aber nicht Zend_Pdf, Zend_Search_Lucene und Zend_HasteNichtGesehen einsetzen möchte, soll das auch gerne tun. Die meisten Komponenten sind lose gekoppelt.
5. Das Framework XYZ ist nicht vollständig, mir fehlen 2 bis 3 Komponenten!
Wer wegen 2 oder 3 fehlenden Komponenten lieber ein komplett neues Framework schreibt, hat eindeutig zu viel Zeit. Da macht es doch mehr Sinn, für ein vorhandenes Framework passende Erweiterungen zu schreiben und diese dann auch der Allgemeinheit zur Verfügung zu stellen. Hat auch den geschmeidigen Vorteil, dass auch andere die Komponenten nutzen und diese somit stetig verbessert wird.
6. Ich kenne gerne den gesamten Programmcode im Detail, so dass ich lieber alles selber schreibe!
Ok, du hast also ein Framework mit Komponenten für Datenbankabstraktion, Models, Controller, Templateverarbeitung, Filter und Validierungsmechanismen, Caching, Konfiguration, Volltextsuche, Authentifizierung, Autorisierung, Formularverarbeitung sowie 10 Webservices geschrieben. Das Framework ist sehr komplex, hat dich aber über 2 Jahre ständig in deiner Freizeit beschäftigt. Kennst du da wirklich den gesamten Programmcode noch im Detail? Ja, bei so einem Elefantenhirn solltest du aufhören zu programmieren und lieber in Quizshows auftreten… Aber im Ernst, jeder kennt das Phänomen, dass man nach längerer Zeit auch seinen eigenen Programmcode manchmal nur schwer bis gar nicht nachvollziehen kann.
7. Was mache ich, wenn das PHP Framework nicht mehr weiter entwickelt wird, weil die Hauptentwickler keine Zeit mehr haben?
Was machst du, wenn du keine Zeit mehr hast, dein eigenes Framework weiter zu entwickeln? Was machst du, wenn du Aufträge ablehnen musst, weil du für das eine Kundenprojekt noch dein Framework erweitern musst? Was machst du, wenn du wegen der Wartung deines Frameworks pro Jahr nur 2 bis 3 statt 23 bezahlte Projekte umsetzen kannst? Hmm, was machst du? Und vor allem, was kuckst du nun?
8. Für das Framework gibt es dauernd neue Releases, bin ja nur noch am aktualisieren.
Ich habe noch nie verstanden, warum neue Releases bei einem Framework ein Problem sein sollten. In einem neuen Release werden Fehler bereinigt und es werden neue Funktionalitäten hinzugefügt. Manche sind für dich wichtig, andere nicht. Und niemand ist gezwungen, jedes Release sofort einzusetzen. Du musst nicht unbedingt, den Wechsel von Version 1.8.3 auf 1.8.4 sofort mit machen, wenn klar ist, dass 1.8.5 schon in den nächsten Wochen kommen wird, und du nicht auf ein Bugfix oder eine Erweiterung in 1.8.4. angewiesen bist. Es sei denn, 1.8.4 schließt explizit eine neu entdeckte Sicherheitslücke. Dennoch solltest du regelmäßig neue Releases einspielen, um auf dem Stand der Entwicklung zu bleiben. Ein direkter Wechsel von einer 1.0 auf eine 2.0 Version ist deutlich aufwändiger, als ein Wechsel von 1.8 auf 2.0. Woher ich das weiß? Aus meiner Erfahrung.
9. Wenn mein Kunde mitbekommt, dass ich nicht alles selber programmiert habe, kürzt er mir das Budget!
Es tut mir natürlich Leid, dass dein Kunde so darauf ist. Ich bin mir aber ziemlich sicher, dass dieser Kunde auch dann Gründe finden würde, dein Budget zu kürzen, wenn du alles selber programmiert hast. Vielleicht sagt er ja: „Wie? Sie setzen kein PHP Framework ein und schreiben alles selbst? Zeit ist Geld! Und Sie sollten Ihre Zeit für mein Problem einsetzen und nicht das Rad neu erfinden! Ich kürze Ihnen das Budget!“
10. Ich schreibe mein eigenes PHP Framework, um zu lernen!
Ok, den Grund lasse ich ausnahmsweise mal gelten…
So, nun seid ihr dran. Wer kennt weitere gute oder schlechte Gründe gegen den Einsatz eines PHP Frameworks?
