Ich packe meinen Koffer und nehme mit …

Lesetipps

1. Zend Framework aufsplitten
2. Erstellt eure eigene PHP Bibliothek
3. Projektwerkstatt: Pasmine, assert library

Keine Sorge, ich gehe nicht auf Weltreise und lasse euch hier alleine. Obwohl, wenn mir jemand eine Weltreise zahlen will, dann gehe ich natürlich gerne und lasse euch alleine. Aber eigentlich wollte ich mit meiner Überschrift was anderes ansprechen. Ich bin ja schon eine Weile in der PHP Entwicklung unterwegs. War an einigen Projekten beteiligt. Meist haben wir versucht möglichst sauberen und wartbaren Code zu produzieren. Jetzt habe ich mir dieses Wochenende die Frage gestellt, was man von den vielen tausend Zeilen Code, die in den meisten Anwendungen vorhanden sind wiederverwenden könnte.

Also so was wie, “aus unserem Projekt ist das Zend Framework entstanden”, oder halt eine andere Bibliothek. Meistens ist es doch so, dass man so programmiert, dass man das Projekt fertigstellen will. Diese Art zu entwickeln sagt wahrscheinlich gar nichts über die Qualität der Anwendung aus, denn die kann sauber und unter Einhaltung der meisten Programmierparadigmen gestrickt worden sein.

Jetzt wisst ihr vielleicht schon, wie mein Titel gemeint war. Wenn ihr ein Projekt abschließt und zum nächsten zieht, was nehmt ihr dann mit? Könnt ihr auf eine große, firmeninterne Bibliothek aufbauen, die ihr über die Jahre aufgebaut habt? Setzt ihr jedes mal wieder von ganz vorne an? Vielleicht startet ihr auch mit einem Standard-Framework. Das ist eine Frage, die mich wirklich interessieren würde.

Bei mir ist es in den letzten Jahren so, dass ich eine Base-Bibliothek aufgebaut habe. Dort kommen alle allgemeinen Funktionalitäten rein, die ich so entwickelt habe. Diese schleppe ich dann von Projekt zu Projekt und verbessere sie hier und da. Eigentlich wollte ich die mal als Open Source Projekt rausbringen, aber dazu würde ich sie erst mal in Drittprojekten testen lassen wollen. Vieraugenprinzip, ihr wisst schon.

So jetzt noch mal kurz die Frage zusammengefasst, was nehmt ihr mit, wenn ihr in ein neues Projekt startet?

22 Kommentare »

• 
  

  Christian

  am 14. Juni 2010 um 07:36 Uhr

  “Eigentlich wollte ich die mal als Open Source Projekt rausbringen, aber dazu würde ich sie erst mal in Drittprojekten testen lassen wollen.”

  Und da ist leider so gut wie keine Zeit fuer, weshalb es auch nie was wurde. Kenn ich gut. Witzigerweise ist da aber ein Denkfehler drin.
  Denn Testen an Drittprojekten sollte man auch Dritten ueberlassen. Also schnell als Open Source veroeffentlichen und auf Feedback warten. Wird schon kommen und spart nicht nur deine Zeit sondern wird auch neue Ideen und Anregungen bringen.

• 
  

  ragtek

  am 14. Juni 2010 um 07:44 Uhr

  Ich arbeite hauptsächelich an vBulletin Erweiterungen, => mir schon eine “riesige Library/Framework” angeboten.
  Mittlerweile habe ich aber auch eine kleine “Library” zusammengestellt, die mir die Arbeit erleichtern soll.
  Diese wird aber nie komplett mitgegeben, sondern ich gebe nur die vom Projekt benötigten Klassen / Funktionen mit.

  Mittlerweile ist es schon so, dass es mein Builder für mich automatisch über meine Konfigurationsdatei in den Build einbaut.
  Das heißt ich trage die Dateien aus der Library ein und der Builder kopiert sie in das Archiv wärend dem Buildvorgang.
  Der Eintrag schaut zB so aus:

  $config['neededLibraryFiles'] = array(
  ‘ragtekDAO.php’,
  ‘ragtek_Profileblock.php’,
  ‘class_ragtek_mail.php’,
  ‘class_ragtek_pm.php’,
  ‘functions.php’,
  );

