Présentation de Symfony 4 avec Nicolas Grekas

Fin 2017, lors du SymfonyCon Cluj, Fabien Potencier présentait Symfony 4 : la dernière version du framework professionnel PHP le plus téléchargé au monde.

Mise à disposition le 30 novembre dernier, cette nouvelle version s’annonce comme la plus simple d’utilisation, la plus flexible et la plus puissante depuis la création du framework et promet de réinventer l’expérience de développement des utilisateurs.

Nicolas Grekas, membre de la core team Symfony, nous présente plus en détails les nouveautés et les avantages apportés par Symfony 4 pour les développeurs, les projets et les entreprises.

Présentation

Symfony 4, une version plus automatisée

Symfony 4, une nouvelle façon de fonctionner en mode projet

Bonnes pratiques pour aborder la migration sur Symfony 4

Monter en compétences et acquérir l’expertise Symfony 4

symfony-4-sensiolabs

Présentation

SensioLabs : peux-tu nous présenter les principaux changements apportés par la nouvelle version ?

Nicolas Grekas : Je dirai de Symfony 4 que c’est une nouvelle façon de développer, beaucoup plus simple, pour les développeurs qui devaient très souvent faire certaines tâches de manière répétitive. C’est particulièrement le cas pour la configuration : à chaque fois qu’on définit ce qu’on appelle un service, il faut (en Symfony 3) modifier un fichier de configuration en miroir des changements faits dans le code. Cela induit de la lourdeur à l’écriture, mais également à la maintenance (par exemple tout renommage dans le code nécessite aussi d’aller voir la configuration pour dire : « j’ai renommé ces parties du code »). Dans Symfony 4, de nouvelles fonctionnalités permettent d’automatiser complètement la configuration pour l’usage commun.

Pour résumer : avant Symfony 4, il fallait être explicite pour que la configuration soit bonne ; il fallait tout dire à Symfony sous forme de configuration pour que Symfony puisse fonctionner. Désormais, au lieu d’être explicite au détail près, on est explicite par lots : on exprime des conventions, et tout ce qui entre dans le cadre de la convention sans y déroger est configuré automatiquement.

Symfony 4, une version plus automatisée

SensioLabs : Peux-tu préciser ce qu’est une convention dans Symfony 4 ?

Nicolas Grekas : Prenons un exemple, en voici une commune : « pour toutes les classes de mon application qui vont avoir besoin d’un logger, leur passer le logger par défaut disponible de base dans Symfony ». On peut évidemment modifier et remplacer le logger en question au cas par cas, sans autre configuration. Cette règle suffit généralement pour la majorité des cas. Dans Symfony 3 il fallait configurer les classes une par une pour préciser quel logger leur passer (souvent le même).

De même, par exemple, il fallait configurer N fois la langue par défaut d’une application pour les N services qui en avaient besoin. Il est maintenant possible de dire : « pour tous les services qui ont besoin de la langue par défaut, voilà la valeur à donner », en rédigeant la convention.

Qui dit « convention » dit également « exceptions ». Dans Symfony 4 il y aussi une manière d’exprimer des cas particuliers pour que la configuration soit explicitement adaptée lorsque nécessaire.

Le but des conventions est de couvrir le cas général, tout en permettant de passer outre si besoin. Le résultat est une configuration concentrée à l’essentiel.

SensioLabs : À quoi correspond Symfony Flex ?

Nicolas Grekas : Flex participe à l’expérience Symfony 4 dont on parlait plus tôt. Il y a deux niveaux d’automatisation dans Symfony :

Tout d’abord, la configuration du code par convention, apportée par Symfony 4.

Ensuite, l’automatisation du branchement des dépendances de son code. Les bundles Symfony sont des fonctionnalités mises à disposition par la communauté (ou en interne), et sont réutilisables sur plusieurs applications différentes. Ces fonctionnalités ont également besoin de configuration, en particulier lors de l’installation de chaque nouveau bundle. C’est cette configuration-là qui est apportée par Flex. Nous avons commencé un travail d’inventaire de toutes les recettes de configuration d’un maximum de bundles de la communauté. Cette base de connaissance permet à quelqu’un qui veut utiliser (ou juste tester) un de ces bundles de pouvoir le faire sans effort : Flex s’occupera de fournir la configuration par défaut nécessaire.

