Symfony2 retour sur expérience et remise en question sur l'efficacité du framework
J'ai déjà publié un article (un peu rapide) sur ce que l'on entendait d'un "puissant framework", cet article met surtout l'accent sur la "simplicité d'un framework". Car un framework complexe ne veut pas dire plus puissant. Et aujourd'hui je remet sérieusement en doute le choix de symfony2 comme framework de développement pour de gros projets ou quand bien même le choix de certaines entreprises.
Symfony2 est-il le bon choix de framework aujourd'hui en 2013 ?
J'ai fait une bref analyse du pourquoi ou non choisir tel framework en entreprise, comme pour soit si l'on est développeur freelance (fuelphp, symfony2 ou zendframework).
Cela va faire presque un an que je travail avec symfony2 dans mon entreprise, sur une grosse application de gestion de publicité en fullajax, multilingue, système de calendar étendu pour la gestion des types de publicités, gestion ACL étendu etc.... A la longue même si l'on gagne en expérience sur l'outil avec lequel on développe, dans notre cas, le Framework Symfony2 (version 2.1.8 on n'a toujours pas migré vers la version 2.2 car nous avons suffisamment rencontré de problème qui ralentissait considérablement les délais que nous avions annoncés à nos clients), On vient fréquemment à se dire "ha merde on aurait du architecturé plutôt comme ça".
Car à force au niveau de la maintenance cela devient vite ingérable. Je ne viens pas dire ici qu'il aurait fallu plus s'orienter vers un CakePHP ou Zendframework, mais je vais expliqué un peu plus en détails là où sensio (symfony2) merde un peu encore une fois sur leur framework.
Brèf petit comparatif afin d'expliquer pourquoi ne pas avoir choisi certain framework du moment (au moment où il nous fallait trouver une techno framework php).
Pourquoi ne pas avoir choisi :
ZendFramework :
- Zenframework2 sortait mais la version n'était pas encore stable
- La version 2 de Zendframework n'apportait pas une réel grande différence ou de nouveautés tel que l'on pouvait les attendres (Mais ça n'est pas plus mal ! Zend doit rester tout de même différent de symfony ou autre framework car la qualité des librairies de zend n'ont pas à être remises en doute c'est certain)
- Par rapport à l'attente de certaines entreprise selon le projet que l'on choisi de faire Zend n'était pas le framework le plus recommander pour que nous l'utilisions
- Trop de conception architectural à mettre en place avant le développement concret de l'application (donc trop de dev en plus et nous n'avions pas le temps de faire toute la migration)
CakePHP v2.x :
- Le framework même en version 2 ne bénéficiait pas de performance suffisante afin de porter notre choix dessus
- Bien que ayant déjà développé de mon côté sur CakePHP, bien que j'apprécie assez ce framework, bien que l'architecture déjà mise en place afin de gérer le développement de nos propres modules à des fins réutilisable soit déjà en place. Je trouve l'architecture trop imposé à ce que l'on cherche et nos besoins.
- CakePHP est pas mal, mais lorsque l'on connait d'autres framework tel que Zend, Symfony, Laravel, FuelPHP ou encore CodeIgniter (pour des petits et moyen projet j'ai réalisé un fork de codeigniter avec un système d'autoloading à la zend), on trouve que ce dernier est un peu trop rigide et dépendant d'une convention à la base de donnée (bien plus stricte que sous Syfmony2 d'ailleurs).
- Donc récapitulatif pour ne pas avoir choisi CakePHP, manque de performance, architecture trop stricte, dépendance trop stricte pour fonctionner avec la base de donnée déjà en place et impossible de faire une migration les coûts seraient trop important avec les anciennes versions.
Yii Framework :
- Puissant framework tout autant que ceux cités ci-dessous
- pas assez de documentation clair et avancé (si on veut faire un simple blog avec les fonctionnalités basique, on trouve toujours la doc qu'il faut, mais lorsqu'il s'agit de savoir comment utiliser la librairie du framework de façon avancé, il y a peu de framework qui propose la doc hormis symfony ou zend framework (aujourd'hui ;))
- courbe d'apprentissage longue à priori donc le jeu n'en valait pas la chandelle
Notre choix de framework s'est donc porté sur Symfony2
Dont la philosophie de modularité avec les Bundles sur le papier et en pré théorie était vraiment remarquable il est vrai. Mais à la longue et en réalité... Le bute de tout framework (et de n'importe quelle application sérieuse aujourd'hui) est de diminuer les coûts de maintenance n'est-il pas vrai ? Et bien avec Symfony2 on s'est aperçu quand même que nous avions et que nous perdions trop de temps sur la maintenance de bug du à l'implémentation d'un bundle tiers, l'apprentissage d'un nouveau bundle, où des changements très contraignant d'un upgrade à une version même mineur.
Je ne vais pas énumérer tous les problèmes que nous avons rencontré car certain je ne m'en souviens plus et pour d'autres cela va grossir l'article pour rien et j'ai pas envie de vous endormir avec. La grosse problématique avec Symfony2 je trouve est que l'on a l'impression que l'on n'a jamais finit d'apprendre et de mettre son nez dans la doc, où à la recherche d'informations sur la toile car il est impossible de trouver facilement une information "importante" sur le site même de sensio.
On se rend compte tout de même que la philosophie que tout est Bundle dans symfony2 est bien, mais que l'on passe par des chemins et des fichiers incessant pour arriver à quelque chose bien souvent je trouve.
Avec l'arriver des des namespaces de façon stable en implémentation depuis PHP5.3 > (je ne sais plus exactement quelle version du build) et surtout pour PHP5.4, Sensio ainsi que d'autres concepteur de framework autant pour zend & co on revue leur système d'autoloading afin d'implémenter plus simplement nos développements sur de grosses applications.
Notamment au lieu de faire sous zend framework des controllers ou module (même pour symfony old version) zend_admin_untruc_encoreuntruc_profile, des nom de class à rallonge on peut maintenant utiliser les namespaces ! 
Qui permet effectivement sur de gros développement, d'éviter la collision de nom de class.
Sensio l'on dit eux même, "grâce aux namespaces cela évitera les noms de class à rallonge"...
Hummmm... Dois-je rappeler que dans symfony2 pour appeler un bundle tiers ou existant nous sommes obligé de faire appelle au namespace comme cela :
use Symfony\Bundle\FrameworkBundle\Controller\Controller;
Et il y a plus long ! Bien sûr on peut utiliser des alias etc... mais très franchement à la longue sur une grosse application ça peut devenir le gros bordel car on aura oublié "merde ce bundle faut que je l'appelle comme ça plutôt" etc...
Ou est donc la différence entre un nom de controller par exemple à rallonge séparé par des underscores et l'appel d'un namespace à rallonge ? Allez voir du côté de fuelPHP vous verrez la logique est plus simple et plus logique
Avec Symfony2 pour faire certaines actions de façon simple on est obligé de passer par une logique de path très franchement, très contraignante et chiante à la longue.
Qui plus est (bien ou pas bien) on peut choisir d'effectuer les Route par exemple de façon différente xml, php, yaml ou annotation et j'en passe pour d'autres types de fonctions services & co. En ce qui concerne Composer, pour mettre à jour et bien installer des bundles tiers c'est bien beau en ligne de commande, mais des fois on aimerait aussi pouvoir les installer de façon simple et manuellement dans symfony sans passer par composer et là aussi c'est compliqué sans prendre le temps de se pencher sur composer et comment symfony gère cela. Et cela demande là encore un temps à investir.
Nous avons rencontré et du corriger le code de façon "importante" je dis bien, sur des upgrade de version "minieur", je le répète rien qu'au niveau des version de symfony 2.1.0 à 2.1.8 (je ne vous dit pas lorsque symfony 2.2 est sorti comme on a tremblé rien que de se dire si on faisait la migration ou non, on s'est dit tout compte fait qu'on ne le ferait pas pour le moment et certainement pas encore bien longtemps !).
Nous avons aussi rencontre des problèmes lors des commandes php app/console upgrade moi mes bundles ! Là aussi ce fut, je ne vous cache pas LA MERDE.
Si l'on additionne tous ces temps passé à corriger le code, le nez dans la doc, chercher sur le blog de symfony qu'est ce qui avait changé (mais non il n'y avait pas tout le temps l'information il fallait allez chercher l'url sur github ! et ouvrir le fichier changelog ! comme c'est top j'adore lire ces petites info dans des fichiers texte), tel que les gestions des formulaires, la gestion des langues, les fichiers qui ont disparus etc...
Et bien le constat et que nous aurions pu passer plus de temps à développer notre application plutôt qu'à la débugger et comprendre symfony2 (tiens ça fonctionne plus pareil ce module faut revoir nos développements).
C'est certain que lorsque l'on a l'habitude et que l'on travail seul ou bien avec un collègue qui a la même philosophie que vous en organisation architectural (si ce dernier a suffisamment d'expérience en intégration et en javascript jquery c'est mieux) ça n'est pas un problème. Mais lorsque vous êtes plusieurs avec des expériences différentes, des niveaux différents, des tendances de compétences différentes (car on ne peut pas demander à tout le monde d'être polyvalent sur des métiers du web)...
Et bien une application sous Symfony2 est vraiment galère à maintenir et vous avez plus l'impression de passer votre temps dans la doc et faire des petites modifications de codes par ci et par là.
Pourquoi ne pas se diriger plutôt vers de nouveaux framework php ?
Et bien car le marché de l'entreprise fonctionne comme les internautes geek sur le web ! Ils fonctionnent par mode ! Les framework en france à la mode sont Zendframework et Syfmony. voilà ce que l'on voit le plus sur les offres, alors que comme je l'avais dit dans un billet précédant, bien des entreprises n'ont nullement besoin d'utiliser tel ou tel framework pour des applications, qu'ils jugent grosse attention ! Mais qu'il en est tout autre.
Je trouve très franchement que sensiolab aurait pu mettre en place la philosophie de leur framework, c'est à dire Bundle, d'une façon dix fois plus simple ! Vous lisez la doc de symfony2 on voit sur certain chapitre des paragraphes qui où il va être dit "symfony gère cela de façon très simple", fréquemment que cela soit sur des blogs indépendants aussi. Mais mettez bouts à bouts tous ces "symfony gère cela de façon très simple" et bien on se retrouve avec énormément de points qu'il faut ne pas oublier, connaître et maîtriser de sorte à trouver directement ce que l'on cherche.
Lorsque l'on utiliser un framework, cela doit être simple et non compliqué, on ne doit pas au bout de un an avoir l'impression qu'il nous reste encore beaucoup à apprendre du framework. Si l'on regarde sur le marché d'autres framework conjuguant les même performance (voir l'article ici) autant choisir le framework qui sera le plus simple en apprentissage non ?
Un développeur et bien il veut développer et pas passer son nez dans la doc d'un outil à chaque fois. Bien sûr il y aura certainement les développeurs qui viendront dire "bah autant développer ton framework", ce à quoi je réponds "Ha Ha ha..." Je n'ai pas encore suffisamment les compétences pour développer mon framework afin qu'ils aient le niveau équivalent d'un symfony2, fuelphp ou autre et que j'ai rencontré, je lis et j'en vois encore, des développeurs prétentieux qui préfèrent développer leurs propre cms ou framework alors qu'ils n'ont aucune connaissance en SEO par exemple, ou bien on une très faible connaissance en intégration aussi. Et je ne vous parle même pas de question de sécurité ou bien de performance ;). On a tendance à souvent derrière ces développeurs pour corriger d'une, leurs erreurs de programmation, d'architecture ! ou bien déjà passer le cape de la compréhension de leur code. Non mais cher amis, utiliser un cms ou un framework correcte développé par des développeurs professionnels ayant plus de recul et d'expériences sur certaines problématiques que certain n'ont pas, n'est pas une tare ! C'est une question de bon sens (faut savoir mettre son égaux ailleurs).
Vous vous mettez sur Laravel ou FuelPHP le développement, la compréhension est pus rapide, plus simple, plus logique ! Attention je ne considère pas Laravel comme un framework aussi puissant que FuelPHP, Symfony2 ou Zend encore, mais je site juste ce framework car on peut tout de même développer une application d'une plus ou moins grande envergure avec Laravel.
Conclusion:
Je me rends compte à force de développer sous Symfony2 qu'ils auraient pu architecturer leur framework de façon bien plus simple et moins fourre tout ! Il y a une grosse différence avec Symfony1 c'est certain mais c'est quand même encore fourre tout je trouve, les upgrade ont mal été géré notamment au niveau de composer (ça a été corrigé à priori sur la version 2.2 mais bon c'est trop tard). Je me rends compte qu'en terme de coût et maintenance on en a perdu plus de temps qu'autre chose en développant sur Symfony2 et que malgré une connaissance suffisante aujourd'hui sur symfony et le fait de tester d'autres "nouveaux" framework php me tant à m'orienter et chercher à maîtriser un autre framework.
En gros avec Symfony je pense que l'on ne pourra jamais maîtriser ce framework sans s'y donner à temps plein, chose que beaucoup de développeur (me suivront sur ça) ne peuvent pas se permettre car on nous demande de connaître beaucoup de technologie et que l'on va se centrer sur certains CMS, quelques framework, quelques langages etc... C'est déjà beaucoup de temps à investir. Sensio ne changera pas là dessus et je crois qu'il devrait s'orienter et mettre l'accent plus sur la "simplicité utilisateur" plutôt que de chercher à faire croire "symfony c'est simple" dans leur propre logique.
Nous sommes hélas pieds et poings liés en fonction des tendances technologiques que les entreprises vont choisir (et bien souvent les responsables ou développeur qui vont faire ce choix technologique n'ont pas non plus suffisamment d'expérience en la question).
Bien que Symfony (sensio) soit un vecteur de tendance en matière de pratique de développement, que sensio soit aussi un précurseur sur bien d'autres approches, au niveau du développement sous framework, je pense aujourd'hui que symfony2 et les versions qui suivront ne sont pas l'ultime choix technologique en soit ! Et qu'il faut plus s'inspirer de la philosophie de FuelPHP et de ses développeurs et donc chercher d'autres solutions aussi puissante mais plus stable et plus simple à mettre en oeuvre.
Donc je dis By Symfony et bonjour FuelPHP (en espérant que fuel grandisse et fasse encore plus d'écho dans l'avenir).
Commentaires
Merci pour ce retour d'expérience, c'est instructif.
Pour ma part, j'ai déjà utilisé yii (1.1.x). Son probleme est surtout les extensions des contributeurs qui ne sont pas toujours très bien faites et j'envisage sérieusement de me mettre a Symfony, ne serait-ce que pour ne pas passer pour un alien et être un peu plus main stream...
Bref, tout ça pour dire que je suis curieux de ton retour d'expérience sur FuelPhp (je l'ai testé très rapidement et ça ne m'avais pas poussé a l'utiliser plus (doc inssufisante dans mon souvenir)).
@Seb, A force avec symfony2 il faut trouver une manière de s'organiser sans pour autant suivre obligatoirement le système des updates, je pense que le mieux est de s'arrêter sur une version stable, voir certaines mises à jours si elles sont importantes on lest faits, si non on reste sur sa version. Car Si non cela devient un véritable merdier en terme de maintenance de sa propre application sur des problématiques d'update propre à symfony2 ou de bundle tiers.
Je développe sous Laravel4 et Fuelphp1.7, j'ai aujourd'hui un très bon recule sur ces deux framework et je peu dire sans conteste que Fuelphp est plus puissant que Laravel4. Non pas sur le fait de son code, mais sur les besoins actuels des outils à notre disposition afin de développer de gros projets.
Les Gros framework que sont ZendFramework2 ou Symfony2 sont là pour cela, et à contrario j'évalue donc les autres frameworks tel que Laravel4 ou bien Fuelphp aux gros frameworks cité au début.
J'aime beaucoup Laravel, mais il manque certaine choses de bases tout comme Fuelphp qui font que pour le moment je ne pourrais pas réellement dire qu'ils jouent dans la même court que Syfmony2 ou un Zendframework.
Gros point noir que j'ai soulevé aux deux communautés tel que laravel ou fuelphp, la gestion des formulaires qui n'est pas assez poussés. Le système de validation. Tout cela dans le cas où l'on se retrouverait sur "une application web" à proprement parler qui inclus donc de nombreux formulaires. J'ai donc étendue en respectant les nomenclatures des deux frameworks, afin d'avoir un code mieux organisé en ce qui concerne les formulaires, la validation des champs et leurs traductions.
La doc de Fuelphp est très bien fait je trouve, elle me rappelle celle de codeigniter, j'ai réussi à me débrouiller et faire presque tout ce que je voulais rien qu'avec la documentation, mais je peux comprendre que certaines personnes auraient sans doute plus besoin d'un "How to" plutôt qu'une simple Doc. C'est ce que les développeurs de Fuelphp compte faire pour la version 2 de Fuel, un peu à la manière de Sensiolabs et Symfony2.
C'est bien et pas bien à la fois. La doc de Fuelphp est très simple à lire et clair comme l'était celle de Codeigniter, et c'est plutôt rare de voir cela. Tant dis que la Doc de Syfmony2 est abondante en terme de How To mais pas du tout en terme d'API si je puis dire. Lorsque tu cherches les paramètres de certaines méthodes ou class dans Symfony2 c'est une réel galère. Les deux seraient mieux mais bon, lol on ne peut pas tout avoir.
Bien que très complexe, Symfony2 nous en apprends beaucoup, bien que je développe professionnellement sous symfony2, je pense aussi aux autres développeurs qui viendraient par la suite, et le bute d'un framework n'est pas de passer son temps le nez dans la doc à chercher mais à développer son application.
Aujourd'hui je peux arriver à un résultat similaire d'application tant avec Laravel4 et Fuelphp que sous Symfony2 en terme de grosse application. Par contre sous Laravel il faudra étendre certaines choses, non pas sur le Coeur du framework, mais quelques oublient qui n'auraient pas du y avoir. Mais Laravel progresse très vite, et ils parlent bientôt d'une version 5 qui viendrait à sortir.
Ce que j'adore dans Fuelphp, c'est que c'est simple, qu'ils ont "presque" tout prévue, template controller, modularité, controller générique.
Que l'on peut plus ou moins, facilement intégrer n'importe quel moteur de template ! Et c'est c'est tout de même un véritable plus, que l'on peut si l'on souhaite utiliser des fichiers de configurations php, ini, json, xml ou encore yaml. Car sous Symfony2 je trouve ça très CHIANT les fichiers yaml alors que bien souvent afin de mieux différencier les choses en php, nous avons le format de fichier ini dont le parser est déjà inclus dans les dll de php.
La syntaxe des fichiers ini est véritablement simple à lire à l'inverse de ce que sensio aimerait bien faire croire avec la soit disante clareté du langage Yaml alors que ça ne l'est en rien du tout ! C'est sûr les fichiers yaml permettent un peu plus de polyvalence dont l'inclusion de variable. Mais pourquoi s'emmerder franchement ?
Pour moi, un fichier de paramétrage ne doit servir qu'à paramétrer point barre, et non inclure des variables dynamique en valeur.
L'être humain est bien plus habitué à lire un fichier de haut en bas, c'est bien plus lisible plutôt que de lire un fichier transverse, car des fois les fichiers yaml peuvent s'étendre sur trop de cascades. C'est une affaire de goût après, mais il faut garder à l'esprit de rester le plus simple possible tant pour la maintenance que pour le travail qui pourrait être repris par un autre.