• 
  

  aeckhoff

  am 14. Juni 2010 um 09:12 Uhr

  Wir haben vor über 10 Jahren mit einem eignen CMS begonnen. Für dieses CMS haben wir haufenweise Klassen erzeugt. Die CMS unabhängigen davon sind in eine kleine Bibliothek gewandert, die seit dem die Basis unserer Projekte bildet.
  Im Laufe der Zeit hat sich aber eine weitere Arbeitsweise herausgebildet, die sich ab einer gewissen Projektgrösse anbietet. Wir nehmen unser CMS (seitenbasiert) als Basis für die Applikation. Eine große Applikation benötigt in der Regel neben Datenbankanbindung, Konfiguration, usw. auch öffentliche Seiten, passwortgeschützte Seiten, statische Textseiten (für Einleitungen, Hilfen, usw), eine Benutzerverwaltung, eine Navigation, uvm. Die letzteren Sachen werden von Haus aus schon vom CMS geliefert, so dass dessen Basisfunktionalität das Grundgerüst der Applikation bildet. Mit Hilfe des CMS können wir somit bereits die komplette Struktur der Applikation vorbauen. Dabei erzeugen wir für die neuen Funktionalitäten bereits die Seiten des CMS und hinterlassen in den Seitenkommentaren die Meldung, welche Funktionalität an dieser Stelle noch benötigt wird. So können wir auch für den Kunden bereits die Applikation mit “Mockups” füllen und man kann bereits erahnen, wie die Applikation aussehen wird. Dann füllen wir nach und nach die Lücken mit entsprechenden Plugins/Modulen und so wächst die Applikation im Laufe der Zeit.
  Somit verwenden wir nicht nur unsere Basisklassen als Bibliothek, sondern auch das CMS als Applikationsframework. Weiterer Vorteil daraus ist, dass die Plugins/Module der jeweiligen Applikation eben solche sind, nämlich Plugins/Module, welche wir für spätere Projekte ebenfalls sehr einfach wiederverwenden können.

  LG, Andy

• 
  

  Norbert Bartels

  am 14. Juni 2010 um 09:34 Uhr

  Wir haben ein Framework entwickelt, das auf unsere Bedürfnisse angepasst ist. Somit werden für neue Anwendungen nur noch Logik, Gui und spezielle DB-Tabellen entwickelt. Erkannte Probleme im Framework fließen dann zurück in die Kernkomponente. Projektspezifische Erweiterungen werden nach Abstimmung mit den Entwicklern in das Framework übernommen.

• 
  

  Stephan Hochdoerfer

  am 14. Juni 2010 um 10:13 Uhr

  So ist im Grunde unser firmeninternes Framework entstanden. Erst als Komponentenbibliothek und dann immer weiter mittels Standardisierungen und Namenskonventionen hin zum eigenen full-stack Framework. Auch wenn ich dafür immer wieder gern aus der Community gebasht werde war das damals (in 2001) die einzig sinnvolle Entscheidung. Jetzt umzusteigen auf ein Standard-Framework macht für uns auch keinen Sinn mehr weil wir a) sehr viel Zeit in die Entwicklung investiert haben und b) sehr viele alte Projekte warten / betreiben müssen.

  Das heißt natürlich nicht dass wir alles neu erfinden. Gerne nutzen wir Komponenten aus Zend oder anderen Bibliotheken um Funktionalitäten wie Mailversand, PDF Generierung oder AMF Kommunikation abzudecken. Und PHPUnit neu zu erfinden macht auch nicht wirklich Sinn

