Don’t reinvent the squared wheel – The “Symfony” way

Lesetipps

1. Reinvent the squared wheel
2. Don’t reinvent the squared wheel – Die Elbphilharmonie
3. Unit testing symfony plugins with php unit

Heute habe ich mal wieder vor mich ein wenig aufzuregen. Und zwar geht es um die Art und Weise, wie Sensio das Rad immer wieder neu erfinden. Wer es nicht weiß, Sensio ist die Firma hinter dem Symfony Framework. Deswegen auch die Überschrift.

Wenn man sich mal ein wenig mit der Firma beschäftigt, dann fällt einem auf, dass sie anscheinend sehr gerne Dinge neu erfinden. Und das nicht nur einmal, sondern öfters. Fangen wir mal an, mit den Dingen, die mir bekannt sind.

Framework

Ok, das ist fies. Symfony ist echt eines der besten Frameworks auf dem Markt und hat bestimmt seine Existenz verdient. Trotzdem haben sie sich hingesetzt und haben für ihre Arbeiten ein „eigenes“ System entworfen.

Unit Test

Tja wenn man entwickelt, dann muss man auch testen. Was nehmen wir denn am besten zum Unit Testing? Ihr meint phpUnit? Nein. Wir schreiben einfach ein neues System namens Lime. Das ist bestimmt eines Tages viel besser als phpUnit. Halten wir uns an xUnit Standards? Ne auch nicht. Finde ich relativ daneben den Ansatz.

Continuous Integration

Ich hatte ja mal vor kurzem einen Artikel geschrieben das Unit Testing nichts wert ist ohne CI. Dazu stehe ich auch immer noch. Ich würde auch sagen, dass es da mit Cruise Control und phpUnderControl sehr gute Systeme gibt, die man nutzen kann. Nein Sensio macht da selbst was intern und verwendet dies.

Pear Channel

Software will ja auch ausgerollt werden. Der PEAR Installer löst da sehr viele Probleme. Das haben auch die Jungs hinter Symfony gedacht und haben sich gleich mal einen eignen PEAR Server gebastelt, der das Ausrollen unterstützt. Doof, oder?

So das waren auch schon die Fakten, von denen ich weiß. Ich will hier jetzt kein Framework gebashe draus machen. Es geht mir einfach nur drum, dass man, wenn man nicht zufrieden ist mit den Lösungen, die der Markt so bietet, sich doch bitteschön hinsetzt und die existierenden Lösungen aufbohrt (entschlackt). Ist ja schließlich alles Open Source, was ich gerade aufgezählt habe. Damit erspart man sich jede Menge arbeit.

19 Kommentare »

• 
  

  Dennis Becker

  am 7. Januar 2010 um 08:37 Uhr

  Da gebe ich dir vollkommen Recht, gerade wenn solche Projekte schon gut 80-95% meiner Anforderungen unterstützen lohnt es sich eigentlich nicht, viel Geld in die “Neuentwicklung” zu stecken. Für ein fünftel des Geldes hätte man sicherlich bei der Mitentwicklung viel mehr erreicht ….

• 
  

  eFrane

  am 7. Januar 2010 um 08:40 Uhr

  Ich kann dir nur zum Teil zustimmen. An sich stimmt das natürlich, dass man nicht immer das Rad neu erfinden sollte. Andererseits finde ich aber auch, das es ab und an notwendig ist, des Fortschritts wegen.
  Wenn man immer nur alte Projekte aufbohrt landet man irgendwann meist bei einem Featureoverload und keiner hat mehr Lust vorhandene Fehler auszumerzen. Außerdem kann es ja auch sein, dass durch das Neuaufsetzen einer Lösungsfindung für ein Problem bessere Methoden gefunden werden als die bisher vorhandenen. So aus meiner Sicht bei Sensio zum Beispiel mit Doctrine geschehen, was ich persönlich wesentlich praktischer finde als Propel.

• 
  

  Cem Derin

  am 7. Januar 2010 um 09:23 Uhr

  Ich bin für jede phpUnit-Alternative Dankbar. Period.

• 
  

  Ulf Kirsten

  am 7. Januar 2010 um 09:52 Uhr

  Eine grundlegende Sachen die man bei Eigenentwicklungen auch immer bedenken sollte. Einarbeitungszeit! Ein Projekt wird niemals nur von einer Person betreut werden sondern es wird gezwungenermaßen ein personeller Wandel passieren. Setze ich hier auf bekannte OpenSource-Lösungen ist das alles einfacher als propertäre Eigenentwicklungen. Dazu ist natürlich auch der User-Support bedeutend höher was Blogs, Bücher, Tutorials, Diskussionen usw. betrifft.

  @Cem
  Wieso? Was störer / missfällt an phpUnit?

