Pourquoi Symfony est-il si compliqué ?

Je travaille avec Symfony depuis la version 0.6.3, le framework a énormément évolué depuis en prenant un virage résolument professionnel. A vrai dire, je suis un peu bluffé par l’endurance de la « core team », qui, à peine la 1.2 sortie, embraille sur la 1.3.

Selon moi, un tournant assez improbable et important a été effectué lors de sortie de la version 1.1. A ce moment là plusieurs personnes se sont senties un peu contrariées par la nouvelle verbosité de l’API. La coupe fut pleine quand le système de formulaire fut complètement refait, passant de l’écriture de fichiers de configurations à des classes PHP. Le travail avec le framework a beaucoup changé depuis la version 0.6. Si la lecture de la documentation (pléthorique) reste indispensable j’ai constaté que les développeurs ont maintenant souvent le nez plongé dans l’API ou lisent fréquemment les classes. D’ailleurs, ne pas leur permettre d’y avoir accès directement depuis l’IDE est impensable. Un autre point révélateur, le générateur d’admin est de moins en moins cité dans les argumentaires promouvant Symfony ; on parle plus de l’architecture ou de la souplesse du framework. Depuis la version 1.1, le framework Symfony est donc perçu comme encore plus difficile à prendre en main.

Et bien je suis d’accord, certaines choses méritent que l’on retrousse les manches pour elles. J’ajouterais donc ces éléments :

  • Coder une classe offrira toujours plus de possibilités qu’écrire un fichier de configuration (voila, c’est dit).
  • Les classes PHP permettent une meilleure organisation de la logique métier (via les classes abstraites par exemple). Ces dernières peuvent lire des fichiers de configuration sans problèmes. Faire un système de gestion de formulaires basé sur des fichiers de configuration aussi puissant que celui de Symfony 1.2 me parait assez difficile.
  • La documentation permet tout de même un démarrage très rapide et efficace. Toutefois, les prérequis ont évolué pour les développeurs : adieu les bidouilleurs et bonjour les pros. Au final, pour eux, mettre le nez dans le code est un réflexe assez naturel au bout de quelques semaines.
  • Le découplage du framework est primordial. Les entreprises ont des besoins bien spécifiques et pourvoir remplacer un morceau de Symfony par le sien, sans forker le projet, est vraiment une killer feature. Symfony réussi parfaitement sur ce point et selon mes informations, la plupart des grands compte utilisant Symfony le font. Imaginer, démarrer en utilisant les fonctionnalités standards puis en changer quelques points à votre sauce simplement en modifiant un fichier !
  • Symfony se propose d’être un outils à destination des professionnels ; autour de moi, par exemple, il y a une dizaine de personnes faisant du Symfony à temps plein, autant dire que cette équipe trouve très vite les limites de la documentation utilisateur, ils ont du mettre les mains dedans et lire une API ne leur fait pas peur !

Symfony est donc adapté si votre objectif est son utilisation sur le long terme et implique de nombreuses autres personnes. Dans le cas contraire je vous conseille Code Igniter 😉 (ou la lecture du livre blanc de Clever Age pour vous aider à choisir un framework).

De mon point de vue, l’aspect « framework professionnel » est complètement couvert par Symfony et cela passe par une courbe d’apprentissage un peu plus longue. Si je comprend que la version 1.1 ait pu frustrer, elle me paraissait nécessaire afin d’arriver à maturité – et malheureusement oui, c’est compliqué.

Finalement, je pourrais ajouter que faire un framework peu puissant mais facilement abordable serait un non sens pour Sensio, la société derrière Symfony. En effet, une partie de leur business model inclut de l’expertise autour de Symfony. Cette expertise doit nécessairement ne pas être trop facile à aquérir.

Publicités