SensioLabs : Peux-tu nous préciser cette automatisation et le fait que le code soit dorénavant « bundle-less » ?

Nicolas Grekas : Bundle-less ne signifie pas que l’application ne consomme plus de bundles. La nuance est que désormais les bundles ne sont plus que pour du code tiers. Avant, dans Symfony 2 et 3, les applications étaient elles-mêmes des bundles.

Mais coder un bundle dans son application imposait d’écrire du code très spécifique pour l’intégration avec Symfony lui-même. Ce code n’avait que peu de valeur ajouté métier, mais il était indispensable, induisant un dette technique inutile. Dans Symfony 4, ce bundle intermédiaire n’est plus nécessaire, on conseille donc de le supprimer de l’application. Cela fait du code de l’application un pur code métier, moins spécifique à Symfony dans l’architecture même de l’application.

Une nouvelle façon de fonctionner en mode projet

SensioLabs : A quel moment d’un projet ces nouveautés prennent-elles le plus d’ampleur ? Quels sont les principaux avantages de Symfony 4 pour les projets ?

Nicolas Grekas : Les nouveautés apportées par Symfony 4 s’appliquent sur toute la vie du projet ! À une époque (alors que l’aventure Symfony 4 était balbutiante), la configuration automatique était considérée par certains comme une bonne approche sympathique pour les débutants, mais dont les plus expérimentés allaient s’éloigner au fur et à mesure de leur montée en compétences. Parce qu’ils n’en voyaient pas l’intérêt et qu’ils considéraient que c’était juste un facilitateur, une béquille, dont ils n’avaient pas besoin. À vrai dire, rien de permettait de dire qu’ils avaient tort à cette époque.

Cependant on s’est rendu compte, à force de pratique, qu’en fait les développeurs experts gagnaient également en productivité, mais que cela nécessitait un changement de paradigme, un changement de façon de penser sa configuration. En interne, lorsque nous avons opéré la migration vers Symfony 4 de Blackfire.io, les développeurs séniors qui étaient sur le sujet n’étaient pas convaincus par l’intérêt de cette « béquille pour débutant ». À la fin de l’exercice, après avoir compris comment appréhender cette nouvelle pratique de développement, ils étaient totalement conquis !

C’est un réel changement dans la productivité des développeurs. La maintenabilité du projet est également amélioré puisqu’on a fait diminuer le volume de fichiers de configuration. Cela veut dire qu’il est beaucoup plus facile d’entrer dans le projet et qu’il est plus facile à faire évoluer. C’est le bénéfice du raisonnement par convention et l’automatisation qui s’en suit.

Cela fait donc gagner du temps au développeur. Une des headlines phare de Symfony 4 est « keep you at coding as long as possible », c’est-à-dire que les allers-retours entre le code et la configuration sont très largement réduits et cela entraine un gain de temps considérable pour le développeur.

SensioLabs : Et au niveau des fonctionnalités, qu’est-ce que la nouvelle version va changer ?

Nicolas Grekas : Symfony 4, est encore plus performante que les versions précédentes ; plus adaptée au cloud aussi. Symfony est parfaitement à l’aise pour être déployé sur les plateformes de conteneurs, comme notamment SensioCloud, en mettant en œuvre les meilleures pratiques pour y parvenir.

Par exemple dans la gestion des secrets – une problématique récurrente – la plupart des développeurs utilisent les variables d’environnement pour configurer les applications qu’ils déploient. Or on s’est aperçu récemment que ce n’était pas forcément pour le meilleur : ces variables fuitent trop facilement. Il vaut mieux maintenant mettre ses secrets dans des fichiers virtuels exposés par des plateformes comme Docker.