• 
  

  Dominik

  am 14. Juni 2010 um 10:42 Uhr

  Wie schon bei den Kommentaren aller anderen: Auch ich habe mir hier ein realtiv umfangreiches Framework zusammengebaut, auf dem basierend jetzt neue Projekte entstehen. Auf der einen Seite gibt es immer wieder verwendete Funktionen wie Session-Management und diverse Wrapper für HTTP-Requests, Mail-Versand und ähnliches, so dass ich mich nicht mehr mit den internas von PHP herumschlagen muss. Auf der anderen Seite steht ein MVC System mit Plugin-Funktionalität. Ich habe also immer das gleiche Basis-System, in das ich einfach nach Bedarf verschiedene Plugins reinladen kann. Dadurch wird immer alles schön modular und wiederverwendbar.

• 
  

  Michael

  am 14. Juni 2010 um 11:01 Uhr

  Ich habe auch so ein Mini Framework, dass quasi die absolute Grundlage für Projekte darstellt, hatte es vor kurzem mal online gestellt:
  http://zeon.mdlabs.de/

  Dazu kommen dann ggf. noch Komponenten die man dynamisch als Module einhängen kann und so wird es sehr schnell zu einer sehr guten Entwicklungsumgebung

• 
  

  Simon

  am 14. Juni 2010 um 12:52 Uhr

  Ich habe mein eigenes Framework und damit entwickle ich schnell und flexibel

• 
  

  Nils Langner

  am 14. Juni 2010 um 13:13 Uhr

  Der Trend scheint wohl zum eigenen Framework zu gehen, hatte gehofft mehr über Bibliotheken zu lesen.

• 
  

  aeckhoff

  am 14. Juni 2010 um 14:00 Uhr

  Naja, bei uns ist es ein Mix aus beidem. Das CMS dient als Framework und die Basisklassen und Plugins als Bibliothek.

  Mehr zu den Bibliotheken:
  Basisklassen: die laufen in der Regel losgelöst vom Rest und bieten die Grundlage. U.a. Formklassen, Validationklassen, Filterklassen, DB-Abstraktion (eigene, damit CLOBS in Oracle vernünftig laufen. Wenn hier jemand Alternativen kennt, die MySQL und Oracle – incl. CLOBS vernünftig unterstützten, würde mich freuen davon zu hören), Request, Response, Registry, Filterobjekte, Auth-Klasse, kleine fixe Templateengine (mittlerweile durch View-Klasse abgelöst), uvm…
  Diese Klassen werden von Projekt zu Projekt verwendet und dabei meist auch weiterentwickelt. Häufig kommen auch neue hinzu, wenn wir sehen, dass bestimmte Klassen häufiger Verwendung finden. Je nach Fragestellung binden wir hier auch das Zend-Framework mit ein (Mime, Mail, Cache, etc).

  Ganze Funktionalitäten erstellen wir als Plugins/Module für das CMS. Diese werden je Projekt auch meist verbessert, bzw. es kommen neue hinzu. Hierzu gehören allgemeine Sachen wie “Login”, “Password Lost”, “Profil bearbeiten”, “Navigation-Tree”, “Navigation-Breadcrumb”, “Navigation-List”, “Adressmanager”, “Formtool”, “Benutzer Registrierung”, “force https”, “CRUD”, uvm. Plugins dieser Art werden bei jedem zweiten Projekt benötigt und somit auch Projekt zu Projekt weiterverwendet und weiterentwickelt. Auf diese Weise hat sich hier ebenfalls eine Bibliothek an Plugins ergeben, die permanent weiterentwickelt und eingesetzt wird. Ein Großteil dieser Plugins ist so geschrieben, dass diese mit Hilfe von Adaptern auch losgelöst vom CMS funktionieren, so dass wir diese auch einsetzen können, wenn das CMS selbst nicht zum Einsatz kommt.