9 réflexions au sujet de « Pourquoi Symfony est-il si compliqué ? »

  1. Loïc

    Bonjour,
    Je trouve que la complexité « nouvelle » du symfony nouveau est d’abord liée à un problème de documentation qui est arrivée très tardivement avec la 1.2 finale(jobeet, propel doctrine, mise à jour intensive de la doc, des cookbooks).
    Il y a eu un vide assez difficile à comprendre entre la 1.0 et la 1.2, notamment au niveau des tutoriaux, vide d’autant plus difficile à comprendre que les documents accompagnant la 1.0 étaient de superbe qualité (merci F.Z.), probablement un des facteurs qui a propulsé Symfony dans les communautés de codeurs.
    Petit soucis de pédagogie donc.
    Ensuite, je trouve dommage que l’on oppose les système de configuration (type yaml) à l’utilisation des classes, cela n’a rien à voir.
    Bien sûr, les classes sont plus puissantes, mais l’écriture d’un fichier de configuration peut faire gagner en production un temps incroyable. Reste à se mettre d’accord sur la structure du / des fichiers de configuration, les moyens de les surcharger etc… ou simplement à développer son propre fichier de configuration (au niveau de l’entreprise) en fonction des besoins les plus courants à couvrir.
    Enfin, ce n’est pas parce qu’il y aurait un modèle de fichier de configuration qu’il faudrait obligatoirement l’utiliser, le fort découplage et la souplesse des dernières versions de sf permettent de choisir le bon outil en fonction du travail à réaliser.
    Loïc

    Répondre
  2. Jug

    Bonjour,

    De mon point de vue, Symfony 1.1 (et donc 1.2) est devenue trop compliquée… à cause de la framework interne des formulaires. Le reste étant resté identiquement difficile ;). La courbe d’apprentissage est très importante, et elle devient tout de suite abrupte.

    Attention ! Je ne remets pas en cause l’utilité et la « puissance » de cette framework interne de formulaire… Une telle framework est tellement essentielle que j’en avais développé une perso pour Symfony 1.0.

    Mais…

    Vous verriez la tête de mon intégrateur web quand il est l’heure de mettre en page un formulaire. Je suis obligé d’être derrière lui pour lui dire où se trouve tel ou tel champs, de quel fichier XyzForm.class.php découle le $formulaire qu’il manipule et quels options ou attributs passer à l’infâme $this->widgetSchema[‘xyz’].

    Pour quelqu’un qui n’est pas censé savoir faire du PHP (mais de l’HTML/CSS)… Dur!

    Je rejoins aussi Loïc sur le point des fichiers de configuration… Dans 99% des cas, on se contente de faire widgetSchema->setLabel(‘x’,’y’),
    widgetSchema->setHelp(‘a’,’b’) et validatorSchema[‘z’] = new sfValidatorLookInApiForName( array(/*options*/), array(/*messages*/));

    Honnêtement, un fichier de configuration peut faire tout ça ! Et mon intégrateur n’aura plus peur de « casser » le code de ma classe XyzForm

    Pour finir, je ne pense pas que la classe sfForm doive être responsable de son affichage… Pourquoi aller changer la valeur des labels dans la classe TrucForm ? Pourquoi dois-je choisir le « FormFormatterName » dans une classe PHP ? (ou dans l’action).

    Imaginez un instant que la classe Article de votre modèle soit responsable de son affichage via un classe qui s’appelle : sfPropelModelFormatterTable. Une classe qui ne serait pas documentée. L’angoisse, non ?

    Remarque, c’est super : dans le viewSuccess, on met juste un et voilà! C’est l’intégrateur qui va être content…

    Bref ma conclusion -vous l’aurez compris – est la suivante : Nous avons perdu la conception MVC dans la framework des forms. Et c’est dommageable.

    A bientôt,
    Jug

    Répondre
  3. Olivier Mansour

    @Jug, de mon coté, les personnes manipulant les formulaires n’ont pas à savoir comment il est codé mais à les utiliser.

    Ton problème vient peut être du fait que tu estimes que c’est ton intégrateur qui doit fabriquer le formulaire, hors symfony a estimé que c’était du ressort du développeur.

    Personnellement j’estime que justement, le nouveau système de formulaire permet de conserver MVC.

    Répondre
  4. Arno

    Hello, moi je suis un admin reseau/système et j’ai toujours fait un peu de php pour faire des petits outils ou tester/utiliser des cms, mediawiki, etc.

    Depuis 1 an, symfony me permet d’aller beaucoup loin simplement avec quelques lignes de commandes et quelques fichiers conf avec le super systeme yaml+quelques plugins (sfGuard).

    Rien qu’avec la doc et les tuto, on peut aller déjà très loin et facilement pour construire un site web avec une personnalisation qui répond à nos besoins.Ce que ne peut pas nous offir les autres systemes opensource (wordpress,DRUPAL,plegg,etc)

    De plus, les bonnes pratiques MVC,AGILE,STORY BOARD etc sont toujours présentes pour autoformer un débutant dans le développement.
    J’espère d’ailleurs que l’admin generator de symfony 1.3 intègrera du jquery facilement afin d’améliorer l’expérience utilisateur.J’ai pas eu le courage de me lancer ds sfYUI…

    La tache la plus difficile est de savoir si on veut aller plus loin, cad lire la nouvelle doc sur les forms,propel ou/et doctrine, et se plonger dans l’api !

    Pour répondre au titre de l’article, je trouve que symfony facilite déjà beaucoup la production de site web pour n’importe quel informaticien de base.
    Bref, un must de l’opensource !

    j’espère un nouveau livre pour la 1.3.

    Sur ce je continue le tuto jobeet ;-

    Répondre
  5. dreur

    Bon article,

    Pourquoi ne pas choisir Zend ?
    Il est tout aussi professionnel (plus ??)

    La raison ? Et bien symfony permet de faire du RAD (Rapid application development) cependant plus la complexité augmente plus il devient difficile de vraiment penser au RAD.

    Cependant, je crois que pas mal d’effort on été mis dans sf1.2 avec toute la doc (c’est fantastique !!) et les exemples, et jobeet …
    et c’est une excellente chose.

    Tellement excellente que j’ai peur de me faire dépasser dans ma connaissance de sf par des nouveaux venus qui travaillent avec la nouvelle doc alors que moi je suis plus occupé à développer(Avec mes connaissances actuelles) qu’à me documenter.

    Mais bon, Vive sf
    Pour ReTweeter qqn : Damn Symfony is so sexy 🙂

    Répondre
  6. Hugo

    Je viens ajouter mon grain de sel à ce billet. Je suis entièrement d’accord sur tout ce qui est dit. L’arrivée de la version 1.1 de symfony a véritablement changer la donne en faisant passer le framework du stade de « semi pro » à professionnel. La 1.0 était déjà très bien à l’époque mais c’était clair que le YAML à outrance et le système de formulaire étaient horribles, ce qui finalement était davantage un casse tête à écrire et une perte de temps. Je me rappelle encore quand je me prenais la tête à écrire mes formulaires. Il y’avait du code dans tous les sens…

    Le découplage des classes du framework, l’arrivée du framework de formulaires et la nouvelle architecture REST ont vraiment donner un sens professionnel à Symfony. Certes la documentation entre la 1.1 et la 1.2 a été relativement absente mais elle tend à présent à s’étoffer et se mettre à jour.

    Pour moi, Symfony n’est pas plus compliqué à apprendre qu’avant. Je dirai même que c’est plus facile aujourd’hui avec la 1.2 pour la simple et bonne raison qu’il y’a beaucoup moins de « magie » derrière les outils de Symfony. On sait exactement où se trouve chaque composant et comment il se comporte. En 1.0, l’utilisation abusive du YAML pour faire de la validation de formulaires était une aberration totale qui apportait son lot de magie et qui au final était une difficulté supplémentaire à gérer. C’est tellement plus simple d’écrire un message d’erreur dans la configuration d’un validateur d’un widget plutôt que dans un fichier YAML dans lequel il faut faire attention à l’échappement, l’indentation…

    Toujours concernant la courbe d’apprentissage, je m’aperçois que de moins en moins de développeurs décrochent au début de l’apprentissage. Est-ce parce que c’est plus simple à apprendre ou bien parce qu’il y’a un côté fun, pro et sérieux à utiliser symfony ? Sincèrement je ne saurais répondre à cette question mais le constat est tel que je pousse de plus en plus de développeurs issus du monde PHP traditionnel à se tourner vers symfony, et ceux-ci arrivent à être opérationnels avec l’outil assez rapidement. Le tutoriel Jobeet et le form book actuel contribuent pour beaucoup à l’apprentissage de symfony et c’était exactement le cas à l’époque d’Askeet de la 1.0.

    Pour moi, les développeurs qui décrochent de symfony rapidement et qui pensent que c’est trop compliqué, c’est qu’ils n’ont pas encore réussi à laisser de côté leur habitudes de codage en PHP traditionnel. Symfony est et reste du PHP à la base, donc tout ce qu’il est possible de faire en PHP est possible dans Symfony. Cependant, et c’est le but d’un framework, Symfony oblige de penser un projet et le code qui l’accompagne différemment. Pour y arriver et comprendre comment fonctionne la logique globale de symfony, il faut être capable de laisser de côté ses vieilles habitudes de codage en PHP et se mettre à penser MVC, OOP et bonnes pratiques.

    Hugo.

    Répondre

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s