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
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
10 Gründe gegen den Einsatz von PHP Frameworks
10 Auswahlkriterien für PHP Frameworks
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.
Pingback: Buchrezension PHP Design Patterns von Stephan Schmidt « DaRaFF's Blog
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.