Logiquement, Symfony est désormais capable de lire dynamiquement ces fichiers à l’exécution, ce qui n’était pas possible avant. De façon plus générale : une application Symfony est compilée : on crée son conteneur et les caches associés une fois pour toute. Toute la configuration qui pouvait exister dans les fichiers devait être lue au moment où on compilait l’application, sans pouvoir changer par la suite. Désormais on peut compiler l’application en y laissant des « trous », qui sont remplis à l’exécution. Cela permet un meilleur déploiement sur les applications Cloud.

Bonnes pratiques pour aborder la migration pour Symfony 4

SensioLabs : Peux-tu nous indiquer les bonnes pratiques pour réussir à opérer sa migration vers Symfony 4 ?

Nicolas Grekas : Une migration entre Symfony 3 et 4 est à la fois différente et similaire à une migration entre Symfony 2 et 3. Il a deux grandes étapes pour la faire complétement.

1. Comme pour une migration Symfony 2 à 3, la transition Symfony 3 à 4 repose sur les mêmes bases : les fonctionnalités dépréciées ont été retirées, il faut donc s’assurer qu’elles ne sont plus utilisées avant de migrer. La même application qui tourne en Symfony 3, débarrassée de toutes ces fonctionnalités obsolètes tournera sur le code Symfony 4, même si la configuration n’est pas mise à jour et reste à « l’ancienne mode ». Cette étape de migration est obligatoire. Cependant on n’est qu’à la moitié de l’expérience Symfony 4, on n’exploite pas encore le nouveau système de configuration.

2. La deuxième étape consiste donc à adopter la nouvelle configuration en écrivant les conventions essentielles recommandées par le framework. C’est aussi à cette étape qu’il est généralement conseillé d’ajuster la structure de répertoires pour l’aligner sur celle du nouveau squelette Symfony 4 et ainsi bénéficier de tout l’outillage associé sans effort.

Ces deux étapes se font dans l’ordre que l’on veut. Il est tout à fait possible de migrer d’abord en Symfony 3.4, puisque cette version contient toutes les fonctionnalités nécessaires à la mise en œuvre de la nouvelle configuration.

Monter en compétences et acquérir l’expertise Symfony 4

SensioLabs : En termes de formations à Symfony 4, quels sont les aspects les plus importants à traiter ?

Nicolas Grekas : Il sera désormais plus facile de commencer sur Symfony. Avec la nouvelle expérience de développement, il est plus facile d’avoir des résultats positifs sans devoir d’abord comprendre comment fonctionne les systèmes de configuration. Le framework est donc plus ouvert, sa courbe d’apprentissage devrait être plus douce au démarrage, permettant à des personnes moins expérimentées de réaliser des prototypes plus aisément.

Cependant, il ne faut pas oublier que ce sont des nouvelles fonctionnalités qui permettent ces simplifications. Les fonctionnalités préexistantes sont toujours là. Donc le parcours d’apprentissage nécessaire pour être expert passe forcément par la maîtrise des versions précédentes. Un développeur débutant commencera par être expert Symfony 4 puis Symfony 3 et 2, puisque le cœur est fondamentalement très similaire.

SensioLabs : Pour obtenir la certification Symfony 4, il faut donc avoir des fortes connaissances sur les versions précédentes ?

Nicolas Grekas : Absolument, la certification Symfony 4 nécessitera de connaître les fonctionnalités (non dépréciées) des versions précédentes.

Conclusion

SensioLabs : Pour résumer, quels sont les avantages de Symfony 4 pour les entreprises ? 

Nicolas Grekas : Tout d’abord, il est plus simple de débuter sur Symfony 4, la réalisation de prototypes ainsi que l’obtention des résultats est facilité.

Pour les experts, la flexibilité apportée par Symfony 4 leur permettra de perdre moins de temps sur les configurations, et de se concentrer sur le code métier.


Vous souhaitez monter en compétences sur Symfony 4 et cherchez la formation la plus adaptée à vos besoins ? Contactez-nous à l’adresse jonathan.sam-mouiy[at]sensiolabs.com ou consultez directement notre offre de formation à Symfony 4 sur notre site sensiolabs.com