Rendez-vous service et optimisez votre environnement de développement

Ceci est le transcript d’un lightning talk donné par Bastien lors du SymfonyLive Paris 2023.

On monitore toujours la production.

Mais qui monitore l’environnement de développement ?

Il paraît évident de monitorer les performances de la production, c’est une pratique quasiment résolue et dont il existe un écosystème de solutions et de documentation plutôt abouti.

Si la production ralentie, il y a souvent un impact business qui entraîne une réaction rapide et une priorisation pour les développeurs.

Il est bien moins courant de faire attention à ce qui occupe pourtant notre quotidien : les performances sur nos ordinateurs de travail. Nous développons pendant des heures, nous pouvons lancer des centaines de fois les mêmes tests et faisons un nombre incalculable d’opérations.

https://xkcd.com/303/

Section intitulée mettre-a-jour-sa-stackMettre à jour sa stack

La performance est une feature.

Les features sont toujours pour les nouvelles versions.

Utilisez les dernières versions.

En étant sur une version récente, moins de deprecated sont à vérifier (c’est le cas entre une 6.2 et une 5.4), et tous les patchs de performance introduits dans les nouvelles versions sont à notre disposition.

L’expérience de développement (DX) y est également de plus en plus agréable car c’est la priorité actuelle des développements Symfony maintenant que la base du framework est robuste.

Donc hop hop, on upgrade nos applications vers PHP 8.2 et Symfony 6.2.

Cerise sur le gâteau, il sera plus facile de tester la 6.3 bêta dans quelques semaines et y passer en production en mai quand elle sera disponible.

Section intitulée dockerDocker

Nous sommes beaucoup à travailler dans un environnement à base de conteneurs Docker, qui n’est pas des plus rapides sur Windows ou Mac.

Un bon article très détaillé sur le pourquoi.

Peut-être qu’il n’est pas pertinent de faire tourner PHP dans votre docker et utiliser symfony serve (on en parle ici et ici) ? mutagen ? unison et volumes partagés ? VirtuoFS ?

Si c’est docker qui vous ralentit, il existe peut-être une solution pertinente pour votre situation.

Section intitulée service-discovery-metadata-autowireService discovery, metadata, autowire

Certains sont assez vieux pour se rappeler l’époque où nous devions faire un clear:cache à chaque changement de code.

Ce n’est plus le cas depuis longtemps, et ce, grâce à un savant enchevêtrement de mécanismes complexes qui surveillent quels fichiers sont modifiés, ce qui est modifié à l’intérieur et est-ce que ça implique quelque chose qui peut changer tout le conteneur et les injections de dépendances.

Nous en parlons très longuement et en détail dans cet article. Nous y avions trouvé plusieurs optimisations de performance de la stack dev grâce à Blackfire.

Exemple dans beaucoup de classes : si vous modifiez la signature d’une méthode publique, boum, le cache est supprimé et il sera nécessaire de le calculer à nouveau à la prochaine requête. Une raison de plus d’utiliser des méthodes private dès que possible !

Ainsi, le nombre de fichiers PHP et yaml/xml a un impact immédiat sur les performances au boot de l’application.

En auditant l’environnement d’un nouveau client il y a quelques jours, nous nous sommes rendus compte d’une régression dans Symfony et que nous sommes en train de la corriger.

Le client constate un gain de 41% à chaque requête en environnement de développement (sur un linux, donc certainement encore plus sur un macOS) 🎉

Section intitulée mettre-en-cache-les-requetes-externes-ou-les-mockerMettre en cache les requêtes externes, ou les mocker

Les applications font de plus en plus appel à de nombreux services accessibles en HTTP. En développement, nous pouvons rapidement nous retrouver à beaucoup attendre des services potentiellement lents, encore et encore.

Vous pouvez découvrir la conférence d’Allison Guilhem sur la capacité d’HttpClient de faire des requêtes HTTP concurrentes en async ?

Saviez-vous que vous pouvez aussi mettre en cache les appels externes en développement ?

Section intitulée maitriser-son-editeur-et-son-environnement-de-travailMaîtriser son éditeur et son environnement de travail

Ça, c’est le nerd qui parle : apprenez les raccourcis de votre éditeur vous permettra d’aller beaucoup plus vite que beaucoup de déplacements à la souris. Des outils comme Github Copilot peuvent également vous aider dans certaines actions répétitives.

Le saviez-vous ? Il existe des claviers avancés qui font plein de choses, réduisent les déplacements nécessaires et sont programmables.

Section intitulée tdd-all-the-timeTDD all the time

Il est bien plus rapide de relancer un bin/phpunit --filter=XXX en ligne de commande que de changer de contexte en permanence entre éditeur et navigateur pour relancer un test manuel.

Le test sera réutilisable tout le temps, contrairement au test manuel.

Nous en profitons pour tester des cas d’échecs et non pas seulement le cas positif.

Rendez-vous également service en adoptant les outils d’analyse statique comme PHPstan (ou Psalm). Ces outils permettent d’anticiper des tas de bugs potentiels et réduisent d’autant une partie de recette obligatoire à chaque changement de code.

Rappel également qu’il est mieux de lancer un PHPstan à haut niveau quitte à avoir une baseline que de lancer qu’à un faible niveau.

Section intitulée faire-confiance-a-son-integration-continue-ciFaire confiance à son intégration continue (CI)

Une bonne intégration continue est vitale pour la confiance dans votre code. Avec une bonne couverture de code (unitaire, intégration et applicatif), nous pouvons nous dire que si la CI est verte, il y a de grandes chances que cela fonctionne en production (et sinon, c’est une bonne indication qu’il manquait un test quelque part).

Cela s’optimise également, et c’est un sujet d’article à part entière (à mettre au goût du jour d’ailleurs) 😛

Section intitulée blackfire-all-the-thingsBlackfire all the things

Impossible de parler de performance dans l’écosystème Symfony sans parler de Blackfire. Et ça tombe bien c’est un outil que nous adorons et qui est une pièce maîtresse de notre rapport à la performance.

blackfire run bin/console
blackfire run bin/console cache:warmup
blackfire curl http://monsite.test

Nous testons tout : le bootstrap de l’app en mode cli, en Web, le warmup. Cela permet également d’avoir des points de comparaison avec les nouvelles versions, à la recherche de potentielles régressions de performance.

Section intitulée la-performance-c-est-de-la-developer-experience-dx-ca-vaut-le-cout-d-investirLa performance, c’est de la Developer eXperience (DX), ça vaut le coût d’investir.

Un environnement de développement lent pour une équipe de développeurs représente des heures de perdues à attendre pour rien. Optimiser ce processus représente donc un gain certain et un confort au quotidien.

Ça vaut donc vraiment le coût d’y investir du temps et de l’énergie. Et comme le temps c’est de l’argent…

Section intitulée se-faire-accompagnerSe faire accompagner

Ce sont des problématiques que nous rencontrons en permanence et nous pouvons peut-être vous aider à améliorer votre stack.

Et si on commençait à travailler ensemble ?