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.