• 
  

  Cem Derin

  am 7. Januar 2010 um 10:03 Uhr

  Allein die Tatsache, dass man es ohne PEAR nicht einfach runterladen kann schließt phpUnit in den meisten meiner persönlichen Projekte aus, denn ich meide PEAR wie der Teufel das Weihwasser. Aber zum Glück kann man phpUnit ja auch ohne PEAR auschecken und benutzen (was ich allerdings alles andere als Benutzerfreundlich finde) – aber selbst dann habe ich immer mit Abhängigkeiten & kaputten Autoloadern oder includes zu kämpfen. SimpleTest ist vielleicht weniger schön Strukturiert, fügt sich dafür aber in jede Struktur nahtlos ein und erfüllt meine Anforderungen stets. Ich würde mich trotzdem über ein “sauberes” & flexibles Unit-Testing Framework freuen, dass nicht nur über PEAR verfügbar ist.

• 
  

  Michael

  am 7. Januar 2010 um 10:18 Uhr

  Du hast noch Ihr tolles Template System Twig vergessen: http://www.twig-project.org

• 
  

  Timo Haberkern

  am 7. Januar 2010 um 10:44 Uhr

  Ein wenig stimmts schon. Allerdings finde ich, dass gerade Symfony von den vielen PHP-Frameworks dasjenige ist, das viele bestehenden Komponenten übernimmt und vergleichsweise wenig neu erfindet.

  Beispiel Datenbank: Beide ORMs (Propel und Doctrine) gab es schon unabhängig von Symfony.
  Beispiel Internationalisierung: Wurde ursprünglich komplett aus Prado übernommen.
  Beispiel E-Mail: Ist Swift-Mailer
  YAML: War ursprünglich auch eine OS-komponente, ist aber mittlerweile was eigenes
  Und vieles andere mehr

  Zum Rest:
  Prinzipiell finde ich es nicht verkehrt, wenn ein eigenes System entwickelt wird, wenn das bestehende nicht den Anforderungen entspricht. So war es bei Lime. Ziel war es ein unkompliziertes und einfaches Unit-Testing zu entwickeln, das dem RAD-Gedanke eher entspricht als PHPUnit. Klar kann man da geteilter Meinung sein, was besser ist. Lime kann funktional natürlich nicht mit PHPUnit mithalten, aber keiner zwingt einen zu Lime. Viele Symfony-User arbeiten mit PHPUnit. BTW: xUnit kommt mit Lime2
  Bei CI hast du auch recht, aber auch hier: Jedem das seine. Sismo ist im Vergleich zu phpUnderControl oder auch Hudson eine Einfach-Lösung, die aber ihren Charm hat, wenn man nicht mehr braucht.

  Wäre doch schlimm, wenn nur noch vorhandene Systeme verwendet würden
  Zum Thema Lime: xUnit kommt mit Version 2. Prinzipiell finde

• 
  

  Marko Gräßlin

  am 7. Januar 2010 um 10:47 Uhr

  Interessant dabei ist, daß meines Wissens ein Teil der Philosophie hinter Symfony ursprünglich war existierende Komponenten zu einem Framework zu vereinen.
  So wurde ein existierender Yaml Parser, mit Propel kombiniert und Prototype als Bibliothek eingebunden.
  Die Entwicklung von Symfony als Framework war sicherlich nicht das Rad neu erfunden. Es hat sehr innovative Ansätze und es gibt bei einigen Gemeinsamkeiten starke Unterschiede zu z.B. Zend Framework.
  Gut nachvollziehbar ist auch die Neuentwicklung des eigenen Yaml Parsers.
  Warum Sensio allerdings auf ein proprietäres Unit Testing Tool setzt habe ich allerdings auch nie wirklich nachvollziehen können. Symfony Anwendungen lassen sich aber auch recht einfach mit PHPUnit testen.

• 
  

  Sebastian

  am 7. Januar 2010 um 11:25 Uhr

  Ich bin da auch eher gespaltener Meinung.

  Zum einen ist es natürlich Richtig, auf Open Source Lösungen zu setzen.

  Zum anderen ist es natürlich so, dass man dadurch weniger Abhängigkeiten hat und somit, wenn ein Open Source Projekt eingestellt wird, man direkt weiter seine eigene Lösung pflegen kann.

• 
  

  Norbert

  am 7. Januar 2010 um 11:47 Uhr

  Grundsätzlich bin ich dafür vorhandene Bibliotheken und Tools zu nutzen, sofern diese gepflegt werden. Auf ein totes Pferd zu setzen ist nicht sinnvoll. Auf der anderen Seite ist aber auch sinnvoll mal etwas neu zu entwickeln, wenn man dadurch einen großen Vorteil hat. Aber man sollte sich an Normen halten. xUnit ist so ein Beispiel. Ich bin der Ansicht, dass die JSRs (Java Specification Request) ein Vorteil von Java sind. Warum kein PSR einführen und Tools dagegen programmieren?

