Ravi de te voir Explorons de nouveaux savoirs

Mon top 5 des PIRES erreurs sous Symfony


12 Août 2022 | 6 mins Marianne Joseph-Géhannin

Je suis dĂ©veloppeuse PHP/Symfony depuis prĂšs de 10 ans, et au cours de mes missions j’ai pu tester, expĂ©rimenter, et dĂ©couvrir diffĂ©rentes architectures et design patterns en entreprise. J’ai vu du bon, j’ai vu du passable, et j’ai aussi parfois ouvert les portes de l’enfer. De ces expĂ©riences, j’ai dĂ©cidĂ© de recenser le pire, et je vous propose dans cet article le top 5 des erreurs qu’il faut Ă  tout prix Ă©viter sous Symfony !

#5 Faire une librairie, alors qu’il s’agit d’un bundle

Library vs Bundle

Combien de fois ai-je vu des soi-disant librairies qui, n’en Ă©tant pas (vous allez comprendre ce que j’entends par lĂ  trĂšs vite), posaient des soucis de maintenabilitĂ© sur les projets Symfony ? La rĂ©ponse est : beaucoup trop.

Tout d’abord revenons sur le vocabulaire : une librairie est un ensemble de code destinĂ© Ă  ĂȘtre rĂ©utilisĂ©, qui fournit des outils pour rĂ©duire le temps de dĂ©veloppement. Il peut ĂȘtre normal, vu cette dĂ©finition, de vouloir en faire avec des composants Symfony.

Le seul hic c’est que dans l’écosystĂšme Symfony
 il n’y a pas de librairies, il n’y a que des composants ou des bundles. Je rĂ©pĂšte donc : les librairies dites Symfony sont inexistantes ! Notons toutefois qu’il peut bien y avoir des librairies PHP.

Si on fait une librairire qui utilise des composants Symfony (qui aura sĂ»rement besoin d’une configuration), alors lors d’une mise Ă  jour de la librairie sur le projet on s’expose Ă  la fois Ă  des bugs difficilement identifiables mais aussi au fait de rendre la configuration illisible. Alors que faire un bundle permet d’utiliser toutes les possibilitĂ©s qu’offre le framework comme gĂ©rer la configuration ou utiliser directement les services sans avoir besoin de les dĂ©clarer.

Moralité : que ce soit à cause de la sémantique ou de la pratique, faites des bundles si vous avez des composants Symfony !

#4 Les librairies partagées

On pourrait croire que c’est une bonne idĂ©e quand dans plusieurs projets nous avons les mĂȘmes classes. On se dit que la duplication de code c’est mal, qu’on a la mĂȘme unicitĂ© sur tous les projets et qu’on n’a qu’à tester qu’une seule fois le code.

Sur le papier, ça passe. Dans les faits, si on n’est pas rigoureux, cela peut vite ressembler à l’enfer.

Prenons un exemple concret : vous avez plusieurs services qui utilisent la mĂȘme librairie, et celle-ci n’a pas de release. Un dĂ©veloppeur travaille sur le service A qui utilise la library Tools pour la feature 01. Il a eu besoin de modifier cette librairie, et ce code a Ă©tĂ© mergĂ© sur la branche principale. Mais ce dĂ©veloppeur n’a pas dĂ©tectĂ© que sa modification a crĂ©Ă© un break change inintentionnel sur le Service B, et comme la librairie n’a pas Ă©tĂ© mise Ă  jour sur celui-ci, c’est restĂ© invisible. Un autre dĂ©veloppeur travaille en parallĂšle sur, justement, ce Service B et a aussi besoin de modifier cette librairie. Quand il va faire sa branche sur la librairie, cela sera Ă  partir de la branche principale, avec la modification pour la feature 01. Quand la librairie sera mise Ă  jour pour tester la branche spĂ©cifique, il y aura une erreur, dont la raison demeurera complĂštement opaque pour le deuxiĂšme dĂ©veloppeur


Example problÚme librairies partagées

Cela fait perdre du temps pour dĂ©bugger, car ça implique de solliciter toute son Ă©quipe, pour identifier le dĂ©veloppeur responsable du break change et corriger ce qui doit l’ĂȘtre.

S’il y a une bonne communication dans votre Ă©quipe et avec les autres Ă©quipes, un mĂȘme processus rigoureux, ou un versionning fait dans les rĂšgles de l’art, vous pourrez limiter les impacts de ce genre d’erreur.

#3 Ne pas faire les mises Ă  jour Symfony

