La parole est aux speakers : Nicolas Grekas

Publié le

Jusqu’au Forum PHP 2022, retrouvez nos interviews de speakers pour mieux comprendre leur parcours et le sujet qu’ils ou elles aborderont lors de leur conférence !

La conférence

Comment décide-t-on de créer un composant Symfony ?

Si vous observez l'évolution de Symfony au cours du temps, vous vous demandez peut-être comment la core-team décide qu'un sujet donné ferait un bon composant ? Il y a déjà des librairies existantes pour presque tout, alors pourquoi en créer de nouvelles ? Comment Symfony s'inspire des autres projets et est-ce que ça arrive souvent ? Est-ce que le fait que les composants Symfony soient utilisés un peu partout leur apporte des fonctionnalités additionnelles ? Comment sont choisies les dépendances de Symfony ? Ou de façon plus générale : comment le projet Symfony interagit-il avec les autres frameworks et librairies ?

Lors de cette conférence, je vous propose d'étudier ces questions, pour vous permettre de comprendre les raisonnements sous-jacents. Ce sera l'occasion d'illustrer les fameux "package principles" et peut-être de vous donner matière à mieux choisir la façon dont vous-même décidez d'adopter (ou de réécrire) telle ou telle dépendance.

Ballroom ABCDEF - Grace Hopper
14/10/2022
09:45-10:25

Toi qui travailles sur beaucoup de composants Symfony, sur lequel préfères-tu travailler ? Lequel préfères-tu utiliser ?

J’ai contribué à un certain nombre de composants ces dernières années, de VarDumper en 2014 à Clock cette année. Mais le plus incroyable est sans hésiter le composant DependencyInjection (DI). Tous les autres sont plus ou moins finis : ils couvrent bien leur domaine et leur maintenance se fait à la marge. Mais le composant DI évolue tout le temps. Je me souviens m’être déjà dit : « Est-ce que cette PR sur DI est la dernière significative ? Je ne vois pas ce qu’on pourrait inventer d’autre ». Et pourtant à chaque fois de nouvelles idées arrivent. C’est aussi celui que je préfère utiliser parce qu’il est partout tout en restant invisible. Décrire suffisamment bien son code est tout ce qu’il faut faire pour qu’il joue la symphonie pour nous. Et sans introduire de couplage par-dessus le marché !

Le fait d’être, avec Symfony SAS une entreprise complètement dédiée au projet, a-t-il changé ta façon de contribuer ?

Mes missions au sein de Symfony sont d’une part d’assurer la bonne marche et le développement de nos offres (certification, conférences, SymfonyInsight, branding, etc.), et d’autre part d’animer la communauté pour contribuer à ce que le projet garde sa vivacité (ça passe par beaucoup de revues de code, échanges sur Slack, accompagnement sur les PRs, parler à des confs, etc.). Mais côté code, je reste totalement libre. Mes PRs viennent quand elles veulent, mon cerveau ne sait pas à l’avance à quoi il va s’attaquer, et nous ne nous fixons aucun objectif à ce sujet. Tant mieux car je pense que c’est essentiel pour ma créativité. Une chose est nouvelle cependant : l’impact qu’a Symfony oblige à être plus responsable. En pratique, ça veut dire par exemple qu’au sein de la core-team, on cherche aussi à se simplifier la vie au maximum, quitte à créer un nouveau composant, venez voir ma conf 😉
Impossible de maintenir efficacement un projet de cette ampleur sans ça.

Une conférence présentée par

Nicolas GREKAS
Nicolas GREKAS
Nicolas contribue à Symfony, avec deux casquettes: côté open-source, il propose de nouvelles fonctionnalités, des corrections de bugs, et accompagne les autres contributeurs presque quotidiennement depuis près de 10 ans. Il s'efforce de rendre Symfony toujours plus performant, souple et extensible. Côté pro, il participe à l'ambition de créer une entreprise durable en contact immédiat avec l'écosystème Symfony. Pas facile quand le produit est gratuit !

Autres interviews