On était au ForumPHP 2020

Utopie de la généricité - Frédéric Bouchery

L'objectif est de répondre à la question : est-ce possible de concevoir du code générique, réutilisable et qui dure longtemps ?

Pour répondre à cette question, il faut prendre en compte la durée de vie du projet. Quand on veut rendre trop générique, on complexifie automatiquement alors qu'une partie du code ne sera surement jamais utile. Voici quelques pistes pour avancer sur le sujet :

• Ne pas prévoir à trop long terme. Utiliser un système de notation pour savoir si c'est vraiment utile et dans quel délai. (ex: si c'est utile dans plus d'un an, on ne le fait pas tout de suite)
• Entretenir son code car plus il est complexe, plus l'espérance de vie du produit est courte
• Challenger le fonctionnel pour savoir si des features sont encore utiles
• Nettoyer son code.
• Connaître la vision du business/produit pour orienter son optimisation/ménage.
• Mettre en place des logs pour vérifier si des pages/fonctionnalités sont utilisées.
• Vérifier si des dépendances ne sont pas chargé pour rien dans le composer.json

Entretenir son code, ce n'est pas perdre du temps mais c'est en gagner pour l'avenir.

Auto-critique de la code bienveillante - Kim Laï Trinh

Les objectifs de la revue de code sont multiples : qualité du code, formation des développeurs, diffusion des bonnes pratiques de l'équipe, etc.

Il s'agit d'une vraie interaction sociale donc il faut le faire avec bienveillance.

Un retour sur une PR va avoir un impact différent en fonction de la personne. Le but n'étant pas de ne pas tout faire réécrire, sinon, autant le faire soit même. Ceci démotivera le développeur qui finalement va écrire du code en fonction de celui qui va le relire pour réduire le nombre de retours.

Un junior a souvent l'impression de ne rien avoir à redire sur les PRs d'un développeur expérimenté mais c'est faux. Il faut que toute l'équipe contribue à la revue de code et en tirent de la reconnaissance de leurs contributions et gagnent en autonomie.

On peut profiter d'une revue de code pour dire "C'est une bonne idée d'avoir fait ça comme ça, ça sera plus facile à maintenir", il ne s'agit pas forcément de dire ce qu'il ne va pas.

Attention aussi à la multitude de retours, est-ce toujours grave de laisser passer quelques bugs sur une partie non critiques ? Le développeur verra son code passer en prod et le corrigera si besoin mais il aura l'impression d'avoir vraiment participé et non publié du code qui ne lui appartient pas vraiment.

Dernière chose, il faut mettre son égo de côté, ne prenez pas un retour personnellement, vous n'êtes pas votre code.

En conclusion, la revenue code est le résultat d'interactions sociales, elle doit permettre de rendre un code lisible et compréhensible par tous.Il faut laisser de l'espace nécessaire à chacun, même un junior peut avoir des retours sur un développeur plus expérimenté si on lui laisse cette espace.

Quoi de neuf sur drupal 9 - Marine Gandy

Pour certains, Drupal évoque un outil ringard bourré de code legacy, mais depuis la version 8, il intègre Symfony, Twig et Composer.

• Drupal est un CMS et un CMF.
• API First : REST, JSON, GraphQL
• Structure plus modulaire avec une restructuration totale de la version 8 sur Symfony 4.
• Cycle de release maintenant calqué sur celui de Symfony.
• Passage à twig et abandon du HTML/PHP dans les templates.
• Utilisation de composer et même composer 2 depuis début octobre.
• Travail en cours pour le support php 8.
• Les concepts se standardisent, les hooks disparaissent progressivement pour laisser place aux event listeners.
• Côté performance : le système de cache a été affiné.
• Notion de tags et de contextes pour supprimer le cache d'une langue par ex. 
• Lazy load sur les images.
• Mise en place de SemVer et de l'outil "Rector" pour proposer les correctifs automatiques.
• Drupal reste aussi une usine à sites et utilise "entity share" pour le partage de contenus.
• Outil de génération de sites statiques possible.

