 Donc du coup on va commencer cette conférence qui va être sur le PHP moderne, on va repress, en fait on va tenter de réconciller le PHP moderne et le développement dans les plugins. Donc du coup la première chose que je vais faire c'est de me présenter. Donc pour le nom je vais éviter de vous répéter le nom vu qu'il va être marqué sur tous les sites mais un peu de contexte ça pourrait être intéressant. Donc du coup je suis développeur de l'officiel chez Group et Média et majoritairement du coup je travaille sur WProquet, donc du coup le sujet de ce truc et du coup sur Imagify. Personnellement j'ai toujours une volonté de m'améliorer en continu et sur WProquet en fait j'ai eu un problème, c'est qu'il y a beaucoup de ressources pour les débutants mais dès qu'on passe en fait à un certain niveau ça vient assez difficile de trouver des ressources pour progresser et du coup c'est aussi un problème parce que je n'ai pas non plus à trouver des exemples concrets ce qui fait que j'ai commencé à stagner. Du coup l'idée derrière ce truc en fait c'est de vous partager toutes les notions que j'ai eues quand je vais rentrer chez WProquet qui m'auraient intéressé avant que j'aie rejoint l'entreprise. Donc c'est un peu une veille concentrée et il y a une autre notion qui me semble intéressante et que j'aimerais approfondir. Au niveau de ce qu'on va faire dans ce truc c'est essentiellement de l'éducation je pense que vous l'avez compris, donc du coup de l'éducation des bonnes pratiques et surtout vous montrez qu'en fait faire des bonnes pratiques avoir du pêche du moderne c'est pas quelque chose qui se fait en un seul coup c'est quelque chose qui se fait petit à petit et du coup ça sera plus simple et moins prenant et on aura des résultats au fur et à mesure. Nous au niveau des résultats on a aujourd'hui un déploiement sur des millions de citoyens et du coup avoir des bonnes pratiques de développement c'est ce qui nous permet en fait d'avoir assez peu de retour pour avoir une équipe de support d'environ 20 personnes sur le plugin et au niveau du support aucune limite de temps, c'est à dire qu'il peut passer autant de temps qu'il faut avec un client s'il a un besoin. Du coup maintenant on sait pourquoi on va faire ce talk au niveau de la structure d'abord on va s'attapter sur l'histoire de nos perroquettes comment il a été créé et comment les notions sont ajoutées une à une ensuite on va avoir une vue de dessus avec l'architecture et enfin on va s'intéresser à la qualité du code comment chez Doudou et Perroquette on fait pour être sûr d'avoir du code de qualité. Du coup au niveau de l'histoire de nos perroquettes avant de vous présenter l'histoire c'est le plus important de vous présenter ce qu'est Doudou et Perroquette Doudou et Perroquette c'est un plugin de cache et de performance effectivement mais pas que. En fait ce qui fait pour moi le core de Doudou et Perroquette c'est le fait que ça soit aussi simple que possible pour les clients c'est à dire qu'ils ont en 95% en tout cas juste à installer le plugin et pas à faire de compréhension mais aussi simple vous allez voir du côté du code et c'est à chaque fois de 5% plus facile. Du coup on va venir à l'histoire de Doudou et Perroquette Doudou et Perroquette ça commence en avril 2013 avec ce que j'appelle la V0. La V0 en fait c'est Jonathan, un de nos fondateurs qui a lancé une vidéo en fait un tutoriel sur comment utiliser son site et à la fin de cette vidéo il proposait aussi un zip payant pour avoir tous les assets de code donc comme vous le pouvez voir il n'y a pas encore plugin et c'était à l'utilisateur d'aller à la main changer dans les settings de son WordPress et ça comme je l'ai dit on tend toujours de simplifier ça a été changé en juillet 2013 quand on a lancé la première version du plugin donc au niveau du code c'était pas tout à fait ça c'était encore du procédural ensuite on a eu la V2 en décembre 2013 qui est vraiment les prémices des bonnes pratiques on a rajouté Git notamment qui permet de travailler à plusieurs assez facilement et on a commencé à avoir de l'objectif en vrai toutes les notions ont commencé à arriver à partir de la V3 en 2018 donc vous pouvez voir on a remodelé l'architecture par feature, on a ajouté des tests et on a protégé les dépendances qu'on utilise ça a l'air d'être un group block mais en fait on a besoin de diviser ce group block pour voir il y a un détail de latence, désolé pour voir qu'en fait c'est quelque chose qui s'est fait petit à petit la V3 ça date de 2018 et aujourd'hui en 2023 on est toujours sur la V3 donc du coup la première notion qu'on a rajouté c'était en 2018 la joue de l'event manager donc du coup l'event manager à quoi ça sert ? l'event manager ça répond à un problème c'est que dans tout plugin WordPress quand on veut commencer de la logique on est obligé d'ajouter un callback sur un événement, un filtre ou une action et plus le plugin grossissait en fait plus on répétait cette logique partout dans notre code et nous plus particulièrement on le mettait dans les constructeurs, ce qui faisait que derrière quand on voulait tester on verra l'importance de tester à la fin du talk en fait on a besoin de simuler l'enregistrement des événements ce qui faisait qu'on répétait aussi cette logique dans les tests et la dernière chose c'est que du coup toutes les classes de notre plugin étaient fortement liées à la paye WordPress ce qui est un problème si il y a un quelconque changement du coup on a répondu à ce problème avec ce pattern en fait l'event manager donc vous pouvez le voir sur le côté en fait on a des subscribes bas qui contiennent toute la logique business en fait c'est toute la logique qui va permettre de faire fonctionner une feature par exemple si on a les illôtes toute la logique des illôtes sera dans le subscriber ce subscriber il va il va passer en fait à l'event manager un tableau et dans ce tableau on va avoir les événements et les callbacks et du coup l'event manager l'event manager lui va s'occuper derrière d'enregistrer tous ces événements dans la paye WordPress au niveau de comment ça fonctionne dans le plugin ça fonctionne de cette façon du coup on initialise l'event manager et ensuite pour chaque subscriber on va l'enregistrer sur l'event manager on va récupérer les événements on va récupérer les événements enfin désolé l'event manager va récupérer les événements sur le subscriber et l'event manager va enregistrer les hooks sur la paye WordPress et aussi simplement de ça on a réussi à éviter de répéter la logique dans l'enregistrement des hooks parce que maintenant elle est un seul endroit dans l'event manager et du coup on a aussi réussi à externaliser les hooks on a tout simplement séparé de la logique business tout ce qui était relié à la paye WordPress et la dernière chose évidemment on a réussi à faciliter les tests parce que maintenant on a besoin de tester la logique business on a pu besoin de simuler l'enregistrement des événements ensuite la deuxième notion qu'on a ajoutée toujours en 2018 c'est l'utilisation de l'autoload de Composeur donc du coup dans une conférence PHP présenter Composeur c'est pas tout à fait simple mais en fait sur WordPress particulièrement c'est pas forcément un outil qui est utilisé tout le temps et donc du coup je voulais juste structure la memoire donc du coup Composeur ça permet de faire l'adjection automatique des événements ça permet aussi de faire l'autoloading en fait c'est le chargement des classes en normal en PHP ça se fait pas automatiquement mais du coup Composeur se propose de faire pour vous et du coup le fait qu'on délègue la gestion des dépendances à Composeur ça permet deux choses en fait la première chose c'est que ça rend votre code plus clair il n'y a plus les librairies et ça permet aussi de réduire les conflits vu que quand on est mis à jour en fait on n'a qu'un seul fichier où toutes nos dépendances sont listées ensuite la notion suivante qu'on a ajouté c'est Leap Container qui est une librairie qui fait de l'injection de dépendance c'était en 2020 du coup pareil quel problème on voulait résoudre en fait dans un plugin on a toujours le problème de lier les classes en fait pour ça on a deux solutions la première solution c'est de lier les classes dans le constructeur c'est un avantage c'est qu'il y a très peu de conflits vu que c'est dans chaque fichier et par contre ça rend le code très difficile à tester dans mon côté la deuxième solution qu'on a c'est de lier les classes dans le core c'est à dire la pratique principale de notre plugin ce qui a en fait les effets opposés c'est à dire qu'il y a beaucoup de conflits vu que c'est un endroit où on centralise tout l'injection de dépendance ça va prendre le meilleur des deux en gros ce qui va se passer c'est du coup quand on va vouloir instantier une nouvelle classe ce qu'on va faire c'est qu'on ne va plus le faire en utilisant new mais on va déléguer ça à un container le container lui ce qu'il va faire quand il va recevoir la signature de la classe qu'il va devoir instantier il va en fait générer l'arbre des dépendances pour nous et nous retourner la classe donc pour le moment on est plutôt sur la deuxième solution et en fait le petit trick il vient sur le dernier objet qu'on voit dans le schéma le service provider qui lui va permettre de créer de l'abstraction et du coup au niveau du core du plugin la partie principale on verra que l'ajout des services provider et on verra plus la logique de liaison entre les classes et ça ça va nous permettre tout simplement de diviser dans le plugin la liaison entre les classes maintenant chaque feature aura son propre service provider qui ira les classes donc du coup les avantages c'est de réduire le coupling entre le core et les features c'est à dire que maintenant vu qu'on a pu allier les classes dans le core on peut avoir un core totalement indépendant des features qu'on a dans le plugin ça pourrait faire en sorte par exemple qu'on réutilise ce core dans notre plugin qu'il n'ave pas du tout les mêmes features et pareil pour la feature maintenant on n'a plus besoin que de ajouter le service provider pour avoir la feature fonctionnelle on a juste à prendre la feature la déplacer dans un nouveau plugin ajouter au compte énorme du nouveau plugin et on a une feature qui marche et du coup ça permet d'avoir effectivement le code réutilisable ça réduit aussi les conflits comme je vous l'ai dit vu qu'on a des services provider qui divise quand on lit les classes il y a moins de chance qu'il y ait de développeurs qui fassent une modification du même pichier en même temps ensuite la notion qui suit c'est la protection des dépendances en fait la protection des dépendances c'est un problème de compositeur à la base et il faut comprendre en fait comment compositeur l'eau de les classes pour comprendre pourquoi on a ce problème quand compositeur l'eau d'une livrairie en fait il va l'ajouter c'est global ce qui fait que sur WordPress vu qu'on a plusieurs plugins qui utilisent des livrairies différentes mais parfois aussi les mêmes si on a deux fois la librairie qui utilisait avec une version différente on va avoir la première qui est chargée qui va se laudait normalement mais la deuxième va en fait générer une fratale pour notre site ce qui est une chose évidemment qu'on ne veut pas donc du coup Mozart qui est une librairie qui va proposer la solution suivante qui est de rajouter un Namespace avant celui de nos librairies qui va préfixer tout nos librairies avec notre Namespace dans le cas par exemple de Noupéroquette c'est WP Underscore Rocket et du coup maintenant on va charger nos librairies vu qu'on pollue plus le Namespace global si quelqu'un d'autre vient lauder cette librairie on n'aura plus de conflits entre les deux librairies ensuite le dernier point que je voulais rajouter sur l'historique c'est en 2022 on a ajouté deux notions avec la 3.11 qui est Perlin, Berlin DB et Action Scheduler du coup Berlin DB, il vient un problème c'est que très vite dans WP Rocket on a été obligé pour les raisons de performance d'utiliser des tables personnalisées et l'environnement pour manipuler ces tables personnalisées il est un peu spartien déjà WP DB c'est une valeur globale ce qui fait que quand on teste ça rend les tests difficiles ensuite on n'a pas de gestion des tables ce qui fait que c'est à nous de dire quand ajouter la table, c'est à nous de dire quand la détruire et on doit aussi créer la table en SQL en plein milieu du code PHP et ensuite la dernière chose c'est que avec WP DB c'est très facile d'avoir des requêtes SQL dans la logique business ce qui n'est pas quelque chose qui est top top donc du coup la solution qu'on a choisie comme je l'ai dit c'est d'utiliser une librairie qui s'appelle Berlin DB qui va nous offrir quatre objets mais dans nos problématiques je vais vous en présenter que deux le premier c'est la query en fait qui va nous permettre de remplacer WP DB par un objet qui n'est pas globale et qui va du coup en capsuler toutes les requêtes SQL ce qui fait qu'on aura pu de mix entre du coup la logique business et les requêtes SQL le deuxième objet c'est les tables qui vont permettre de simplifier la gestion des tables donc du coup tout ce qui va être la définition d'une table ça va prendre en compte la plupart du SQL et on aura pu définir les champs en SQL et du coup ça va aussi créer les tables automaticement pendant nous et concernant la destruction ils ont préféré nous laisser la charge du coup de détruits à la table mais ça se fait toujours en une fonction ensuite on a vu un deuxième problème qui s'est posé lui sur le préload en fait de WP Rockets sur WP Rockets on a aussi des sites qui sont énormes avec des milliers de pages et du coup si on voulait préloader toutes les pages sur du coup en PHP normal ce que ça aurait fait c'est que sur la plupart des serveurs on a une limite de temps donc du coup ça laudait les 100 premières pages et après la limite de temps on aurait arrêté l'exécution PHP donc du coup on aurait laudé que 100 pages sur des milliers on a aussi un autre problème c'est qu'on va monopoliser les ressources en fait à chaque fois qu'on préloade une page on recharge entièrement on recharge entièrement WP du coup on consomme pas mal de ressources si on exécute tout à la chaîne en fait on va monopoliser les ressources du serveur et donc le faire cracher c'est pour ça que nous on a décidé d'utiliser Action Scheduler qui est une librairie qui nous permet en fait de contrôler ces opérations de deux façons premièrement en rendant l'exécution un synchrone c'est à dire qu'on va plus bloquer un fred mais on va l'exécuter plus tard dans le temps et ensuite on fait une exécution par bâche, c'est à dire qu'au lieu de tout loder dans ce coup on va le faire 80 par 80 URL ce qui va éviter de saturer le serveur tout simplement maintenant qu'on a vu les notions qui s'enchaînaient on va voir une vue dessus en fait avec l'architecture de WPRO4 WPRO4 de dessus ça ressemble à peu près à ça au centre on a un corps et autour on a différentes features qui font leur vie un peu tout seul donc du coup je vous propose d'abord de nous centrer sur le corps quel sont ces objectifs plus qu'il y a du corps c'est vu qu'on est dans dans l'environnement WordPress vu qu'on a un plugin WordPress ça va être déjà de charger le plugin du coup d'exécuter toute la logique qui permet de charger le plugin derrière ça va aussi charger toutes les librairies compositeurs dont on va avoir besoin de charger l'enregistrement des événements avec justement l'event manager qu'on a vu avant et ça va mettre en passe l'injection de dépendance avec le container qu'on a vu aussi précédemment du coup comment ça se met en place ça se met en place de la façon suivante donc du coup d'abord on a on appelle le fichier WPRO4.php comme tout plugin WordPress ce qui nous permet de lancer l'enregistrement des traductions dont on a besoin du coup pour traduire le plugin et ensuite on commence vraiment le chargement WPRO4 du coup en appelant la fonction RocketInit cette fonction va commencer par charger les librairies compositeurs une fois qu'on a les librairies compositeurs on va pouvoir accéder à les containers et donc du coup instantier le container pour l'injection de dépendance ensuite on va prendre ce container et on va vraiment goûter le plugin dans la classe plugin qui peut aussi s'appeler la classe Core et à ce moment là ce qui va se passer c'est qu'on va ajouter tous les services provider donc du coup l'endroit où on lit toutes les classes aux containers ce qui va les rendre accessibles et une fois qu'on a toutes les classes vraiment accessibles on va aller récupérer les subscribers en fonction de ce qu'on a besoin on a un plugin de performance donc du coup on va pas loader tout le temps ça serait un peu bas d'eau et on va juste loader les subscribers dont on va avoir besoin et une fois qu'on a les subscribers dont on a besoin on va simplement les donner à l'event manager qui va les enregistrer dans la API Workpass maintenant on sait comment marche le Core on va s'intéresser un peu comment est-ce organisé une feature donc du coup une feature c'est toujours organisé de la fonction suivante on a un ou plusieurs subscribers on va voir la business logic donc vraiment la logique qui va servir derrière à exécuter par exemple les silos le service provider comme j'ai dit qui va servir à lier les classes et optionnellement si on en a besoin une table pour pouvoir interagir avec du coup une table en SQL et une queue si on a besoin d'actions à 5 points du coup l'avantage d'avoir des features comme ça qui sont en stein de l'eau mais qui n'interagissent pas avec les autres c'est qu'on découpe en fait les features ce qui fait que si on déploie un changement sur une feature on n'a pas peur de casser l'autre feature tout simplement ensuite on a une seule source de vérité donc du coup c'est vraiment rendre le plugin le plus simple possible donc du coup si le développeur il a besoin d'une ressource il sait que par exemple une ressource du remove un new css dans le dossier du remove un new css et nulle part rien ce qui fait qu'il trouvera la ressource beaucoup plus vite et du coup ça ça nous permet aussi de garder le code simple vu qu'on est basé uniquement sur la feature et qu'on n'a pas à on n'a pas à prendre en compte en fait l'interaction avec les autres features et c'est justement ce qu'on va parler juste après du coup c'est comment faire interagir les features qu'on a sont des plus clés et on va aussi par la mail répondre au problème comment garder le code extensible pour les utilisateurs et pour les développeurs sans qu'ils aient à modifier en fait le code et du coup pour ça on a une solution faite par WordPress pour WordPress qui sont en fait les événements donc du coup les actions et les fixes du coup ça part surtout d'une philosophie plus que plus que de notions l'idée c'est de toujours penser le plugin comme extensible par intermédia d'actions et de fixes et du coup pour rendre cette phrase un peu plus claire j'ai deux exemples d'utilisation pour les filtres et deux exemples d'utilisation pour les actions donc du coup par exemple pour les filtres on peut les utiliser dans le cas d'une constante magique une constante magique c'est par exemple quand on exécute une crône on va l'exécuter toutes les 24 heures ça vient d'où c'est le développeur qui a décidé mais imaginons qu'on est quelqu'un qui soit expert qui sait que pour lui la crône doit se tourner doit tourner toutes les 48 heures par exemple si on a une constante magique il sera bloqué l'idée ici c'est de rajouter un look et du coup le look, désolé on va rajouter un filtre et le filtre lui il va nous offrir deux choses d'abord il va nous offrir une valeur par défaut pour l'utilisateur qui est lambda en fait et qui a aucune idée de ce que veut dire 24 heures pour lui et qui a pas envie de savoir donc du coup on lui donne une valeur par défaut qui va lui s'amplifier son utilisation et de l'autre côté on ne va pas non plus imposer notre choix et du coup l'utilisateur qui lui sera expert et aura besoin de changer la valeur à 48 heures lui pourra avec un intermédiaire un callback en fait sur notre filtre ensuite le second exemple c'est contrôler et lui donner donc du coup pour ça j'ai un exemple assez simple c'est quand on pierre le cache des fois on a des plugins qui sont un peu enfin on a des sites désolé qui sont un peu non conventionnettes ce qui fait qu'ils ont des URL en plus en fait à nettoyer en même temps qu'un poste et donc du coup ici si on a être à te filtre du coup l'utilisateur serait bloqué et il ne pourrait pas faire grand chose et si on lui offre un filtre qui va lui permettre d'ajouter de retirer des données qui va lui permettre de modifier un filtre donné du coup on va pouvoir il va pouvoir en fait ajouter ses URL à la fin des URL qu'on allait donner à nettoyer tout simplement et donc du coup ça lui permet une configuration par l'utilisateur et ça permet aussi une adaptation de la logique en fonction justement des cas de l'utilisateur ensuite au niveau des actions du coup la première chose à quoi c'est une action c'est à signaler un événement du coup par exemple encore une fois quand on cure le cache on a pas mal de phases parties qui justement ont développé du code qui interagit avec nous notamment quand il faut nettoyer le cache et du coup leur donner une action avant et après on est nettoyé le cache ça leur permet très simplement de mettre en place leur logique et d'exécuter au bon moment sans avoir à chercher dans le file système quand est-ce que les fichiers ont disparu et du coup tout ça bien sûr ça facilite la compatibilité le second exemple c'est déléguer de la logique en fait souvent quand on a un bloc de logique par exemple un bon exemple ça se fait quand on a un plugin de paiement sous au commerce on a plusieurs choses qu'on veut faire mais on a une logique qui est essentielle dans le cas d'un plugin de paiement c'est de payer c'est de payer et du coup derrière on va avoir aussi de la logique qui est un peu on doit exécuter mais qui n'est pas principal par exemple envoyer un mail et du coup ce que on va faire ici c'est au lieu d'écrire la logique d'abord pour payer puis la logique pour envoyer le mail on va tout simplement écrire la logique pour payer ajouter une action et la logique pour envoyer le mail on va l'ajouter en callback de cette action ce qui fait que si dans le futur on a un problème avec les mails et qu'on a besoin d'une notification Slack on pourra réimplémenter le callback on n'aura pas à toucher à la logique essentielle du plugin pour le paiement et du coup ça ça aura aussi un impact au niveau de la visibilité vu qu'on n'aura pas mélangé de fonctionnalités différentes au même endroit ça nettroira la logique et on aura plus que la logique qui est centrale en fait et ça facilite du coup j'ai dit la modification ensuite au niveau de la qualité du code du coup chez d'oui perroquette on a plusieurs choses qu'on utilise pour s'assurer que la qualité du code est toujours optimale et du coup la première chose qu'on utilise c'est phpcs en gros ça vient du problème qu'on a plusieurs devs dans l'équipe d'oui perroquette heureusement et du coup ces devs ils viennent d'environnement différents et du coup ils ont des pratiques différentes l'idée derrière ça va être d'utiliser un linter qui va nous permettre trois choses la première chose ça va nous permettre d'établir des règles pour le formatage du code la deuxième chose ça va nous permettre de vérifier si le code est valide par rapport à ces règles et la troisième chose qui va plus apprécier des developers ça va nous permettre de mettre le code autant que possible aux normes mais ça marche pas à 100% des cas parce qu'il y a toujours des cas où le code doit être adapté manuellement et ça ça va nous permettre à la fin d'avoir du code standardisé entre les developers et donc du coup beaucoup plus visibles ensuite la deuxième chose qu'on fait c'est qu'on teste donc du coup tester c'est goûter une chose qui est pas mal dit dans la communauté mais tester c'est pas que vérifier que tout marche bien tester c'est aussi garder une connaissance des spécifications et donc du coup une connaissance du produit à l'intérieur même du code c'est à dire que sur d'où est perroquette on est un plugin qui on a commencé à développer il y a déjà 10 ans et les devs ils étaient là il y a 10 ans ils sont déjà partis et les codes en fait vont nous permettre de garder l'idée de pourquoi les devs qui étaient là il y a 10 ans ont implanté cette feature de cette façon ça permet aussi de voir rapidement un défaut quand on teste manuellement souvent depuis que ça prend du temps on teste à la fin avec des tests on va pouvoir tester tout le temps en permanence vu que c'est une tâche qui peut même être exécutée en arrière-plan et la dernière chose c'est que tester c'est de automatiser des tâches ennuyées en fait tester à la main franchement en tant que développeur prohp c'est pas la tâche la plus intéressante au niveau des tests maintenant on sait pourquoi on teste il y a 10 différentes types de tests les premiers c'est des tests unitaires du coup ils sont au niveau des classes et c'est les tests les plus bas ils vont s'assurer en fait que chaque classe fonctionne correctement donc du coup l'avantage de ces tests c'est qu'ils sont très bas donc on peut voir bien le problème mais les avantages c'est qu'on dit qu'ils sont très fragiles c'est à chaque fois qu'on va modifier du code et que ça va changer le résultat d'une classe il va falloir les retravailler donc du coup ça prend pas mal de temps les tests d'intégration c'est un niveau au-dessus on va s'assurer que le système ou une fonctionnalité fonctionne correctement donc du coup on aura des tests qui seront plus robustes vu que maintenant si il faut que ça change c'est qu'on a changé nos attentes par rapport à la fonctionnalité mais du coup on est un peu moins précis c'est-à-dire qu'on va tester et on saura que le problème est dans cette fonctionnalité et la dernière niveau qu'on a chez Dwayne Perot 4 c'est le end-to-end donc du coup c'est vraiment au niveau de l'interface utilisateur on va regarder que tout se passe bien quand on appuie sur les boutons donc c'est le plus complet vu qu'on l'aute complètement le plugin mais après du coup c'est celui qui est le plus de trou dans la racquette une notion importante que je voulais vous partager c'est la TDD du coup on l'entend souvent mais je voulais quand même vous l'aurez expliqué une test driven development c'est quoi ? tout simplement la TDD c'est créer les tests avant le code en normal si on va avoir des tests de qualité on a toujours besoin de 2 développeurs le truc c'est en fait avec la TDD on va écrire les tests avant le code ça fait qu'on ne connaîtra pas le developer ne connaîtra pas le code puisqu'il n'a pas encore été écrit et du coup il ne sera pas biaisé par le code qu'il a écrit au moment où il écrit les tests et ça du coup comme avantage au lieu d'avoir 2 développeurs pour écrire du code et du test on a plus qu'un ça fait qu'on a des tests de bonne qualité en fait et valide du coup si on fait l'inverse on écrit le code et après les tests on va écrire des tests qui vont vérifier que le code qu'on a écrit est bien écrit de la façon dont on l'a écrit et non pas que le code fonctionne selon les experts selon les experts selon les experts ah selon les apprends qu'on a et du coup ça va permettre de réduire le coût d'une erreur en fait en développement plus on voit une erreur tard plus l'erreur de plus de cher et ce qu'on va faire en TDD c'est qu'on va tenter de faire en sorte qu'on échoue le plus tôt possible et du coup on va échouer avant même d'avoir écrit le code donc du coup l'idée dans la TDD c'est ce schéma je sais pas si c'est assez grand donc du coup la première chose ça va être d'écrire un code simple on est des développeurs donc du coup notre job c'est de diviser des problèmes en sous problème donc du coup si vous écrivez un test compliqué divisez-le en sous problème cliquez-les en sous test on vérifie après que notre code échoue, pourquoi est-ce qu'on vérifie que le code échoue parce que si on écrit le code et que le code échoue pas ça veut dire qu'on va écrire du code qui sert à rien une fois qu'on a le code qui échoue du coup le test est rouge c'est comme ça qu'on l'appelle dans la norme de la TDD on va écrire le code le plus simple possible pour faire passer ce test le code peut être horrible on s'en fiche à ce niveau là on va s'en occuper plus tard l'important c'est que le test passe et que du coup deviennent verts une fois qu'il est vert on va ajouter une dernière petite étape le refactoring du code du coup on avait du code horrible maintenant on a toutes les attentes par rapport on va pouvoir le modifier et tenter de le rendre plus joli pourquoi à ce niveau là parce qu'en fait vu qu'on a toutes les attentes si on casque quelque chose on aura forcément un test qui échouera qui tournera rouge et on sera directement avertis et du coup la dernière notion que je voulais partager sur les tests c'est les fixtures du coup chez le WP Rocket on les appelle les fixtures en vrai on aurait dû les appeler les scénarios donc les scénarios ça répond à ce problème là quand vous avez écrit de la TDD vous allez avoir beaucoup de tests qui sont très similaires et donc du coup ça va devenir très difficile à maintenir parce que imaginons on a un changement dans les attentes on va avoir à modifier 10 tests d'un coup pour deux lignes de code et ça ça rend bien sûr les erreurs faciles la solution qu'on a en fait c'est de créer les scénarios des jeux de données on va créer derrière un test commun à tous ces scénarios qui va lui avoir la logique pour tester et on va simplement iterativement en fait injecter les données de chaque scénario et regarder si le test passe ça qu'on a avantage du coup c'est qu'on a pu qu'un seul test à maintenir du coup c'est beaucoup plus simple si on a un changement dans les attentes on a une facilité c'est assez facile pour rajouter un nouveau test vu que du coup on a juste à rajouter un scénario et du coup c'est beaucoup plus maintenant parce que comme je vous l'ai dit quand il y a quelque chose qui change en fait c'est juste le test central qui change qu'une seule chose à changer après je vous parle beaucoup de tests de choses qui sont assez lourdes à faire mais la plupart des gens si je pense qu'ils sont dans une agence et du coup ils ne sont pas sur un plugin qu'il faut maintenir pendant 10 ans et du coup ils n'ont pas le problème ils n'ont pas les mêmes problèmes que nous eux leurs problèmes souvent c'est que le patron dit le temps c'est de l'argent et donc du coup il faut aller vite et avoir des preuves rapidement en fait du coup on a besoin de tests solides donc du coup on n'a pas besoin de s'investir énormément mais qui nous retourne quand même enfin qui nous servent quand même avec quelque chose et qui nous avertissent quand on casse en fait des choses, enfin on casse du code par rapport à nos spécifications du coup pour moi un bon compromis c'est d'utiliser la TDD du coup la TDD c'est ce que ça veut vous vous permettre c'est qu'en fait quand vous annoncez quelque chose dans une entreprise souvent on vous dit oui mais on va tester on ne va pas l'appliquer à tout le monde au début si vous êtes dans une entreprise où il n'y a pas beaucoup de dev de tout seul à devoir tester la nouvelle feature et du coup si vous devez écrire des tests tout seul et que vous n'utilisez pas la TDD vous n'aurez jamais des tests qui sont validés et du coup ça vous permet de vous lancer là dessus même si vous êtes tout seul ou même en freelance en fait ensuite au niveau des tests moi je vous indiquerai pas d'utiliser les trois types de tests en fait d'un seul coup mais plus des tests d'intégration en fait les tests unitaires ils sont beaucoup trop fragiles et donc du coup à chaque fois que vous allez faire des iterations de TDD vous allez devoir les changer et vous allez perdre énormément de temps et les tests end-to-end c'est effectivement les plus abstraits mais derrière en fait on doit setup tout un environnement donc du coup pour débuter dans les tests je pense pas que ça soit le plus simple donc moi je préfère le juste milieu en fait les tests d'intégration qui vont nous permettre d'avoir un environnement pas trop trop compliqué et du coup on va quand même avoir un retour et très peu de choses à maintenir et bien sûr je vous conseillerai d'utiliser des fixtures ou des scénarios pour maintenir le plus vite possible vos tests et du coup une dernière chose pour ce talk c'est launchpad en gros c'est un framework qui recouvre toutes les bonnes pratiques que j'ai listées dans ce talk et du coup il n'est pas tout à fait déployé mais en gros si vous voulez le tester vu que moi pour le moment je l'ai testé que sur un seul environnement vous pouvez le tester si ça crache vous créez une issue et ça me permettra à moi derrière d'améliorer en fait le framework et c'est à peu près tout pour moi est-ce que vous avez des questions j'allais un peu rapidement une question bonjour Symmy merci pour la présentation et je voulais te demander si il y a eu un futur que l'on veut modifier et on fait des tests est-ce qu'on modifie en faisant si le test a pris une modification d'un futur c'est un peu le même système que quand on commence un futur de zéro et au niveau de la TDD c'est ça au niveau de la TDD du coup en fait on reprend les anciens tests et soit on va modifier les tests soit si on est sur des nouvelles enfin sur les nouvelles attentes on va en fait rajouter un scénario dans le test est-ce que ça d'accord oui je vais bien compris je vais étudier aussi une question on va me libérer on va rassurer un petit peu on va s'entrouver pour la table merci