Qui n’a pas dĂ©jĂ  eu Ă  travailler sur du code legacy en Symfony dans une vieille version, dont la mise Ă  jour est devenue plus difficile et coĂ»teuse au fur et Ă  mesure du temps qui passe ?

Le framework n’est pas mis Ă  jour rĂ©guliĂšrement que pour des nouvelles fonctionnalitĂ©s, il l’est aussi pour corriger des bugs qui peuvent ĂȘtre relatifs Ă  la sĂ©curitĂ©. Cela veut dire qu’en ignorant une ou plusieurs mises Ă  jour, vous pouvez laisser des failles sur votre application. Aussi, les versions de Symfony sont liĂ©es Ă  des versions de PHP. Vous ne pourrez par exemple pas monter votre version de PHP sur le serveur si vous avez une vieille application qui tourne sur du Symfony 3/PHP 7.

Faire rĂ©guliĂšrement les montĂ©es de versions de Symfony en enlevant progressivement les deprecated Ă©vitera les surprises lors d’une montĂ©e majeure de version.

Attention toutefois, car paradoxalement faire trop rapidement une mise Ă  jour Symfony est aussi une erreur. Rares sont les projets qui n’utilisent pas de bundles externes, et quand il s’agit d’une montĂ©e de version majeure, il faut attendre que ceux-ci proposent leur propre mise Ă  jour.

MĂȘme si de nos jours les releases Symfony sont globalement stables, attendre un petit peu pour ĂȘtre sĂ»r qu’il n’y ait pas de bugs peut ĂȘtre salutaire.

#2 TROP utiliser les Event Listeners

Je suis la premiÚre à aimer utiliser les listeners : ça me permet de mettre en place une action commune pour un événement particulier assez facilement.

Mais ça peut vite devenir une usine Ă  gaz difficilement maintenable pour toute nouvelle personne arrivant sur le projet. Les listeners sont souvent invisibles dans le code, dispersĂ©s entre le code source et les bundles, pouvant ĂȘtre dĂ©clenchĂ©s trĂšs facilement si l’évĂ©nement est rĂ©current. Les risques sont d’avoir des listeners se marchant sur les pieds (par exemple un listener pouvant impacter le comportement d’un deuxiĂšme) ou de plomber les performances par des appels trop frĂ©quents. Blackfire peut ĂȘtre votre ami dans ce cas-lĂ  avec le metric symfony.events.

GrĂące Ă  la commande bin/console debug:event-dispatcher ou dans le profiler, il est facile d’avoir la liste des classes, de vĂ©rifier qu’un listener existant ne peut pas ĂȘtre enrichi avant d’en crĂ©er un autre et surtout de debugger.

#1 Utiliser API Platform aveuglément

No API Platform

API Platform permet de crĂ©er rapidement des APIs et cela permet de gagner un temps incroyable en dĂ©but de projet. Malheureusement, le coĂ»t de dĂ©veloppement et de maintien vient plus tard et peut ĂȘtre faramineux.

Si votre besoin est trĂšs spĂ©cifique et demande plus que des CRUD basiques, cela peut vite devenir trĂšs lourd : besoin de faire des hacks dans tous les sens, d’override des classes, et si vous avez besoin d’une serialization un peu gourmande, vos tirs blackfire vous feront perdre de la tĂȘte. Pour l’avoir vu et expĂ©rimentĂ©, il faut ensuite dĂ©ployer une Ă©nergie folle et faire appel Ă  son ingĂ©niositĂ© pour passer outres toutes ces problĂ©matiques.

API Platform propose rĂ©guliĂšrement des mises Ă  jour pour amĂ©liorer sa performance, pourtant je reste convaincue de ne pas l’utiliser si le projet est un peu plus complexe.

En fonction de votre besoin, il faut rĂ©flĂ©chir entre utiliser cet outil ou faire soi-mĂȘme son API. FOSRestBundle vous permettra d’ĂȘtre indĂ©pendant sur les actions que doivent faire vos routes, sans code magique, ce qui vous permettra de maĂźtriser la rĂ©silience et la performance de votre application.

Conclusion

Ce top est propre Ă  mon expĂ©rience, et avec de la chance, je n’ai sĂ»rement pas tout vu.

Et vous, quelles erreurs avez-vous déjà vues ?

Auteur(s)

Marianne Joseph-GĂ©hannin

DĂ©veloppeuse PHP/Symfony 🩝

Utilisation hors-ligne disponible