Nous auditons un SymfonyContrôleur de messages. Le CRUD semble standard : créer, mettre à jour, supprimer, lister. Nous commençons à revoir le code, en notant les problèmes de sécurité, les gros contrôleurs, les validations manquantes. Et puis nous ouvrons leMessageentité.
Lediffuserle champ est unchaîneavec des valeurs"Y"et"N". Letaperle champ est unintsans énumération, nombres magiques dispersés sur le contrôleur. Letitrele champ en PHP s'appelletitredans la base de données. Et c’est là que se pose la vraie question : auditons-nous le contrôleur ou auditons-nous l’entité ?
Si nous réparons le contrôleur maintenant, nous écrirons du code qui vérifiediffusion === "Y". Lorsque nous corrigerons l'entité plus tard pour utiliser unbouffon, nous devrons revenir et toucher à nouveau ce contrôleur. Même code, audité deux fois, modifié deux fois. C'est exactement ce que nous voulons éviter.
Face à un projet Symfony existant avec 15 entités, 20 contrôleurs, une poignée de services et d'écouteurs, il existe trois manières d'organiser un audit. Aucun n’est universellement mauvais – mais un seul évite le piège systématique du remaniement.
Commencez par les contrôleurs. C'est une approche intuitive : suivez le flux HTTP, voyez ce que l'utilisateur voit. Vous découvrez des problèmes de sécurité, disparus@EstGranted, de gros contrôleurs exécutant 300 lignes de logique métier.
Le bon côté : c'est du concret. Vous repérez rapidement quelles entités sont sous-utilisées, quels services sont sur-conçus. L’inconvénient : chaque contrôleur que vous auditez vous ramène aux entités. Vous trouvez un"O"/"N"ici, un dénué de sensinttapez là, des nullables gratuits ailleurs. Vous passez votre temps à écrire "réparer l'entité plus tard" sans jamais rien réparer.
// Ce que vous trouvez dans le contrôleur if ($message->getBroadcast() === 'Y') { $this->notificationService->sendToAll($message); } // Ce que vous voudriez écrire if ($message->isBroa...
[Courte citation de 8% de l'article original]