Editions ENI Livres | Vidéos | e-Formations
Introduction
Avant-propos
L’évolution constante de la technologie transforme considérablement notre manière d’obtenir et d’échanger des informations au quotidien. De ce mouvement permanent naît une certaine fragilité, et il n’est, par exemple, pas rare de voir un smartphone dernier cri devenir obsolète en l’espace d’une année.
Internet n’échappe guère à cette règle ; en quelques années, nous sommes passés de sites web aux pages statiques à des sites dynamiques et interactifs, reliés aux réseaux sociaux ainsi qu’à différents systèmes externes. Les applications mobiles sur smartphones et tablettes ont élevé cette évolution à un niveau encore supérieur.
Travailler ou lancer un projet à destination du Web n’est donc pas une tâche aisée. Cela nécessite souplesse, adaptabilité et réactivité à toute épreuve pour pouvoir surfer sur la vague du progrès sans se noyer !
Au travers de cet ouvrage, nous verrons comment Symfony peut nous aider à relever ce défi.
Public visé
Ce livre s’adresse aux développeurs, chefs de projet, directeurs techniques ou, plus largement, à toute personne souhaitant apprendre à industrialiser ses méthodes de programmation avec PHP.
En plus des avantages qu’il apporte à votre projet (comme la maintenabilité et la vitesse de développement), l’apprentissage d’un framework constitue un apport pédagogique indéniable. Des concepts comme l’architecture applicative ou les design patterns (modèles de conception) sont disséqués. Ces concepts ne sont pas spécifiques à Symfony ou à PHP, mais peuvent être appliqués pour n’importe quel projet, quel que soit son langage de programmation.
Symfony est un framework très répandu dans le monde professionnel et même les sociétés ne l’utilisant pas apprécient les développeurs ayant une connaissance d’un framework, cela leur garantit un certain niveau de rigueur et de qualité de conception. Pour un développeur PHP, avoir des compétences Symfony sur son CV est un avantage indéniable.
Prérequis
La lecture de cet ouvrage nécessite certaines connaissances techniques.
Vous devez maîtriser la programmation orientée objet avec PHP et tous ses mécanismes : classes, classes abstraites, interfaces ainsi que les espaces de noms.
Il est recommandé d’avoir une bonne connaissance du Web en général, de la manière dont le navigateur, le serveur web et l’application PHP interagissent entre eux, autour du protocole HTTP, avec une requête et une réponse.
L’utilisation de lignes de commandes sera incontournable, vous devez donc savoir comment ouvrir un interpréteur de lignes de commandes (une invite de commandes sous Windows ou un terminal sous Linux) et effectuer des tâches basiques comme naviguer vers un répertoire ou interpréter un fichier avec PHP.
Certains de ces prérequis seront évoqués au cours de cet ouvrage, mais notre but n’est en aucun cas de vous former à ces derniers. L’objet d’étude principal sera toujours Symfony.
Objectifs du livre
Notre objectif est de vous apprendre à développer avec le framework Symfony, mais également de vous présenter des bonnes pratiques et des outils complémentaires à ce dernier.
Il est important que vous suiviez les chapitres dans l’ordre. Ils ont été organisés de manière progressive : la compréhension d’un chapitre donné requiert souvent la lecture d’au moins l’un des chapitres précédents.
Nous avons choisi de faire en sorte que tous les exemples de code soient basés sur la construction d’une application complète. Même s’il ne s’agit pas réellement d’une approche de type « tutoriel », cela permet de raccrocher plus facilement les notions des chapitres précédents au sujet en cours. Tous ces exemples de code sont à votre disposition en téléchargement sur le site des Éditions ENI.
Les chapitres commencent toujours par une approche théorique (concepts, définitions de termes, etc.) avant d’aborder la partie pratique. Si vous vous sentez dans le flou en abordant un chapitre, rassurez-vous : des exemples concrets vont rapidement suivre.
Lorsque nécessaire, nous expliquons le fonctionnement interne de certaines parties du framework. Le but n’est pas de vous inonder d’informations...
Le développement avec les frameworks
1. Complexité des développements et productivité
Depuis le début des années 1980, l’explosion des capacités des machines informatiques a fait que l’on veut toujours leur en demander plus. Et c’est bien naturel… Seulement, cela induit de fait une complexité des applications et des développements qu’il faut pouvoir maîtriser. L’apport de la programmation orientée objet et des méthodologies de conception associées ont permis de donner les clés pour pouvoir appréhender cette complexité ; néanmoins le processus conduisant à un produit fini et fonctionnel est long et semé d’embûches.
Au-delà du codage proprement dit, les activités de modélisation et conception, tests, intégration et livraison interviennent dans le projet et sont outillées. En modélisation, par exemple, nous utilisons fréquemment le langage UML (Unified Modeling Language) afin de schématiser le projet sous ses divers aspects ; les tests possèdent de leur côté des outils facilitant leur écriture et leur exécution. Il est donc tout à fait normal que l’activité de codage puisse également bénéficier d’outils de productivité.
a. Productivité et qualité logicielle
Il est évident que la productivité ne doit pas se faire au détriment de la qualité des logiciels produits. Aujourd’hui, la démocratisation des campagnes de tests logiciels permet d’augmenter cette qualité en mettant en avant ces différentes catégories de tests : tests unitaires, d’intégration, fonctionnels, de performance et de sécurité. La mise en œuvre de ces tests dès le début du processus de développement permet de détecter les problèmes, et donc de les corriger, au plus tôt : plus un problème est identifié rapidement, moins il coûte à solutionner. Le retour des utilisateurs ou des clients constitue également un axe d’amélioration de la qualité : le « feedback » apporté permet de savoir si l’on converge correctement vers les fonctionnalités demandées. Il faut donc tester souvent pour corriger rapidement, et livrer souvent pour obtenir un retour fréquent ; les plateformes d’intégration et de livraison continues vont en ce sens.
b. Intégration et livraison continues
L’intégration continue est un processus automatisé réalisé par un automate (serveur d’intégration continue tel que Jenkins, par exemple), consistant à construire un logiciel à partir de son code stocké dans un dépôt central (Git, par exemple), à en exécuter les tests et à produire un rapport envoyé aux équipes de développement. La livraison continue fonctionne de la même manière mais concerne la mise en production ou préproduction des livrables considérés comme finalisés ou, tout du moins, exploitables par les utilisateurs finaux.
2. Particularité des développements en PHP
Avec un outillage adapté pour la productivité et la qualité, les développeurs disposent de moyens idéaux pour avancer sereinement sur leurs projets ; reste la question du langage de programmation utilisé. Tous les langages ne sont pas égaux en matière d’apports méthodologiques et de bonnes pratiques, loin de là.
a. Contexte historique de PHP
Le premier objectif du langage PHP au moment de sa création en 1995 était de permettre le développement rapide de sites web dynamiques. Les développements PHP mélangent donc au sein des pages et scripts, code HTML pour la présentation, règles métier et requêtes SQL pour l’accès aux bases de données. Aucune séparation des responsabilités en composants, donc une faible évolutivité des développements réalisés. Peu d’importance à l’époque : les sites web sont amenés à faire peau neuve souvent et comme on code rapidement, ça ira vite… Voilà une idée de l’état d’esprit général de l’époque.
De ce fait, les considérations de modularité, réutilisabilité et maintenabilité n’étaient clairement pas au centre des préoccupations avec un impact direct sur la pertinence de ce langage pour développer des applications métier.
Initialement, PHP est un langage procédural et, même si quelques notions objets étaient présentes, il faut attendre la version 5 en 2005 pour voir un vrai modèle objet être ajouté au langage, soit dix ans après sa création.
Dix années d’habitudes de développement procédural dans une démarche non structurée ont établi une manière de développer encore aujourd’hui bien ancrée ; il suffit de voir certains tutoriels présents sur Internet pour s’en rendre compte… PHP n’était donc pas très bien parti pour être considéré comme un langage sérieux auquel on pouvait confier la complexité d’une application métier.
b. Évolutions
La démocratisation de l’approche objet dans les langages actuels a permis de voir apparaître de plus en plus de bibliothèques orientées objet pour PHP, impliquant un usage de cette approche avec le langage et forçant à considérer plus globalement le modèle objet et ses apports dans les applications, l’apparition de frameworks apportant un point final à cette démarche.
Progressivement, l’outillage disponible dans des langages concurrents, tels que Java par exemple, a fait des émules dans le monde PHP et des déclinaisons de bibliothèques, outils de test et de gestion de projets, environnements de développement intégrés, et enfin, frameworks, ont finalement vu le jour et été adoptés par les développeurs PHP, remettant ainsi en question des années d’habitudes, mais...
Symfony
1. Historique
Au commencement, Symfony est un ensemble de composants PHP créé en 2005 par Fabien Potencier au sein de la société SensioLabs. Il sera initialement nommé Sensio Framework, avant d’être rebaptisé Symfony. Ce nom est choisi avec l’idée de conserver les lettres S et F du Sensio Framework.
L’objectif initial pour SensioLabs est tout simplement de factoriser des fonctionnalités indispensables à chacun de leurs développements au sein de Sensio Framework. L’idée de faire profiter la communauté de développeurs PHP de ce framework viendra dans un second temps, en 2007. Symfony est distribué depuis ses débuts sous une licence MIT libre et open source, ce qui implique que les applications développées avec Symfony peuvent être commercialisées sans restriction.
La première version de Symfony a une durée de vie assez longue et ne laisse la place à Symfony2 qu’en juillet 2011. Cette seconde version casse la compatibilité avec la précédente et améliore grandement la productivité des développements. Chaque version majeure de Symfony introduit ensuite une incompatibilité avec les versions précédentes ; ainsi même si la version 3, en novembre 2015, reprend les concepts de Symfony2, il faudra migrer les applications existantes vers cette nouvelle version. Symfony 4, qui sort en novembre 2017, a pour principal objectif de simplifier la structure des projets en abandonnant notamment le principe de « bundle » jugé finalement inadapté. Symfony 5 voit sa première version publiée en novembre 2019. Les nouveautés de cette version se concentrent essentiellement sur l’amélioration de la sécurité et des performances, on constate ainsi un gain moyen de 7 % par rapport aux versions précédentes.
Enfin, Symfony 6, la version couverte par cet ouvrage et qui est publiée en novembre 2021, n’apporte pas réellement de grosses nouveautés pour le développement. En effet, cette version se focalise sur deux aspects :
-
le support de PHP 8 ;
-
la suppression du code marqué comme déprécié depuis de nombreuses versions.
C’est une version préparatoire indispensable avant la sortie de Symfony 7 qui apportera des nouveautés conséquentes. Le passage à Symfony 6 depuis des versions antérieures nécessite donc de nettoyer son code des fonctionnalités dépréciées.
La première version à support à long terme de Symfony 6 est la version 6.4, sortie en novembre 2023. La notion de version à support à long terme est évoquée plus loin dans ce chapitre.
2. Gouvernance et gestion des versions
a. Les versions
Il existe plusieurs versions de Symfony et chacune est composée de trois nombres, séparés par des points (ex. 6.4.6). Ces trois valeurs correspondent respectivement aux versions MAJOR, MINOR et PATCH du framework :
-
La version PATCH est mise à jour pour les corrections de bugs.
-
La version MINOR est mise à jour lors de l’ajout de nouvelles fonctionnalités.
-
Une nouvelle version MAJOR est créée lorsque Symfony ne peut assurer la rétrocompatibilité d’une nouvelle version du framework avec tous les projets fonctionnant correctement sur l’ancienne version.
On appelle ces règles le « versionnage sémantique » (http://semver.org/) ; elles vous permettent de mettre à jour Symfony (ou plus largement, d’autres dépendances de votre projet) en toute sécurité, en évitant les incompatibilités. Symfony les applique depuis sa version 2.3.0.
Ainsi, en passant de la version 6.4.0 à la version 6.4.1 de Symfony, vous obtiendrez uniquement des corrections de bugs. En passant de la version 6.3.1 à la version 6.4.2, vous aurez accès à de nouvelles fonctionnalités. Par contre, en passant à la version 7.0.0 (Symfony 7), des parties de votre code deviendront probablement incompatibles avec la nouvelle version et nécessiteront des modifications.
Ces règles ne sont pas seulement appliquées par le framework, mais par toutes les dépendances de votre projet (section require du fichier composer.json), dans la mesure où leur développement est rigoureux. Avant d’ajouter une quelconque dépendance, nous vous conseillons de vérifier qu’elle suit bien ces conventions de versionnage.
Les contraintes de version
Grâce au versionnage sémantique, il devient facile de prédire les versions que votre projet acceptera.
La section require de votre fichier composer.json offre de la souplesse sur la version des dépendances. Elle ne doit pas obligatoirement comporter les trois valeurs de la version.
Ainsi, pour Symfony (symfony/symfony), vous pouvez...