L'idée de passer en revue toutes ces évolutions, c'est de montrer que les projets avancent.A chaque nouveau projet, posez-vous cette question :  Quel outil/CMS/Framework est le plus adapté à mon besoin ?

Les outils évoluent donc faites de la veille et ne restez pas sur une mauvaise expérience en excluant automatiquement un outil.

PHP, c'est vous ! Et vous pouvez contribuer ! - Martin Supiot & Pascal Martin

Si je vous dis comme ça de but en blanc : "Contribuez-vous à PHP ?". Il y a de grande chance pour que vous me disiez que non. C'est vrai que formulé comme ça, on s'imagine tout de suite entrain d'écrire du C et pousser une Pull Request au core du langage. Donc formulé comme ça, je comprends que vous ne soyez pas nombreux.

C'est de ce sondage qu'est née l'idée de cette conférence. Martin & Pascal ont tout deux contribué à PHP, chacun à sa façon. Et de leur expérience, il nous ont apporté 50 idées pour contribuer à PHP.

Car PHP, ce n'est pas qu'un langage, donc contribuer à PHP ne peut pas se limiter à "écrire du C". PHP c'est un écosystème, il y a beaucoup de personnes qui l'utilisent ; certains écrivent des librairies, des frameworks, des livres ; d'autres organisent des événements ; bref contribuent à son essor à ton rayonnement.

Donc contribuer à PHP c'est aussi :

• lire / commenter / approuver les RFCs du langage : prenez part son avenir
• contribuer à des extensions du langage : car PHP est riche en extension
• tester les nouvelles versions de PHP : la communauté a besoin de retours sur ce qui fonctionne, ou pas
• écrire des tests pour le langage PHP : ça se fait en PHP et ça permet d'augmenter le coverage du langage
• écrire un livre, un article, un tweet parlant de PHP : parlez de votre amour de ce langage
• contribuer à des librairies, frameworks écrits en PHP : c'est améliorer l'écosystème dans son ensemble
• sponsoriser des auteurs de librairies : c'est leur donner les moyens de faire de meilleurs outils
• organiser, accueillir, financer, des événements PHP (Forum, Meetup, etc :...) : c'est permettre à l'écosystème de vivre
• ... (oui il y en avait vraiment 50)

Une conférence pleine de positif, qui donne le sourire et nous fait complètement re-penser notre réponse du début...

Alors je vous la repose : Contribuez-vous à PHP ?

Une organisation au top

Alors bien sûr, au-delà de ces 4 conférences, il y en avait bien d'autres, et qui nous ont tout autant intéressés, comme How your PHP application can get hacked, and how to prevent that from happening? d'Anti Rossi ou encore Performance : mais que se passe-t-il après le backend ? de Jean-Pierre VINCENT et plein d'autres qu'on vous invite à voir ou même revoir sur le site de l'AFUP.

Au delà des conférences, le Forum PHP c'était aussi des rencontres sur la plateforme WorkAdventure mise en place. Ce fut l'occasion d'échanger entre participants, sur notre stand sponsor entre autre.

Pour finir, nous aimerions remercier du fond du cœur l'AFUP pour cette édition du Forum PHP. Prestaconcept était très heureux d'être sponsor de l'événement et de participer à cette édition célébrant les 20 ans de l’AFUP et les 25 ans de PHP. Malgré le contexte, l'AFUP a réussi à nous faire passer un très bon moment et on ne va pas se le cacher, ça fait du bien de voir autant de monde réuni pour échanger. Nous espérons pouvoir vous retrouver très vite pour en apprendre toujours plus !

Une dernière chose

Et avant de se quitter, on voulait vous rappeler que nous avons créé le Jeu de la Pull spécialement pour cette édition anniversaire du Forum PHP qui est téléchargeable sur sa page dédiée maintenant ouverte à tous.