Frameworks oder nicht – das ist hier die Frage
Kommentare
Der erste Tag der International PHP Conference 2014 neigt sich dem Ende – und den Framework Day haben wir bereits hinter uns...

Der erste Tag der International PHP Conference 2014 neigt sich dem Ende – und den Framework Day haben wir bereits hinter uns gebracht. Und dabei ging es nicht um die Frage „Framework X oder Framework Y“ – viel mehr ging es um grundsätzliche Themen, die bereits viel früher greifen: Benötigen wir wirklich ein Framework? Und wenn ja, wie passt es in unsere Architektur? Wie entscheiden wir, welches das richtige für uns ist, und was ist eigentlich mit dem damit verbundenen Einarbeitungsaufwand?

All das sind Fragen, die sich jeder von uns früher oder später stellt. Es sind Entscheidungen, die getroffen werden müssen, wenn wir am Beginn eines Projekts stehen – und Entscheidungen, mit denen wir aller Wahrscheinlichkeit recht lange werden leben müssen.

The siren song of frameworks

Brandon Savage hat sich dieses Themas vor einiger Zeit bereits mit einem interessanten Blogpost angenommen: The Framework you learn doesn’t really matter. Und sein Appell ist klar:

Understanding the language is what makes you a great developer. So, if you’re struggling with knowing where to place your bets, bet on PHP itself. Chances are good you won’t lose.

Die Verlockungen sind natürlich riesig: Mit Frameworks lassen sich schnelle Ergebnisse erzielen, wenn Zeitdruck herrscht. Außerdem haben andere bereits das Rad erfunden – warum sollten wir das erneut angehen?

Doch das Problem sitzt tiefer, wie man bei genauerer Betrachtung feststellt. Die Sorgen und Nöte überwiegen oft.

Von Sinn und Unsinn des Frameworkeinsatzes

Es gibt einige Fragen, die man sich stellen muss, bevor man sich für oder gegen den Einsatz eines Frameworks entscheidet. Die wichtigste davon ist zweifelsohne die nach der Laufzeit eines Projekts. Denn möchte man sich in die Abhängigkeit eines Frameworks begeben, wenn ein Projekt über viele Jahre hinweg laufen muss, man aber nicht garantieren kann, ob das Framework der Wahl dann noch existiert? Die vermeintliche Sicherheit, die eines der großen Frameworks bietet, kann dabei trügerisch sein. „Der Knall ist dann nur lauter, wenn es gegen die Wand fährt“, so Robert Lemke in einer Diskussion.

Wichtig ist auch die Frage nach den Vorgaben, die uns das Framework auferlegt. Natürlich sind viele zum Teil auf den ersten Blick kompliziert anmutende Aufgaben mehr oder weniger standardisiert gelöst – das bedeutet jedoch nicht, dass es sich dabei auch um die für das Projekt richtige Herangehensweise handelt.

Außerdem, so Stefan Priebsch, wird die Entscheidung für ein Framework meist viel zu früh getroffen; und aus den falschen Gründen. Sich zu einem Zeitpunkt festzulegen, an dem das Framework der Wahl bei der Community hoch im Kurs steht, vermittle ein falsches Gefühl der Sicherheit.

Und die Moral von der Geschicht?

Der Einsatz eines Frameworks sollte wohl überlegt sein. Viele Detailentscheidungen müssen berücksichtigt, viele Szenarien abgewogen werden.

Bei kurzlebigen Projekten, die oft unter Zeitdruck entstehen, ist der Einsatz eines Frameworks eine valide Lösung – auch wenn ein großer Teil des Feature-Sets gar nicht erst genutzt wird, oder die Lösungswege, die vorgegeben sind, zu umständlich sind.

Bei langfristigen Projekten, die in Gefahr geraten, wenn man sich an ein Framework bindet das mit einem Major-Update grundlegende Funktionalitäten über den Haufen wirft, sollte man sich das zwei mal überlegen.

Denn merke: Ein Framework aus einem Projekt herauszuoperieren, weil es den gewachsenen Ansprüchen nicht mehr gerecht wird, möchte man sich sicher nicht antun.

Aufmacherbild: construction workers in the sunset von Shutterstock / Urheberrecht: hxdyl

Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -