Facebook
Twitter
Google+
Kommentare
21
Willkommen bei "the web hates me". Mittlerweile hat unser Team ein tolles neues Monitoringtool für Agenturen gelauncht. Unter dem Namen koality.io haben wir einen Service geschaffen, der er Agenturen ermöglicht mit sehr geringen Kosten alle Ihre Webseiten zu überwachen.

10 Auswahlkriterien für PHP Frameworks

Es gibt ja bekanntlich mehr PHP Frameworks als Sandkörner am Strand von St. Peter-Ording. Da fällt die Auswahl natürlich sehr schwer. Ist die Eigenentwicklung eines Frameworks keine Alternative, geht der findige PHP Entwickler halt auf die Suche und wir schnell fündig. Er notiert sich eine Liste der Frameworks, die er findet, und macht sich nun ans Auswählen. Doch das ist einfacher als zunächst gedacht.

Mancher probiert zunächst ein wenig mit dem einen oder anderen Framework herum. Ein anderer sucht nach unabhängigen Frameworkvergleichen und findet neben viel Rauschen alles Mögliche, nur keine unabhängigen Frameworkvergleiche. Wieder ein anderer durchwühlt die Featurelisten oder fragt Freunde und Bekannte. Um Euch die Auswahl zu erleichern, möchte ich euch einen kleine Kriterienkatalog an die Hand geben.

1. Kriterium: Aktualität

Ein wichtiger Aspekt ist die Aktualität eines Frameworks. Ist das Framework bereits veraltet oder wird nicht mehr aktiv gepflegt, lohnt es sich nicht, darauf Zeit zu verschwenden. Um die Aktualität bewerten zu können, solltet ihr euch folgende Fragen stellen.

  • Wie aktuell ist das neueste stabile Release?
  • Wie häufig gibt es neue Releases?
  • Wie sieht die Release Historie aus?
  • Gibt es feste Release-Zyklen?
  • Seit wann wird das Framework entwickelt?
  • Gibt es eine Roadmap?

2. Kriterium: Verbreitung

Da Millionen Fliegen sich bei irrer Nahrungswahl auch einig sind, spricht eine hohe Verbreitung des Frameworks auch dafür, dass sich ein näherer Blick lohnt. Je weiter es verbreitet ist, desto geringer die Chance, dass es eines Tages einschläft und nicht nicht mehr gewartet wird.

  • Gibt es Informationen zu den Downloadzahlen (leider nur selten verfügbar)?
  • Gibt es bekannte Referenzen, die das Framework einsetzen?
  • Anzahl Treffer in Suchmaschinen (Google, Yahoo)
  • Google Pagerank?
  • Ist in Zukunft eher von einer steigenden Verbreitung auszugehen?
  • Gibt es Stellenangebote von Unternehmen, welche Erfahrung im Framework voraussetzen?

3. Kriterium: Dokumentation

Wie hilfreich und wichtig eine gute Dokumentation ist, merken manche Entwickler erst, wenn diese fehler- und/oder lückenhaft ist. Je besser die zur Verfügung stehende Doku ist, desto schneller könnt ihr im Selbststudium ein Framework kennen lernen und erste Schritte gehen.

  • Wie umfangreich und aktuell ist die mitgelieferte Dokumentation?
  • Gibt es eine Kommentarfunktion in der Dokumentation mit weiteren Hinweisen der Anwender?
  • Gibt es viele Tutorials, Anleitungen und dokumentierte Best Practices? Wie aktuell sind diese?
  • Gibt es auch eine API Dokumentation zum Download?
  • Gibt es Bücher zum Framework (Gedruckt, E-Books)?

4. Kriterium: Qualitätssicherung

Wichtig ist auch die Frage nach der Qualitätssicherung (neudeutsch Quality Assurance). Ein Framework, dass sich nur wenig um die Sicherung der Qualität kümmert, kann auch als Bananensoftware bezeichnet werden: sie reift dann beim Anwender / Kunden.

  • Gibt es Programmierrichtlinien, an die sich alle Entwickler des Frameworks halten müssen?
  • Werden Unit-Tests zur Qualitätssicherung eingesetzt?
  • Werden diese mitgeliefert?
  • Wie hoch ist die Testabdeckung?
  • Wird sogar testgetrieben entwickelt?
  • Wird das Schreiben von Unit-Tests für eine auf dem Framework basierende Anwendung unterstützt?

5. Kriterium: Entwickler