• 
  

  Volker Dusch

  am 14. Juni 2010 um 14:09 Uhr

  Hm, interessante Frage. Je nach Projekt ist der Code eigentlich das unspannenste was man so mitnehmen kann.
  *Antwortet mal etwas an der Frage vorbei:*
  Natürlich nimmt man erst mal Erfahrung mit, was funktioniert hat und was nicht.

  Sollte das nächste Projekt mit gleichen Laden mit den gleichen Leuten sein gibt es einige Dinge die man relativ einfach mitnehmen kann: Projektmanagement (wenn es funktioniert hat), Teamstrukturen, die ganzen Coding Guidelines, die CI und sonstige Infrastruktur. Ändern was nötig ist und den Rest beibehalten.

  Was die eigentliche Frage angeht kann ich dem schon geschriebenen auch nichts mehr hinzufügen.

• 
  

  nikosch

  am 14. Juni 2010 um 14:46 Uhr

  “Der Trend scheint wohl zum eigenen Framework zu gehen”

  In der Tat. Obwohl doch immer gerade als Vorteil von fertigen Frameworks gehandelt wird, dass dies nicht mehr nötig ist. Scheint, als hätte die meisten PHP-Entwickler eben mehr Freude am Programmieren, als am Konfigurieren..

  Kurz: eigenes Framework. Ich versuche dabei die Bestandteile eigenständig und modular zu halten, so dass man auch bspw. mal ein herausgelöstes Element wie Validierung oder Formularverwaltung in Fremdprojekten oder gar CMS autonom benutzen kann. Oft passiert dabei eine Code-Review/ein Refactoring, das dann mit ins Framework einfließt. So wird bei jedem Projekt das Framework ein bischen verbessert. Einziger Wermutstropfen ist die Pflege alter Projekte, die noch auf altem Entwicklungsstand herumdümpeln

• 
  

  Dennis Becker

  am 14. Juni 2010 um 15:33 Uhr

  Ich verwende nur das Zend Framework, da ich mir kein eigenes schreiben will

  Ich denke bei den bisherigen Antworten kann man vor allem rauslesen, dass das Framework schon vor einigen Jahren begonnen wurde aus der Not heraus, da es zu dem Zeitpunkt einfach nichts brauchbares gab.

  Würde heute jemand ohne Framework da stehen, sähe die Entscheidung, selber entwickeln oder fertiges nehmen, sicherlich anders aus.

• 
  

  Martin

  am 14. Juni 2010 um 16:10 Uhr

  Ist das eigentlich eine PHP-Eigenheit, dass jeder sein eigenes Framework baut?
  Ich hatte eigentlich den Eindruck, dass existierende Framework schon ziemlich modular aufgebaut sind und sich gut erweitern lassen.
  Eigentlich müsste man dann den Begriff Framework für die genannten Beispiele schon in Frage stellen. Es soll ja eigentlich kein für sich lauffähiges Programm sein. Genau der Eindruck drängt sich aber auf. Eine Masterapplikation die durchaus lauffähig ist und die wird dann geclont für neue Projekte. Meistens wird dann das Nachziehen der alten Projekte “vergessen” und alles läuft schon auseinander…

• 
  

  Martin

  am 14. Juni 2010 um 16:12 Uhr

  Achso was ich mitnehme habe ich vergessen: Ein Kasten Bier für die Fussballpausen und eine Vuvuzela um für die richtige Stimmung in der Entwicklung zu sorgen.

• 
  

  Stephan Hochdoerfer

  am 14. Juni 2010 um 16:47 Uhr

  @Denis: Das stimmt wohl. Heute würde ich sehr wahrscheinlich keine Neuentwicklung vornehmen.

• 
  

  Simon

  am 14. Juni 2010 um 17:03 Uhr

  Nein, meins habe ich entwickelt, weil mir Zend und die anderen großen nicht gefallen haben

• 
  

  klg

  am 15. Juni 2010 um 19:50 Uhr

  @Dennis

  > Würde heute jemand ohne Framework da stehen,
  > sähe die Entscheidung, selber entwickeln
  > oder fertiges nehmen, sicherlich anders aus.

  Nein, nicht unbedingt.

  Vielleicht will man gar kein bloatiges, alles abdeckendes Framework benutzen, sondern eins, das den eigenen Vorstellen und Anforderungen am nächsten kommt.

  Klar, ist etwas Aufwand und muß natürlich auch entsprechend getestet werden, aber die Entscheidung, sich ein individuelles Framework (oder eine eigene Bibliothek) zu bauen, kann durchaus sinnvoll sein.

  Gruß,
  klg