• 
  

  Nils Langner

  am 7. Januar 2010 um 11:54 Uhr

  Also neu erfinden kann auch mal gut sein, Aber nur, wenn es meine Kernkompetenz ist und mein Geschäftsmodell. Wenn ich einfach nur Nutzer bin, dann halte ich es für Schwachsinn.

• 
  

  Ulf Kirsten

  am 7. Januar 2010 um 12:13 Uhr

  @Sebastian
  OpenSource-Projekte können nicht eingestellt werden, da sie eben OpoenSource sind. Es kann sein dass die Community nicht mehr weiterentwickelt, wenn ich aber als großes Framework ein OpenSource-Projekte unterstütze, dann stelle ich meist auch Man-Power zur Verfügung und habe damit auch eine große Community die mir folgt. Die Gefahr bei Eigenentwicklungen ist viel größer dass sie eingestellt werden müssen, da ich eben nicht die Community habe auf welche ich zurückgreifen kann.

  Im übrigen ist für mich Hudson ein lebendes Beispiel von absolut verfehlter Usability. Mir graut es jedes Mal vor irgendwelchen Änderungen.

• 
  

  Christian

  am 7. Januar 2010 um 12:28 Uhr

  Auch ich bin zwiegespalten.
  Timo hat Recht, dass gerade symfony sehr viele vorhandene Technologien einsetzt. Vor allem am Emailsystem wird das deutlich, denn das wurde von einer eigenen Implementierung auf diese OS Komponente migriert (zugegeben ist Fabien jetzt auch gleich dort der Lead Developer..).
  Auch lime kommt nicht einfach aus dem Himmel, sondern wurde von – dem damals in der PHP Welt noch unerfahrenen – Fabien dem Perl Vorbild Test::More [1] nachempfunden. Es ist zwar urspruenglich nicht xUnit konform aber TAP (Test Anything Protocol) [2].
  Und richtigerweise wird Lime 2 xUnit konform sein und lime ist es ab symfony Version 1.3 auch schon.
  Worauf ich hinaus will ist, es gibt unterschiedliche Ansprueche und Ansaetze bei den symfony Eigen Entwicklungen, die durchaus ihre Berechtigung haben. Ob sie in die eigenen Prozesse und Strukturen passen, muss aber nach wie vor jeder selbst entscheiden. Ich habe mich witzigerweise gerade heute mit diesem Thema beschaeftigt. Siehe: http://test.ical.ly/2010/01/07/testen-einer-symfony-applikation/

  [1] http://bit.ly/8KWOT7
  [2] http://bit.ly/2YCbZA

• 
  

  Frank Kleine

  am 7. Januar 2010 um 12:29 Uhr

  Ich finde Deinen Ansatz von der falschen Seite her aufgezogen. Zum einen hat Sensio eine absolut richtige Entscheidung getroffen wenn ihnen die Eigenentwicklung hilft, sich damit entscheidend auf dem Markt von Mitbewerbern zu differenzieren. Die Entscheidung kann doch nicht sein, bei Open Source immer etwas bestehendes zu verwenden, sondern muss aus Firmensicht zwischen zwei Optionen sein:
  a) Ist es Commodity, was wir hier machen? Dann Wiederverwendung bestehender Produkte.
  b) Ist es entscheidend für unser Geschäft? Dann ist die Eigenentwicklung mit hoher Wahrscheinlichkeit die bessere Alternative.

  Zum anderen hätte Sensio auch gar nichts mit Open Source machen müssen, mit Closed Source wären sie sicher auch gut gefahren und würden sich nicht solchen Kommentaren aussetzen müssen. Das sie ihre Entwicklungen als Open Source zur Verfügung stellen ist eigentlich gut: es stärkt den Wettbewerb und bringt neue Ideen in die Open Source Community, die auch wieder in andere Projekte einfließen. So wie ich das mitbekomme, befruchten sich die Symfony- und ZF-Community auch gegenseitig mit Ideen, und da kommt sicher mehr bei heraus, als wenn alle im gleichen Strom schwimmen.

  Insbesondere Dein Beispiel des PEAR-Channels finde ich nicht besonders gelungen. Fabien Potencier hat IMHO sehr gut begründet, warum er einen neuen PEAR-Server entwickelt hat, und die Entwicklung von Pirum ist für mich erstmals der Grund, überhaupt über einen eigenen PEAR-Channel nachzudenken.

