En France, nous avons deux gros rendez-vous annuels organisés par l’AFUP (Association Française des Utilisateurs de PHP) : le Forum PHP, événement national organisé sur deux jours en région parisienne au mois d’octobre, et l’AFUP Day, qui est une journée de conférences organisée dans plusieurs villes au même moment au mois de mai.

Comme annoncé précédemment, cette année j’étais présent à l’AFUP Day Lyon, en tant que sponsor pour le framework Temma. Au final, j’y ai surtout présenté le manifeste PHP Way of Life.

Les retours que j’ai eus ont été très positifs. J’ai reçu des compliments pour le manifeste, qui met en lumière les problèmes liés à certaines « bonnes pratiques » qui se sont généralisées alors qu’elles ne sont pas adaptées à toutes les tailles d’équipes. On m’a aussi dit que c’était agréable d’avoir un sponsor qui aborde un sujet de fond plutôt que de simplement présenter sa solution.

Voici la vidéo, tournée par Romane Ledru (membre de l’équipe de l’AFUP Lyon) :

Voici les slides de la présentation :

Transcription de la vidéo :

Slide 1. Bonjour à toutes et à tous.

Slide 2. Je vais me présenter rapidement pour donner un peu de contexte. Je m’appelle Amaury. Je suis directeur technique chez Homunity. J’ai été coordinateur à l’AFUP Paris dans les années 2010. J’ai plusieurs projets open-source à mon actif. Je tiens le blog De geek à directeur technique, et le compte PHP Zen sur les réseaux sociaux.

Slide 3. Je suis là en tant que sponsor pour vous parler de Temma.
Temma, c’est un framework PHP open-source, qui a été créé il y a 18 ans pour les besoins du site Ooreka (qui a été revendu aux PagesJaunes). Ce n’est pas un framework très répandu même s’il y a quelques sites qui l’utilisent. Très rapidement, les bases c’est : très facile à apprendre, qui permet de développer très rapidement, avec une grande rétrocompatibilité.

En fait, je ne vais pas vous parler trop de Temma là maintenant.
Le truc c’est que quand je parle de Temma, je dis souvent qu’il est dans la voie de la philosophie PHP Way of Life. Et à force de dire ça, il a fallu à un moment mettre un peu ça par écrit.

Slide 4. Donc j’ai créé un manifeste, qui est disponible sur le site phpwayoflife.com.
Et pour expliquer un peu cette philosophie, je vais revenir rapidement sur l’histoire des langages de programmation et des frameworks.

Slide 5. Donc si on remonte aux années 50, avec l’assembleur. Je pense qu’on est tous d’accord pour dire que l’assembleur ce n’est pas le langage le plus facile à prendre en main.

Slide 6. Ce qui fait que, quand le C est arrivé (alors je fais de grosses grosses simplifications, ne m’en veuillez pas, c’est pour le besoin du discours ; il y a eu des langages entre l’assembleur et le C, mais voilà, le C est un langage qui est toujours là), il était beaucoup plus simple que l’assembleur. Yay !

Slide 7. Ensuite, le C++ est arrivé. Dans le genre compliqué comme langage, ça se pose bien là, il y a plein de paradigmes dedans ; si vous voulez maîtriser 100% du C++, ça va vous prendre un certain temps.

Slide 8. Ce qui fait que, quand le Java est arrivé dans les années 90, c’était une espèce de bouffée d’air frais parce que c’était « Ah, un langage moderne qui nous permet de manipuler les concepts objets qu’on utilise en C++ mais de manière plus simple et plus fluide ».

Slide 9. Et évidemment, les choses se sont gâtées quand on a tout recomplexifié avec les frameworks basés sur le Java.
On peut déjà voir un certain pattern, là…

Slide 10. Du côté des langages interprétés, on peut voir le Perl comme étant quelque part un peu le fils spirituel du C, au moins en partie dans sa syntaxe, et a permis de faire des choses beaucoup plus vite et simplement que ce qu’on faisait en C, parce que langage interprété, typage dynamique, gestion de la mémoire.

Slide 11. On peut voir le PHP comme aussi un fils spirituel du Perl, il lui a emprunté pas mal de choses.
Dans les années 2000, dans le monde PHP (pour ceux qui s’en souviennent), on mettait en avant le fait que ceux qui utilisaient le Java, le JEE, c’était souvent les sociétés de service, parce que le Java c’est plus compliqué, ça prend plus de temps, on facture plus de jours-hommes, bref on fait plus de business avec. Alors que le PHP, c’était plus simple, plus facile, plus rapide, moins cher.

Slide 12. Le truc, c’est que par la suite, sous couvert de professionnalisation du PHP, on s’est beaucoup inspiré du monde Java. Et pas de souci, la professionnalisation du PHP c’est une très bonne chose.

Slide 13. Mais ça a ouvert la porte à d’autres plateformes, qui étaient perçues comme plus simples, quelque part étaient beaucoup plus cool.
Le Ruby on Rails pour le Ruby, le Django pour le Python, le NodeJS qui a ramené le Javascript côté serveur (comme ce que faisait Netscape dans les années 90 avec LiveWire) et le Go.

Alors j’ai une anecdote marrante sur le Go. Je connais plusieurs personnes qui ont été des développeurs PHP pendant plus de 10 ans et qui utilisaient des gros frameworks bien connus, et qui me disent que maintenant ils ont retrouvé le plaisir de faire du développement web grâce au Go.
Le Go. Un langage compilé, qui a été créé pour être un successeur du C, que certaines personnes disent de son modèle objet qu’il est complètement pété. Ben si aujourd’hui il y a des gens qui préfèrent faire du développement web en Go plutôt qu’en PHP, c’est sûrement qu’on s’est trompé de direction à un moment.