• 
  

  Juan M.

  am 17. Juni 2010 um 21:33 Uhr

  Hi Nils,

  also ich habe einen Mix.

  Basis ist das Zend-Framework, erweitert wird es mit dem eigenen Framework – es ist im Laufe der letzten Jahre entstanden.

  Prinzip: Web-App benutzt eigenes Framework, Eigenes Framework benutzt Zend-Framework

  Warum Zend als Basis?
  Viele neue Klassen ermöglichen flexibles Handeln, dokumentierte Funktionen und Beispiele ermöglichen schnelle Ergebnisse. Festgelegte Applikation-Struktur und das dynamische Laden der Klassen je nach Gebrauch, gefällt mir einfach … und warum das Rad neu Erfinden, wenn es schon jemand getan hat?

  Warum eine eigenes Framework?
  1. Zend-Framework verändert sich, man kann das eigene Framework anpassen wenn Zend sich ändert ohne die Application zu verändern.
  2. Zentrale Pflege, wenn ich mehreren Projekten die gleichen Funktionalitäten bieten möchte, Update ich nur das Eigene Framework auf dem jeweiligen Server.
  3. Sicherheit: Ich kann mir vorstellen das die Leute von Zend darauf achten, aber ich möchte noch eine Stufe höher, wo ich es im Griff habe, was die App verlässt und bekommt.

  Auf der IPC ’09 habe ich übrigens überzeugen können, dass es einige Firmen so machen.

  Grüße, Juan

• 
  

  Igor

  am 20. Juni 2010 um 17:02 Uhr

  Was mich noch interessieren würde:
  Version 1.0 deiner Base-Lib ist jetzt in Projekt A entstanden.
  In Projekt B hast du Version 1.1 deiner Base-Lib fertig gestellt (die Lib wurde erweitert, Fehler korrigiert, optimiert – das übliche eben).
  Das geht so weit, bei Projekt Z bist du quasi bei Version 26.0

  Bringst du das Update auch bei Projekt A wieder ein oder wird Projekt A quasi für immer mit Version 1.0 arbeiten?

  Wenn ja, machst du das automatisiert? Pflegst du deine Lib gesondert? Oder kopierst du immer das Verzeichnis mit, so dass die jeweilige Version im SRC des Projektes lebt?

• 
  

  Stephan Hochdoerfer

  am 20. Juni 2010 um 17:31 Uhr

  @Igor: Ich glaube das kann man nicht pauschal definieren. Aus eigener Erfahrung kann ich sagen dass es keinen Sinn macht alte Projekte ständig nachzuziehen. Haben wir anfangs versucht, aber es macht auf Dauer keinen Sinn da viel zu aufwändig. Bugfixes müssen natürlich nachgezogen werden, das ist klar und passiert quasi automatisch. Die Lib wird dabei gesondert in einem eigenen Repository in den unterschdl. Versionen gepflegt. Auch hier kann ich sagen dass das manuelle Kopieren bzw. Syncen auf Dauer viel zu aufwändig und fehleranfällig wird.

  Beide Fragen sollte man sich natürlich auch dann stellen wenn man ein öffentlich verfügbares Framework verwendet. Der einzigste Unterschied ist dass Dritte das Management/Bugfixing übernehmen und man selbst quasi nur das Ergebnis konsumiert.

• 
  

  fchriis

  am 22. Juni 2010 um 14:34 Uhr

  Ich schreib meistens Anwendungen für das WCF (Woltlab Community Framework), daher stellt sich die Frage nach dem Framework garnicht

  Für standalone-Projekte nutz ich.. naja, Framework kann man dazu nicht sagen. Es ist eine Sammlung von Klassen und Funktionen, die ich mal ausgegliedert hab.

RSS Feed für Kommentare zu diesem Artikel. TrackBack URL

Hinterlasse einen Kommentar