• 
  

  Johannes

  am 7. Januar 2010 um 13:22 Uhr

  Ulf Kirsten, Du setzt voraus, dass es eine “Entwicklercommunity” gibt, doch viele Anwendungen haben zwar eine große “Anwendercommunity” aber nur einen einzelnen oder ganz wenige Entwickler.

  Nun reden wir hier über Entwicklertools im PHP-Bereich, da sollte es natürlich der Fall sein, dass die “Anwendercommunity”, die aus PHP-Entwicklern besteht, das nötige KnowHow hat – das stellt aber nicht sicher, dass die sich so aufstellen kann, dass das alte Projekt tragfähig weiterentwickelt wird.

• 
  

  Ulf Kirsten

  am 7. Januar 2010 um 14:43 Uhr

  @Johannes
  Die Alternative ist aber ein eigenes System zu entwickeln was ja dem mindestens den Anspruch haben sollte genauso komplex und funktional zu werden. Damit dies der Fall ist, muss natürlich erstmal viel Arbeit (=Geld) investiert werden. Und wenn man dieses System dann entwickelt, bleibt erstmal alles bei dem Team hängen. Bei einem bestehenden OpenSource-Projekt hat man eine schon existierende Community, die natürlich nicht immer direkt zum Erfolg des Projekts beiträgt, aber oft auch Dokumentationen, Tutorials etc. pp. schreibt. Das macht ein Projekt auch bekannter und verständlicher, was ja eminent wichtig für den Erfolg ist.

  Die Beispiele welche Nils aufgezählt hat, besitzen ja alle gute bestehende OpenSource-Lösungen, so dass die Eigenentwicklungen für mich auf dem ersten Blick keinen Sinn machen. Ich kenne aber Symfony gar nicht, um differenziert beurteilen zu können, ob diese Eigenentwicklungen sinnvoll sind. Obige Punkte gelten aber auch im Allgemeinen (insbesondere für den Punkt man muss sein eigenes Framework entwickelt ). Das bedeutet natürlich nicht dass zwangsläufig Neu-Implementierungen schlecht sind,, man sollte es aber gut abwägen. Tote OpenSource-Projekte helfen natürlich nicht aber phpUnderControl, phpUnit oder PEAR sind alles andere als tot. Im Zend_Framework wurde ja z.B. die Entity-Komponente auch zu Gunsten von Doctrine “geopfert”.

  P.S. Die Diskussion bei Twig hatte ich etwas mitverfolgt und da konnte ich nachvollziehen dass etwas Eigenes entwickelt wurde. Ich kann durchaus beide Ansichten verstehen.

• 
  

  Nils Langner

  am 7. Januar 2010 um 15:23 Uhr

  Ich gebe euch allen Recht irgendwie. Manchmal ist es legitim und auch richtig das Rad neu/anders zu erfinden. Aber ihr müsst dich zugeben, dass es hier überdurchschittlich oft passiert.

  @Frank: Ich glaube nicht, dass eines der genannten Tools geholfen hat Symfony zu dem zu machen, was es ist. Und das ist schließlich ihre Cashcow.
  Dass sie es als Open Source veröffentlicht haben, war auf jeden Fall eine sehr gute Sache. Da stimme ich dir 100% zu.

  Was man Fabien aber positiv zuschreiben muss, ist dass er sagt, dass man nutzen soll was man will. Wenn jemand mit phpUnit besser zurecht kommt, dann nutze es. Deswegen kann man schon mal drüber weg sehen, dass er für sich fast nur Eigententwicklungen verwendet.

• 
  

  Sebastian K.

  am 7. Januar 2010 um 20:18 Uhr

  “[...] sich doch bitteschön hinsetzt und die existierenden Lösungen aufbohrt (entschlackt).”

  Da hast Du natürlich Recht. Nur, dass das nicht auf Symfony/Sensio zutrifft. Im Gegenteil: genau das hat Symfony im Prinzip von Anfang an gemacht, da es – genauso wie Agavi – ein Mojavi-Fork ist. Außerdem ist mit Symfony zum ersten Mal der RAD-Ansatz konsequent nach PHP portiert worden.

  Fabien empfiehlt auch in zahlreichen Tutorials (siehe Jobeet) ausdrücklich den Einsatz Third-Party-Libraries (z.B. Zend Framework). Darüber hinaus macht Sensio einzelne Komponenten standalone verfügbar, was die Verwendbarkeit in anderen Projekten bzw. anderen Frameworks ermöglicht – auch ein Zug pro OpenSource.

  Aber ich bin da wohl als Symfony-Anhänger eindeutig vorbelastet.

• 
  

  septem

  am 9. Januar 2010 um 02:51 Uhr

  Ich stimme Ulf Kirsten überein. Außerdem finde ich, es hat auch etwas mit Kundenbindung zu tun. Was auch der Fall bei Mobilgeräten von Apple, Google und Co. sein kann oder ist.

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

Hinterlasse einen Kommentar