Auf den ersten Blick mag dieser Aspekt nicht so wichtig sein. Doch wer bereits erlebt hat, dass ein Framework, in das er sich monatelang eingearbeitet hat, stirbt, weil der einzige Entwickler plötzlich zum Fliegenfischen nach Tasmanien ausgewandert ist, der kennt die Problematik.

  • Ist es ein reines Open-Source Projekt, das von vielen Freiwilligen gestützt wird?
  • Oder steht eine Firma im Hintergrund, welche die Entwicklung vorantreibt / unterstützt?
  • Ist die Anzahl der Kernentwickler bekannt? Wie viele?
  • Bieten die Kernentwickler / die Firma auch kommerziellen Support an?
  • Ist das Framework ein Fork oder wurde es schon mal geforkt („brain drain“)?

6. Kriterium: Community

Mit einer tollen und aktiven Community macht die Arbeit mit einem Framework noch mehr Spass. Außerdem findet man somit schneller Hilfe, wenn man mal vor einem Problem steht, das alleine nicht zu lösen geht.

  • Wie aktiv sind die Mailinglisten und Foren zum Framework?
  • Wie schnell bekommt man Hilfe auf eine Frage?
  • Wie ist der Umgangston in den Mailinglisten und Foren?
  • Gibt es Blogs, welche aktuelle Informationen sammeln und veröffentlichen?

7. Kriterium: Lizenz

Dieser Lizenzkram ist extrem langweilig, aber man kommt nicht darum, sich damit auseinander zu setzen. Nichts ist schlimmer, wenn man mitten im Projekt erst entdeckt, dass der geplante Einsatz des Frameworks gar nicht in dieser Form erlaubt ist.

  • Unter welcher Lizenz wird das Framework veröffentlicht?
  • Gibt es auch eine kommerzielle Lizenz?
  • Passt diese Lizenz zu den eigenen Anforderungen für die Nutzung des Frameworks?

8. Kriterium: Technik

Jetzt geht es langsam ans Eingemachte. Einen Entwickler interessieren natürlich die technischen Aspekte besonders. Ich kenne mindestens einen Fall, wo sich jemand ein Buch zu einem Framework gekauft hat, um bei der Lektüre festzustellen, dass dieses Framework gar nicht auf PHP 4 läuft.

  • Wird noch das veraltete PHP 4 unterstützt oder werden die Stärken von PHP 5 ausgekostet?
  • Passen die technischen Anforderungen des Frameworks auf die vorhandenen technischen Voraussetzungen?
  • Lässt sich das Framework einfach erweitern?
  • Werden umfangreiche Konfigurationsdateien benötigt oder gibt es Konventionen, die man einhalten muss / kann?
  • Besteht die eigene Anwendung aus Monsterklassen oder lassen sich die Elemente (Controller, Aktionen, Models, Views, Formulare, etc.) fein trennen?

9. Kriterium: Bugs

Für viele ärgerlich gehören die Bugs doch zu unserem täglich Brot. Je kennt die Situation, in der man einen unvorhersehbaren Fehler findet und nicht weiss, wo der vermalledeite Fehler her kommt. Den will man natürlich weg haben und schnell findet man sich bei Google und dann sofort im Bugtracker des Frameworks wieder. Also fragt euch:

  • Ist das Framework bugfrei? (kleiner Scherz)
  • Wie viele Bugs wurden gemeldet / gelöst?
  • Verhältnis gemeldete und bereinigte Bugs?
  • Beispielzahlen von Mitte August 2009:
    • Agavi (gemeldet 1065, bereinigt 995, Ratio 93,43%)
    • CakePHP (gemeldet 6528, bereinigt 5880, Ratio 90,07%)
    • eZ Components (gemeldet 1355, bereinigt 1215, Ratio 89,67%)
    • Symfony (gemeldet 6814, bereinigt 5367, Ratio 78,76%)
    • Zend Framework (gemeldet 7551, bereinigt 5736, Ratio 75,96%)

10. Kriterium: Features

Endlich, die Features! Nicht wenige fangen bei der Auswahl bei diesem Punkt an und belassen ihre Bewertung auch meistens nur bei der Betrachtung der Features. Doch die Features sind nur ein Aspekt, der dennoch nicht ungeachtet werden darf. Aber selbst ein Framework, dass nur 60% der gesuchten Funktionalitäten bereit stellt, aber ansonsten in allen anderen Kriterium gut weg kommt, ist alle mal besser, als ein Framework, dass die Features zu 99% bereit stellt, aber seit 2 Jahren nicht mehr gepflegt wird.

  • Bietet das Framework alle Features / Komponenten, die in der eigenen Anwendung gebraucht werden?
  • Sind die fehlenden Features / Komponenten zeitnah (in den nächsten Monaten) geplant?
  • Können die Anwender auch eigene Features / Komponenten vorschlagen / anbieten?
  • Wie einfach lassen sich externe Komponenten integrieren, z.B. Smarty, Doctrine, Webservices?

