Comme vous le savez tous maintenant, je suis issu d’un cursus technique (si ce n’est le cas, il n’est pas trop tard pour jeter un œil à Qui suis-je ?). Etant développeur avant d’être chargé de projet, j’ai réalisé quelques sites internet en PHP. Bien souvent ce sont les mêmes problématiques inhérentes à PHP qui reviennent : « Le langage est trop laxiste et n’impose pas un cadre suffisant à la production de qualité. », « Certaines tâches récurrentes sont inévitables » ou encore « Des problèmes de performances se font sentir ! Serait-ce nos développeurs le problème ? »
Afin de pallier aux lacunes de PHP, l’équipe dont je faisais partie à décider d’opter pour un Framework capable de couvrir l’ensemble de nos besoins. C’est ainsi que j’ai eu l’occasion d’expérimenter Symfony, un Framework PHP qui propose une multitude d’outils d’aide au développement. Mais ne nous étendons pas là dessus, si vous voulez plus d’informations concernant le Framework en lui-même, je vous invite à consulter le site web du projet Symfony
Voyons maintenant les raisons qui me poussent à affirmer que Symfony est un Framework agile, et qu’il a été conçu afin de faciliter la mise en application de certaines méthodes telles que XP (Extreme Programming). Fabien Potencier, si vous lisez cet article, n’hésitez pas à commenter cette supposition !
L’architecture MVC
Ce modèle consiste à séparer le code en trois couches distinctes à vocations différentes: Le modèle, la vue et le contrôleur. Chaque partie est entièrement séparée et permet donc une réutilisabilité de code de haute qualité. La collaboration au sein du groupe de développeurs en est facilitée par le fait que chaque couche peut être abordée par différents développeurs sans créer de conflits sur un même fichier. Ainsi les tâches sont partagées et chacun sait situer chaque élément du projet.
Revue et qualité de code
Vous allez me dire que la qualité du code généré dépend entièrement de l’équipe dont on dispose. C’est vrai ! Mais il est évident que le cadre que l’on impose à une équipe de développeurs aide grandement à la qualité. C’est pourquoi cette architecture MVC permet d’améliorer grandement sa conception et sa maintenabilité sans pour autant parler de normes de code. Si vous couplez l’architecture avec quelques règles de normage de code, vous obtiendrez alors une application tout à fait pérenne et dont la revue sera aisée par un quelconque membre de l’équipe. D’ailleurs si vous jeter un œil aux classes composant le Framework vous y verrez la rigueur avec laquelle le code a été travaillé, toutes les variables sont nommées de la même façon, les noms de fichiers suivent une règle bien précise, etc.
Le travail collaboratif est possible et fortement conseillé
L’arborescence mise en place lors de la création d’un projet avec Symfony, nous fait dire qu’elle a été pensée pour le travail collaboratif. En-effet, la répartition des modules est gérée toujours dans un souci de qualité et réutilisabilité de code dans d’autres projets par exemple. Tout y est structuré de façon à ce qu’une équipe puisse travailler sans en impacter une autre qui développerait un autre module.
Afin d’amplifier encore l’impact du Framework sur vos projets je vous conseil donc de l’utiliser avec un gestionnaire de configurations tel que SVN (si vous ne savez pas ce qu’est SVN, je vous invite à lire l’excellente introduction à SVN d’Olivier Dolbeau. Cet outil facilite la collaboration par des équipes travaillant sur plusieurs sujets à la fois, sur les mêmes fichiers ou encore pour des équipes offshore. Enfin, il permet de garder un historique de toute version d’un fichier.
Tests unitaires et tests fonctionnels
Certaines méthodes préconisent l’utilisation du TDD (Tests Driven Development).
Le cycle préconisé par TDD comporte cinq étapes :
- Ecrire un premier test ;
- Vérifier qu’il échoue (car le code qu’il teste n’existe pas), afin de vérifier que le test est valide;
- Ecrire juste le code suffisant pour passer le test,
- Vérifier que le test passe,
- Puis refactoriser le code, c’est-à-dire l’améliorer tout en gardant les mêmes fonctionnalités
Symfony met en œuvre des fonctionnalités d’automatisation de tests unitaires et de tests fonctionnels.
Les versions applicatives
La mise en place de versions logicielles dites de pré-production pour assurer les démonstrations de fin d’itérations est simplifiée. Ainsi l’intégration continue peut s’opérer dans les meilleures conditions, et nombreux sont les projets dont cette étape se passe dans la douleur…
Gain de temps considérable
Le développement est plus rapide grâce aux classes Symfony: Avant il fallait une multitude de lignes pour pouvoir se connecter à une base et récupérer des données. Maintenant une simple déclaration de variable suivi de l’appel d’une méthode suffit!
Exemple: $vente = VentePeer::retrieveByPK(10); // Récupération de la vente stocké en base de données ayant pour id 10.
Génération du code pour certains modules tels que l’administration, toute la couche d’abstraction aux données de la base de données peux également être générée par Symfony.
Voilà quelques raisons pour lesquels selon moi, Symfony peut donc tout à fait être considéré comme un framework agile. Il s’accorde parfaitement avec des méthodes telles que XP (Extrem programming) et couplé à des pratiques agiles et des outils collaboratifs tels que SVN, il est alors d’une efficacité redoutable pour tous ceux qui doivent respecter des délais serrés et produire une qualité de code exemplaire.
Croyez-moi, pour l’avoir testé sans méthodologie agile puis avec des pratiques agiles je dois dire que dans le second cas, le Framework m’a bluffé d’efficacité. Nos délais de livraison ont été raccourcis et notre code à gagner en clarté et qualité. J’ai pu noter d’ailleurs un regain de motivation au sein de l’équipe qui reprenait enfin goût au développement d’un projet qui paraissait pourtant s’embourber et démotiver les troupes au fil des mois.
Un grand merci à l’équipe de développement de Symfony, car la communauté de développeurs PHP avait depuis longtemps besoin d’un tel framework !
—
N’hésitez pas à me laisser en commentaire vos avis concernant ce Framework.
Avez-vous eu l’occasion d’utiliser le couple « Symfony + méthodes agiles » telles que XP, SCRUM lors de vos projets ? Etait-ce une réussite ?
Quand on lit un article comme le vôtre, on s’aperçoit que l’industrialisation du développement par PHP est en bonne voie. Cependant ce sont des choses qui existent depuis longtemps en Java.
Pourriez vous en dire un peu plus à propos des versions applicatives car je ne vois pas comment cela se traduit.
Bonjour Mikael,
Je partage votre avis sur le fait que l’industrialisation de PHP est en cours grâce notamment à des Frameworks tels que Symfony ou encore Zend que j’ai également eu l’occasion de tester il y a de cela deux ans maintenant alors que le projet était encore à ces balbutiements.
Je suis également d’accord sur le fait que ces processus sont utilisés dans d’autres technologies d’avenir telles que le Java et depuis bien longtemps. Je pense d’ailleurs que le créateur de Symfony s’est inspiré des très bons frameworks Java que sont Struts ou encore Hibernate dans pas mal de points et notamment pour la couche ORM qui est ici représentée par des modules comme Doctrine ou Propel.
Il va de surcroit qu’une telle démarche était nécessaire au bon déroulement d’un projet réalisé en PHP. Bien souvent ce langage se voit bafouer dans le monde de l’entreprise qui a peur de la maintenance du code, ou encore des évolutions qui bien souvent, il faut l’avouer sont problématiques pour une entreprise sur le long terme, or le fait d’implémenter un tel framework évitera bien des désagréments lors d’évolutions ou de reprise de code et rassurera l’entreprise qui pourra facilement trouver des développeurs de Symfony ou même Zend qui développe donc sur la même base et avec des objets communs.
Concernant maintenant votre question sur les versions applicatives, Symfony intègre une panoplie d’outils permettant de faciliter ce qui est appelé l’intégration continue en agilité. Ainsi vous avez accès à un paramétrage qui vous permet de créer autant d’environnement que vous le souhaitez et qui vous permet de les déployer ensuite tout aussi simplement grâce à des lignes de commandes Symfony. Il est donc possible d’automatiser les builds par période temporelle (jour,semaine, mois,…) ainsi que par environnement paramétré (développement, pré production, prototype, production…)
Voilà j’espère avoir été assez clair dans mes propos Mikael.
A bientôt sur Coffe-meeting, le blog agile !
Bonjour André,
Je suis tombé (pas de trop haut) sur votre article en cherchant avec un collègue des exemples de tâches ou user-stories qui auraient été écrites autour de projets réalisés avec Symfony …
Je suis en accord avec vos avis sur la rapidité de développement de Symfony, encore faut-il l’avoir un peu pratiqué (et donc y avoir investi un peu de temps …) pour être au point sur les applications/modules à créer pour un nouveau projet. Que ce soit la définition sans encore avoir tapé sur le clavier ou la décomposition en tâches toujours sans avoir encore tapé sur le clavier …
Est-ce que vous pouvez donner des exemples concrets de user-stories ou tâches que vous auriez utilisées dans le cadre de la définition du backlog product ou des tâches relatives à la partie infra d’un projet (dont le choix de l’outil de conception aurait déjà été décidé d’être Symfony) ?
Merci d’avance !
Pascal
Salut André .. tout d’abord merci pour l’article qui est intéressent et qui témoigne d’une expérimentation sur terrain e non pas d’un simple avis personnel .
mais ce que j’ai remarqué au début de l’article tu introduit par le fait que les methode agile sont un vrai plus quand on développe avec SF , ensuite tu focalise sur la methode XP …
je veux savoir est ce que XP est la méthode la plus adapté à SF et si oui pourquoi ???
et est ce tu as essayé Scrum avec SF ??
si oui qu’est ce qui t’as fais choisir XP plutôt que scrum et est ce que je doit renoncer à cette méthodologie et me tourner ver XP (que je connais pas encore)
et merci
Bonjour Omar,
Pour avoir fait beaucoup de SF dans le passé, je peux te dire que c’est particulièrement adapté au combo Scrum/XP. L’architecture des projets SF est propice à la réalisation de pair programming, revues de code côté ingénierie logicielle mais simplifie également le travail de développement lorsque l’on nous sommes en Scrum et que l’on découpe en Users Stories les fonctionnalités à développer.
Mon conseil serait plutôt: Ne renonce à rien, expérimente les 2 méthodologies, elles sont complémentaires et très efficaces pratiquées ensemble.
Tiens moi au courant !