Slide 14. Et vous pouvez voir que les êtres humains aiment beaucoup passer par des phases de complexification et de simplification.
Aujourd’hui je pense qu’on est prêt pour revenir à quelque chose d’un peu plus simple, plus proche du PHP lui-même.

Slide 15. Alors, il y a un article que j’aime beaucoup, écrit par Avery Pennerun, qui est le patron de TailScail, qu’il a publié l’été dernier. Alors l’article est très très long, mais très intéressant ; je vous invite vraiment à le lire. J’en ai pris juste une petite partie.
Il dit que :

Beaucoup de tâches quotidiennes qui étaient autrefois simples pour les développeurs sont aujourd’hui devenues compliquées.

L’empilement de complexité est devenue tellement haut qu’on envisage sérieusement de coller des LLMs par-dessus pour qu’ils écrivent le code incompréhensible dans des frameworks incompréhensibles pour qu’on n’ait pas à le faire nous-mêmes.

Dans l’informatique moderne, on tolère des temps de compilation interminables, suivis de builds Docker, l’envoi vers des registres de conteneurs, des déploiements qui prennent plusieurs minutes avant que le programme ne tourne, et encore plus de temps avant que les logs ne soient accessibles quelque part. Tout ça parce qu’on nous a fait croire que tout devait absolument passer à l’échelle. (au sens « tout doit être scalable »)

En tant qu’industrie, on a consacré tout notre temps à rendre possibles les choses difficiles, mais aucun à rendre faciles les choses simples.

J’aime beaucoup cet article, je vous invite vraiment à le lire en entier, il est très très intéressant, et je pense que ça va tout à fait dans la voie de ce PHP Way of Life.

Slide 16. Alors, ce manifeste, c’est quoi ?
C’est 11 chapitres, disponibles en plusieurs formats − vous pouvez voir que le PDF fait 73 pages, donc ce n’est pas juste un petit article de blog.
Et c’est pas que issu de mon cerveau malade, il y a plus de 80 références et citations de personnes comme Rasmus, DHH le créateur de Ruby on Rails, Jeff Atwood le créateur de StackOverflow, les créateurs des langages Go, Closure, Erlang, les créateurs de Django, de PostgreSQL, le fondateur de NPM et Gina qui membre de la core team PHP. Et plein d’autres personnes.

Slide 17. Donc dedans, qu’est-ce qu’on trouve ?
Une introduction sur PHP et son histoire. On va parler des tableaux, des objets, du typage, des interfaces web, des bases de données, des frameworks, des tests automatisés, des microservices, des APIs et de la sécurité.
Pour vous donner juste un petit avant-goût − ça prendrait beaucoup de temps d’entrer plus dans les détails − j’ai sélectionné 4 chapitres sur lesquels je vais faire un petit avant-goût.

Slide 18. Par exemple, sur le typage, j’imagine qu’ici il y a des gens qui se disent développeuse ou développeur Symfony, et qui savent que pour coder proprement aujourd’hui en PHP il faut activer les strict types, parce que sinon ça veut dire qu’on ne sait pas coder, qu’on n’est pas un vrai développeur ou développeuse. Mais avez-vous remarqué que dans le code de Symfony les strict types ne sont pas activés ? Et que Symfony ne pousse même pas à utiliser les strict types. Doctrine c’est complètement autre chose, on est d’accord, mais pas dans Symfony. Ça devrait quand même soulever quelques questionnements.
Dans le chapitre, il y a aussi un lien vers une RFC écrite par Gina, qui propose de supprimer l’option des strict types et qui explique pourquoi.

Slide 19. Autre petit focus, sur les tests automatisés, juste pour dire que si vous avez un code coverage de 100% à vos tests unitaires, mais que vous n’avez pas un seul test d’intégration, c’est sûrement que vous avez raté quelque chose en cours de route.

Slide 20. Autre chose. Si vous faites une application web c’est différent, mais si vous faites un site transactionnel classique (on clique sur un lien on charge une page, on envoie un formulaire on charge une page), a priori vous n’avez pas besoin d’un framework Javascript. La vidéo est marrante, je la laisse se dérouler. C’est quand même un peu ça aujourd’hui le Javascript.

Slide 21. Dernier petit focus sur les bases de données, juste un tweet intéressant écrit par François Zaninotto. Alors François c’était le co-créateur de Propel, qui était un des deux ORMs majeurs PHP dans les années 2010, qui dit qu’aujourd’hui il n’utilise plus d’ORM. Voilà, je pose ça comme ça…

Slide 22. Et donc, le but de tout ça c’est quoi ? C’est pas de dire qu’il y a une seule manière de coder en PHP.
Je ne demande pas aux gens d’être d’accord avec ce qui est écrit, ni en totalité ni en partie. Mais juste d’activer un petit peu la réflexion. De se dire que les bonnes pratiques qu’on nous met en avant depuis un certain temps, celles qui sont proposées par des entreprises qui ont plusieurs centaines de développeurs, si vous, vous avez une équipe de 8 personnes, c’est certainement pas les bonnes pratiques qui s’appliquent à vous. Les outils, les moyens, les technos doivent être adaptés à chaque situation.
Et il y a une sorte d’unification qui est présentée depuis quelque temps, qui ne se justifie certainement pas, et à mes yeux − pas que à mes yeux encore une fois il y a beaucoup de références − revenir à quelque chose de plus proche de ce qu’était le PHP à la base a sûrement du sens aujourd’hui.