Natürlich lassen sich nur schwer alle Fragen für alle Frameworks beantworten! Meistens findet man die Zahlen und Daten gar nicht (Beispiel Downloadzahlen) oder sie sind nur schwer zu erfassen. Dieser Kriteriumkatalog ermöglicht es aber, schnell eine Vielzahl an Frameworks auszuschließen, um sich dann auf die wesentlichen Frameworks konzentrieren zu können! Ergänzt wird die eigene Auswertung dann durch Ausprobieren und Testen der Frameworks.

Diesen Kriterienkatalog habe ich übrigens das erste Mal auf der letzten PHP Unconference in Hamburg vorgestellt. Marko Bischof hat übrigens den Entwickler des Yii-Frameworks um die Beantwortung der Fragen gebeten und diese eiskalt in seinem Blog veröffentlicht. Danke Marko! Wer möchte, kann dies auch gerne bei anderen Framework Entwicklern versuchen und sich hier in den Kommentaren melden.

Nun eröffne ich gerne die Diskussion. Fallen auch weitere Kriterien ein? Habt ihr einen andere Vorgehensweise zur Auswahl eines Frameworks.

Über den Autor

Ralf Eggert

Ich arbeite seit 1998 mit PHP und kenne somit noch die Vorzüge vom guten alten PHP 3 ;-) Mein Spezialgebiet sind das Zend Framework, mit dem ich mich bereits seit Anfang 2006 beschäftige. Ich betreibe einen Zend Framework Blog [1] und schreibe regelmäßig für das deutschsprachige PHP Magazin. Zudem habe ich bereits ein Buch über das Zend Framework veröffentlicht [2]. Hier bei PHP hates me habe ich bisher überwiegend über Frameworks allgemein geschrieben. [1] http://blog.zf-info.de/ [2] http://www.zendframeworkbuch.de/
Kommentare

