Sensio a publié ce lundi un livre blanc, très attendu, sur les bonnes pratiques pour le développement Symfony. Les premiers retours de la Communauté sont divergents, notamment à cause de l’introduction du document, qui commence par jeter le discrédit sur une partie des “Bonnes pratiques” poussées jusque-là par la Communauté (Richard Miller explique très bien les causes de ces réactions virulantes).
Si quelques propositions font figure de bon sens, d’autres tiennent plutôt du parti-pris (l’utilisation d’Assetic, par exemple) et certaines s’inscrivent carrément à contre-courant des pratiques courantes.
Par exemple, l’idée de déplacer tous ses templates dans le dossier App peut paraître saugrenue au premier abord. Mais elle devient très logique si on lui adjoint une autre recommandation : celle de n’avoir qu’un seul Bundle AppBundle par application. On lit alors entre les lignes qu’une “bonne” application Symfony est surtout une application orientée “Services” et que la couche présentation, elle, est située au cœur de l’application. Un point de vue défendable, mais pas nécessairement très consensuel auprès des développeurs de la Communauté.
De même, l’usage des annotations est recommandé dans les contrôleurs et les entités. Cela permet d’éviter de parcourir des tonnes de fichiers dans des formats différents pour trouver une information. Donc d’une part on nous demande de découpler la logique métier du framework, pour ensuite aller injecter, au sein même de cette logique, des annotations que le framework utilise pour interpréter les usages qui en sont faits. Cela semble contradictoire… Comme pour d’autres recommandations, c’est au final une question de goûts et de couleurs. Certains développeurs trouveront plus simple d’avoir tous leurs fichiers de configuration dans un seul répertoire, dans un seul format. D’autres préféreront avoir toutes les informations sous la main au moment où ils manipulent leurs routes, entités… ou documents (Doctrine ODM). Tout cela dépend de nombreux facteurs liés au contexte du projet, à la culture des équipes, à la maturité technique de l’équipe qui sera chargée de la maintenance, aux objectifs de réutilisation…
Or l’impression majoritaire qui ressort de la lecture de ces Bonnes Pratiques est qu’elles ne s’adressent qu’à un seul type de projet, alors que la Communauté est justement caractérisée par son éclectisme. Même au sein de Clever Age, nous ne sommes pas parvenus à un consensus. Certains d’entres nous, habitués à produire des applications Symfony liées à des besoins figés ou de petits périmètres, pensent pouvoir mettre en place rapidement ces recommandations. D’autres, qui ont l’habitude de construire de véritables architectures modulables dont les composants sont réutilisables, les trouve plutôt limitantes.
Autant de questions qui trouveront probablement leurs réponses quand la contribution au document sera ouverte et qu’il sera possible d’y définir non plus une vérité unique mais bien des bonnes pratiques adaptées à des contextes techniques et fonctionnels particuliers. Nul doute qu’il deviendra alors le support de débats intéressants, qui ne feront qu’enrichir la très bonne couverture documentaire du framework.
En attendant, il est bon de rappeler que ces « Bonnes Pratiques » sont facultatives, comme l’indique Sensio :
Keep in mind that these are optional recommendations that you and your team may or may not follow to develop Symfony applications. If you want to continue using your own best-practices and methodologies, you can of course do it. Symfony is flexible enough to adapt to your needs. That will never change.
Samuel Martin
15 octobre 2014
Plus généralement, avoir une méthodo et s’y tenir. Les bonnes pratiques métiers feront difficilement consensus tant l’écosystème de projets est différent. C’est d’ailleurs très bien expliqué dans l’article.
La solution est de maitriser l’ensemble des recommandations, d’être capable de prendre du recul, d’être capable d’aller contre une bonne pratique en connaissance de cause, et enfin de faire son choix, à la carte avec son équipe pour chaque projet.
Maitriser pour mieux oblitérer les bonnes pratiques.
shady
16 octobre 2014
Juste pour rappel, un point semble avoir était oublié par la communauté symfony, il s’agit d’une « early preview release ». Partant de ce constat, effectivement le document n’est pas complet, mais c’est clairement indiqué :/
Hugo Hamon
19 octobre 2014
Bonjour,
Merci pour ce retour qui donne une vision objective et externe à ce livre de bonnes pratiques. Le véritable but de ce recueil des bonnes pratiques décrites par Fabien (ainsi que Javier et Ryan), c’est de permettre à des développeurs PHP de rapidement monter en compétence sur Symfony et se sentir capables de produire des applications métier qui fonctionnent. Aussi il est bon de rappeler que ces bonnes pratiques s’inscrivent dans une démarche d’écriture d’applications propriétaires. Les bonnes pratiques pour écrire du code que l’on souhaite mettre à disposition de la communauté sont quant à elle complètement différentes. En effet, écrire du code pour l’Open Source doit au contraire favoriser la généricité, le découplage, l’extensibilité, la surcharge et l’intégration avec plusieurs librairies tierces. Sans parler des problématiques de « Backward Compatibility » à garantir une fois que le code a été ouvert.
Dans ce livre, il s’agit simplement d’une vision très pragmatique de l’usage de Symfony visant à simplifier la complexité perçue par les nouveaux développeurs et leur permettre d’être efficaces. L’expérience que nous avons acquise dans la formation ou bien dans l’audit montre souvent que les développeurs cherchent trop à vouloir découpler, modulariser ou rendre les parties de leur application extensibles et configurable sans que cela n’apporte réellement de valeur ajoutée à leur code. Au contraire, cela amène généralement de la complexité et de l’abstraction inutiles au projet. À trop vouloir coller aux « bonnes pratiques » fondamentales du paradigme orienté objet et du génie logiciel, les développeurs en viennent à perdre leur pragmatisme et produisent des usines à gaz in-maintenables.
La vision de Fabien retranscrite dans cet ouvrage de « ses bonnes pratiques à lui », c’est de simplifier le développement afin de rester le plus pragmatique possible et délivrer des applications dans les temps. Symfony est un framework avant tout professionnel destiné à développer des applications métier sur mesure.
Pour simplifier l’apprentissage de Symfony et le temps de développement avec ce framework, il s’agit par exemple de diminuer la quantité de fichiers à manipuler ainsi que la profondeur des différents namespaces et répertoires. C’est aussi encourager le couplage fort avec le framework (usage des annotations, étendre la classe Controller de base, entités Doctrine dans les bundles…) s’il n’y a aucun véritable besoin qui justifie réellement le découplage entre les composants. Quand on compare d’autres frameworks populaires de l’écosystème PHP comme Laravel ou Silex, on comprend vite pourquoi ils ont du succès :
– ils sont simples à apprendre,
– ils offrent une grande liberté d’architecture,
– ils permettent de produire des fonctionnalités rapidement,
Ce sont des frameworks qui s’inscrivent dans une démarche pragmatique et Symfony ne devrait pas être plus compliqué que Silex ou Laravel à apprendre. C’est pour cette raison que Fabien souhaite montrer au travers de cet ouvrage que produire du code avec Symfony c’est facile et ne requiert pas forcément de lire une pléthore de documentation et installer un IDE.
Je pense que beaucoup de personnes dans la communauté ont perçu cet ouvrage comme LA manière de faire ou bien comme une attaque aux bonnes pratiques fondamentales de génie logiciel. Il n’en est rien ! Ce n’est qu’un recueil de bonnes pratiques qui visent à donner une ligne directrice pour celles et ceux qui veulent utiliser Symfony avec une approche purement pragmatique. De plus, ces « bonnes pratiques » ne sont en aucun cas contradictoires avec une démarche qualité du logiciel. Il s’agit toujours d’encourager les pratiques de « fat models / thin controllers », de services métiers et de tests automatisés.
Au final, malgré les quelques remous que l’annonce de cet ouvrage a provoqué dans la communauté Symfony, chacun est libre de suivre ou non ces conseils en fonction des ses propres besoins. Nous sommes tous dotés d’un cerveau ! Utilisons le pour analyser, réfléchir et prendre les bonnes décisions techniques qui s’imposent en fonction du contexte. Les bonnes pratiques sont aussi faites pour être transgressées quand elles n’apportent aucune valeur ajoutée à l’application. PHP a cet avantage d’être extrêmement permissif et pragmatique que d’autres langages ; par conséquent, transgresser les bonnes pratiques quand il le faut devient aussi plus facile !