Inspiriert vom Artikel 10 Gründe gegen den Einsatz von PHP Frameworks auf dem phphatesme Blog (der übrigens eine sehr spannende Diskussion auslöste), ging ich dem Thema selber noch ein bisschen nach und diskutierte unter anderem mit Ralf Westphal(Gründer Clean Code Developer) und Michael Heiniger(Kollege) über den Sinn des Einsatzes eines Frameworks.
Der Begriff Framework
Der Begriff Framework ist für mich eine Kombination von einem “richtigen” Framework und einer Funktionsbibliothek (wie z.B. PEAR). Da viele Leute diese 2 Dinge vermischen und man ein “richtiges” Framework meistens auch Modular nutzen kann, verwende ich den Begriff jetzt pauschal für beides.
Anfängliche Argumente gegen ein Framework
Durch negative Erlebnisse in gescheiterten Entwicklungsprojekten, dachte ich, dass das Framework zumindest eine Teilschuld am Misserfolg hatte.
Folgende Argumente/Gefühle schwirrten mir durch den Kopf:
- Frameworks machen vom Framework abhängig/ Es wird schwierig das Framework zu wechseln
- Stimmt, aber jeder Code macht abhängig, auch eigene Klassen/Funktionen
- Natürlich kommen immer wieder neue Frameworks auf den Markt, welche auch besser sein können, aber häufig bieten sie eine ähnliche Funktionalität. Wenn man das Framework wirklich wechseln will, soll man dies in kleinen Schritten machen.
- Ich fühle mich besser, wenn ich eigenen Code schreibe
- Stimmt, aber das ist kein Argument gegen ein Framework (in der Arbeitswelt zählt Effizient)
- Es dauert lange, bis ich mich in ein Framework eingearbeitet habe, selber Coden ist häufig schneller
- Das ist nicht sicher, ob man wirklich schneller ist
- Framework Code ist normalerweise qualitativ besser und stabiler und wird bei Fehlern auch gefixt
- Mitarbeiterfluktuation ergibt Probleme, weil sich die neuen Leute in den Code UND in das neue Framework einarbeiten müssen
- Ja und mit einer Eigenentwicklung müssen sie mehr eigenen Code lesen (vielleicht kennt der neue das Frameworks sogar schon?)
Fazit
Folgende Schlüsse habe ich mir erarbeitet:
- Bei den gescheiterten Projekten herrschte Zeitdruck (durch Fehler im Management)
- Unter Zeitdruck das Framework lernen und für den Kunden die richtige Umsetzung zu erledigen ist schwierig
- Abläufe/Prozesse waren fehlerhaft
- Prozess für die richtige Produktwahl war ungenügend
- Ausbildung der Entwickler war ungenügend
- Bewusstsein für sauberen Code war zu wenig vorhanden (Ausbildung/Führung)
- Das Rad nicht neu erfinden
- Es macht keinen Sinn das Rad neu zu erfinden. Bestehende Funktionen soll man nutzen und sich auf die effektiven Bedürfnisse des Kunden konzentrieren. Ansonsten könnte man ja auch den Compiler oder das Betriebssystem selber schreiben, weil man dann eine bessere Kontrolle hat.
- Anwendung Framework
- Man kann die Abhängigkeit eines Frameworks steuern. Viele Frameworks bieten auch eine Modulare Einbindung in den eigenen Sourcecode. Somit könnte man bei Bedarf auch eine andere Bibliothek/Funktion einbinden.
- Qualität
- Meistens sind die Entwickler eines Frameworks die besseren Programmierer, daher sind auch die Funktionen, die sie anbieten besser
- Falls eine Funktion Fehler enthält, werden die Fehler bei Frameworks schneller bemerkt (und behoben)
- Bei einer aktiven Community sind sehr viel Ressourcen verfügbar, die das Framework weiter treiben, d.h. man kann immer wieder auf neue Funktionalität zugreifen, welche man sonst selber hätte entwickeln müssen.
- Der Kunde zahlt
- Heutzutage muss die Entwicklung effizienter sein als früher. Der Kunde zahlt nur noch für Funktionen, die ihm unmittelbar etwas bringen. Um diese Effizienz zu erreichen, muss man auf bestehende Funktionalität zurückgreifen.
Auswahl eines Frameworks
Auf folgende Punkte sollte man bei der Auswahl eines Frameworks achten
- Aktuelles Framework
- Aktive Community oder Firma, die das Produkt weiterentwickelt
- Hoher Verbreitungsgrad (damit ist die Chance gross, dass auch die ersten 2 Punkte erfüllt sind)
- Dokumentation (Tutorials, Bücher,…)
- Funktionen die angeboten werden (auch Plugins)
- Es soll zum Projekt passen, das man in Angriff nehmen will (es bringt nichts, eine MVC implementation anzuwenden, wenn diese gar nicht benötigt wird)
Quellen
Ich persönlich bin auch pro-Framework. Als wichtigen Punkt für die Auswahl würde ich noch die Stabilität der API ansehen. Wenn die sich alle paar Wochen ändert kann der Rest noch so toll sein, das kostet dann immer wieder Zeit.
Grüße
Applikationen bzw. die Business-Logik sollte nicht per-se eine Abhängigkeit zum Framework selbst haben. Die Business-Logik sollte unabhängig von den Strukturen des Frameworks plaziert sein so dass man theoretisch die Möglichkeit hätte einen Frameworkwechsel durchzuführen.
Stephan da gebe ich Dir Recht. Es nicht richtig immer und überall ein Framework einzusetzen. Bei der Business-Logik sollte man, wenn man denn ein Framework einsetzt, zumindest Adapter dazu schreiben, so dass man diese beim Wechsel des Frameworks einfach wieder anbinden kann. So entsteht zumindest nur eine Teilnabhängigkeit.
Ein sehr interessanter Artikel. Wollte schon lange was darüber schreiben. He he… Nun hier mein Kommentar: stimme zu, dass das Einarbeiten in einem Framework nicht immer leicht ist und zum Teil langwierig sein kann. Wenn man es aber einmal drauf hat, dann ist die Umsetzung oft sehr schnell. Zudem braucht man sich danach oft keine Gedanken über die Sicherheit zu machen, da die meisten Frameworks gut getestet sind. Es gibt auch Nachteile! Nehmen wir an man fängt gleich mit einem Framework das Programmieren mit PHP zu erlernen. So ist das Problem hier, dass man nichts von den nativen Funktionen des PHP mitkriegt. Da hat zu Folge, dass bei tiefer-gehenden Problemen man sich mit das Framework genauer beschäftigen muss jedoch aber nicht genügend Wissen und Erfahrung dafür hat. Also, am besten ab und zu mal versuchen sich genauer mit dem Framework zu beschäftigen und zu schauen wie die das dort umgesetzt haben. Gegebenenfalls den Lösungsansatz mit anderem Framework vergleichen.
Erstmal vorweg: Ist es nicht auch eine Frage des Projektumfangs? Sollte eine Entwicklerstube bereits eigene Bibliotheken aus Klassen und Funktionen entwickelt haben, die sie relativ schnell zu einem Gesamtprojekt zusammensetzen/-skripten kann…was spricht dagegen, wenn der Code zudem übersichtlich gehalten und gut dokumentiert ist? Bei einem Shopsystem sicher kein geeigneter Weg, aber bei minimalen Projekten (bspw. die unzähligen Webseiten, auf denen Künster, Projekte etc. dargestellt werden)?
Und ein Punkt zur Qualität stört mich etwas: “Meistens sind die Entwickler eines Frameworks die besseren Programmierer, daher sind auch die Funktionen, die sie anbieten besser.” Ist das nicht etwas pauschal? Was ist mit jenen, die mit einem Framework beginnen? Die werden sich um Grundlegendes nie kümmern müssen, was aber letztlich relevant wäre, um zu entscheiden ob jemand ein “besserer Programmierer” ist. Demnach entstünde bei jenen, die sich auf Frameworks einschießen, aus dieser Betrachtung ein Nachteil, weil sie sich über manche Funktionen garnicht bewusst sein müssen, wie sie entwickelt werden, da die Bibliotheken bereits einiges vorgeben. Klar, es müssen Teile angepasst werden…aber letztlich nur das, was wirklich benötigt wird. Dass die Url nicht wie gewohnt aus Sonderzeichen (?, &, =) besteht wäre vielleicht ein Beispiel dafür, dass einiges nicht selbst entwickelt / gelernt werden muss.
Unabhängig vom praktischen Nutzen: Zählt ein jemand nicht eher zu den “besseren Programmierern”, wenn er Projekte mit eigens gut entwickelten Bibliotheken umsetzen kann? Nicht, dass ich mich dazu zählen würde…aber etwas pauschale Behauptung wie ich finde.
Hi Christoph
Natürlich ist der Umfang ein Argument. Aber eine typische Webseite benötigt/verwendet heutzutage MVC, Routing, Caching, Environments usw. Warum soll man dies also jedesmal von neuem Enwickeln? Natürlich, wenn man eine historisch gewachsene, eigene Bibliothek mit nützlichen Funktionen geschrieben hat, kann dies auch verwendet werden. Die Problematik ist, dass man die Funktionalität, die man häufig von einem Framework gratis geliefert kriegt hier selber inhouse entwickeln muss. Die ganzen Erkenntnisse aus der Community (schnellere Funktionen, Security, usw) müssen ständig inhouse nachgepflegt werden. Daraus resultiert, dass häufig Eigenentwicklungen dem State of the Art hinterherhinken (ich sage nicht immer 🙂 ).
Vielleicht habe ich mich nicht ganz so klar ausgedrück, bzw. Du hast mich missverstanden. Ich meine jemand, der an der Entwicklung eines Frameworks beteiligt ist, benötigt normalerweise mehr/bessere Fähigkeiten, als jemand, der das Framework benutzt. Somit glaube ich, das ein Framework fast immer eine bessere Codequalität aufweist, als eigens entwickelter Code, der von einem “normalen” Anwendungsprogrammierer entwickelt wird.
Natürlich lernt man viel, wenn man selber ein “Framework” entwickelt und wird dadurch auch ein besserer Entwickler. Ob man aber mit der Qualität der Frameworks aus der Community mithalten kann, welcher von dutzenden Leuten entwickelt/gereviewt wird, mag ich zu bezweifeln.