21 Comments

  1. Genau Jan, das ist der Sinn des Artikels. Je nachdem, wie du die Kriterien gewichtest, kannst du zu einem anderen Ergebnis kommen. Ich bin z.B. am Ende beim Zend Framework gelandet, weil es für meine Zwecke am besten passt. Andere Frameworks würde ich wiederum nicht mit der Kneifzange anfassen wollen… 😉

    Reply
  2. Ich glaube, bei meiner letzten „Welches Framework passt“ Fragerunde habe ich bestimmt 8 der 10 genannten Punkte selbst in meine Überlegung bezogen. Eine sehr gute Liste, die jedem weiterhelfen kann. Vielen Dank dafür 🙂 Ich hoffe, es verbreitet sich schön weiter im Netz!

    Reply
  3. Ralf, Danke für deine Antwort. Eine andere Kommentar: ich finde sehr schwierig eine anderes Framework lernen. Wenn du eines benutzest, wenn es gut ist (wie z.B. Symfony oder Zend) und du fühlst dich bequem mit ihn, dann du findest kein Sinn zu verändern. Glaubst du nicht?

    Reply
  4. Ich weiss nicht wie die Statistik der Bugs zu den eZ Components berechnet wurde. Der issue-tracker kennt im Moment 13 offene Bugs, bei 1399 issues insgesammt – das waere 99,07%. Zu dem Zeitpunkt eines Releases, was aktuell ca. 2 Monate in der Zukunft liegt, kuemmern wir uns immer darum keine offenen bekannten Bugs zu haben, die Quote sollte also dann immer bei ca. 100% liegen (es gab einmal eine Ausnahme).

    @Ralf: Beziehst du enhancement-requests in die Statistik mit ein, oder wie kamst du zu den Zahlen?

    Reply
  5. @Kore,

    guter Einwand, hätte ich dazu schreiben sollen. Bei den Zahlen handelt es sich um alle Issues, also sowohl Bugs als auch die Enhancements. Die Zahlen für die eZ Componensts hatte ich aus diesem Bericht entnommen:

    http://issues.ez.no/IssueList.php?

    Bei den anderen Frameworks sind die Enhancements soweit auch enthalten, also sollte der Vergleich eigentlich wieder passen.

    Reply
  6. @Jan,

    solange man mit einem Framework gut zurecht kommt und eingearbeitet ist, macht es für mich keinen Sinn, vor jedem neuen Projekt gleich wieder neu anzufangen mit der Suche. Anders sieht es aber aus, wenn ein ernst zunehmendes neues Framework auf dem Markt erscheint. Dann könnte man das Ganze noch einmal anschauen, wobei ich dann nur das neue und die Frameworks aus der letzten Runde näher in Betracht ziehen würde…

    Reply
  7. @Ralf,

    OK, gut zu wissen. Meiner Ansicht sollte man das aber aufteilen. Ungefixte Bugs sind eine hartes Hindernis, dass die Benutzung stark einschraenken kann.

    Erweiterungen sind in sauber designten objektorientierten Komponenten normalerweise kein Problem, und stehen somit auf einem anderen Blatt. Wichtig ist dazu, meiner Meinung nach, noch die mittlere Zeit in der Bugs gefixt werden, auch wenn leider wenige Bugtracker diese Information direkt liefern.

    Reply
  8. Separation of Concerns. Für mich ist noch besonders wichtig, dass das Framework keine eierlegende Wollmichsau ist. Viele „Frameworks“ wollen auch das tausendste Feature implementieren und haben keinen echten Fokus und kein Ziel mehr.

    Overengineering. Auch ob das Framework „verkünstelt“ ist. Manchmal werden die Sachen total overengineered. Der Code muß zielgerichtet entwickelt sein.

    Integration. Das Framework muß ich mit anderen leicht integrieren können. Zum Beispiel würde ich vielleicht gerne Log4PHP nutzen, die Dependency Injection Klassen von PIWI und ein paar Dinge vom Zend FW. Auch dafür sollte ein Weg existieren.

    Erlernbarkeit. Ich möchte schnell zum Ziel und nicht das komplette Framework erlernen müssen, um damit arbeiten zu können. Ich muß ein Framework innerhalb von 2h verstehen können und meinen ersten Prototyp innerhalb von 2 Tagen aufsetzen können. Nach 2 Wochen sollte ich gut mit dem Framework umgehen können ohne ständig über unbekannte Elemente zu stoßen.

    Reply
  9. @Kore,

    ja, macht im Prinzip mehr Sinn. Natürlich ist bei diesen Auswahlkriterien nichts in Stein gemeisselt. Und die Zahlen waren auch eher nur als Beispiel gedacht. Mal schauen, vielleicht finde ich die Zeit und suche mal die Zahlen nur für die Bugs heraus.

    Reply
  10. @Christian und @Florian

    Danke für die neuen Vorschläge. Natürlich lässt sich die Liste beliebig erweitern oder kürzen oder insgesamt den eigenen Bedürfnissen anpassen. Jeder hat für sich persönlich auch einen anderen Schwerpunkt.

    Reply
  11. Die 10 Pukte sind nicht falsch, aber der Zusammenhang untereinander kommt zu kurz.
    Kernfrage:

    >> Was soll das Frmework für mich leisten? <<

    Die führt auch zu Punkt 11: Wie lange brauche ich, um mit dem Framework klar zu kommen.

    Reply
  12. Bauchgefühl gehört aber auch irgendwie dazu.

    Als ich auf der Suche war, waren im ernsthaften Entscheidungsprozess eigentlich nur CakePHP und Zend FW. Und ich hätte mich auch gerne für Zend FW entschieden, den Verbreitung und Features sind der hammer, aber mein Bauchgefühl hat gesagt, nimm Cake und mein Bauch hatte (denken ich zumindest im nach hinein) auch recht.

    Reply
  13. @Sebastian,

    stimmt, das Bauchgefühl ist auch ein wichtiger Aspekt, der sich jedoch für viele nicht greifen lässt. Mein Bauchgefühl hat mich damals übrigens von CakePHP und Symfony abgehalten und mich auf das Zend Framework konzentrieren lassen. Und auch mein Bauch hatte damit recht.

    Und es ist auch gut, dass es für alle verschiedenen Bäuche unterschiedliche Frameworks gibt. So bekommt jeder Bauch seinen Geschmack… 😉

    Reply

Leave a Comment.

Link erfolgreich vorgeschlagen.

Vielen Dank, dass du einen Link vorgeschlagen hast. Wir werden ihn sobald wie möglich prüfen. Schließen