Coups de cœur au Forum PHP 2019
Thifaine, développeuse web, revient sur sa découverte du Forum PHP.
Pour ma toute première participation, j’ai eu la chance d’être en compagnie de collègues de chez M6Web, dont certains présentaient eux-mêmes des conférences.
En comparaison à d’autres conférences, j’ai été agréablement surprise par l’attention particulière portée aux problématiques de gaspillage et de protection de l’environnement. Ainsi les sponsors avaient été sensibilisés en amont par les bénévoles de l’AFUP : aucun flyer n’était présent dans le tote bag de bienvenue, une boîte de troc était mise en place et peu de vaisselle jetable était présente sur les lieux.
Autre petit plus de l’organisation : la retranscription en direct (bien qu’elle ne soit pas toujours très compréhensible) ! Elle rend le Forum plus accessible, et en l’occurrence, a apporté un petit côté fun plutôt apprécié.
Concernant les conférences, les sujets se recoupaient plutôt bien et la présence d’un second track permettait un choix diversifié. Dans un souci d’impartialité, je n’évoquerai pas ici les conférences de Pascal Martin et Benoît Viguier, mes collègues de M6Web.
Je vous partage en revanche mes deux gros coups de cœur : la présentation “Writing Effective PHP” de Nuno Maduro et “Le TDD dans la vraie vie avec Panther” d’Adrien Lucas.
Writing Effective PHP — Nuno Maduro
“Expect the worst”
Nuno Maduro nous offre (dans un anglais parfaitement intelligible) une présentation avec Live Coding particulièrement intéressante.
Il nous explique comment créer des applications robustes, sécurisées, testables et faciles à maintenir en adoptant les différentes pratiques défensives suivantes :
- Make state immutable : Utiliser des attributs privés, supprimer les setter et rendre l’état privé
- Always assert all inputs : Il recommande notamment l’utilisation de la librairie berbelei/assert
- Clear API contract : Utiliser la PHPDoc sur les classes et méthodes afin d’afficher l’objectif/utilité réelle de l’objet
@return array<string, string> will allow string[], string and also [key, value]
- Make classes final by default : De façon à informer clairement que la classe en question n’est pas destinée à être étendue, ce qui force ainsi les développeurs à privilégier une réflexion autour de la composition au lieu d’utiliser l’héritage
- High quality testing : Le but étant de tester tous les scénarios et résultats possibles
- Do not ignore static analysis : Il recommande ici l’utilisation de PHPStan et PHPInsights, la définition d’objectif de complexité cyclomatique et une couverture test de 100% (réel).
Le TDD dans la vraie vie avec Panther — Adrien Lucas
Adrian commence par illustrer les différents avantages d’avoir une suite de tests complète ; en quoi l’utilisation de tests permet d’éviter les tests manuels, répétitifs et ennuyeux, éviter les erreurs d’oubli et de manipulation et faciliter les montées de version.
Il donne plusieurs arguments afin de justifier l’implémentation de tests dans le cadre de projet client (notamment à petit budget), et notamment avec la métaphore du chirurgien : le chirurgien ne demande pas à son patient s’il doit se laver les mains avant de l’opérer.
Il présente ensuite les 3 lois du TDD :
- Vous ne devez pas écrire de code de production tant que vous n’avez pas un test en erreur
- Vous ne devez pas écrire plus de lignes de test qu’il n’en faut pour que le test passe
- Vous ne devez pas écrire plus de code de production qu’il n’en faut pour que le test passe
Une fois que les tests passent, on met en place du refactoring.
De manière générale, la TDD est la meilleure façon de respecter les principes SOLID, d’assurer l’exhaustivité de la couverture et d’avoir du code testable.
Mais alors comment limiter les coûts de maintenance à la suite de tests ?
Adrian présente les différents types de tests et les outils couramment associés :
- Tests unitaires : PHPUnit
- Tests d’intégration (ou fonctionnels) : WebTestCase
- Tests de bout en bout : Selenium
Pour faciliter l’implémentation des tests, il recommande la mise en place de Panther (projet libre PHP dépendant du paquet Facebook/webdriver). Panther consiste en une extension du WebTestCase avec l’implémentation de nombreuses fonctionnalités telles que : waitFor, takeScreenshot, getMouse->mouseMoveTo…
composer req panther
Nous assistons d’ailleurs à une illustration de ses propos via une session de live coding où Adrian utilise le maker bundle pour générer ses fichiers de tests.
Je reviens également sur trois autres présentations plus techniques mais tout aussi intéressantes :
Clean Architecture — Nicolas De Boose
“Don’t mock what you don’t own”
Selon Nicolas De Boose, la clean architecture présente plusieurs avantages :
- Indépendance vis-à-vis des librairies externes
- Code plus lisible
- Pas besoin de test end-to-end
Par le biais d’un exemple concret, il nous présente les différents composants de la clean architecture : port, interface, adapter… Et il nous explique ensuite comment mettre en place un projet utilisant la clean architecture par le biais de la division du code (implémentation d’un vrai MVP — Model View Presenter) et la mise en place de use cases au cœur du projet.
Il recommande notamment l’utilisation d’adapters implémentant des interfaces et permettant de faire concorder l’appel vers une librairie externe (exemple : l’envoi de mails via Swiftmailer).
GraphQL : Plus de raison de ne pas essayer ! — Aurélien David
Aurélien nous rappelle les principes de GraphQL : il s’agit d’un langage permettant aux clients de faire des requêtes spécifiques (contrairement à l’utilisation de endpoint). Il permet de facilement agréger des données provenant de multiples sources et retourne uniquement les données demandées par le client.
Aurélien reprend les différents préjugés concernant GraphQL afin de mieux les remettre en cause et proposer des tentatives de contournement :
- GraphQL breaks the cache
GraphQL n’utilise pas le cache HTTP. On peut alors : ne pas mettre en cache les requêtes de mutation, utiliser la méthode GET au lieu du POST (mais limitation en termes de caractères), créer un hash de la requête à transmettre à la requête et communiquer la liste des hash au serveur. - GraphQL is slow
Il s’agit d’une problématique liée à l’imbrication des données, qui nécessite de fetch les relations de l’entité. L’utilisation de DataLoader permet d’optimiser les requêtes avec imbrications. Le pattern DataLoader utilise également un système de cache (mémorisation et applicatif). - Complexité et depth
Il existe des attributs de configuration pour limiter ces deux points. - Authentification et autorisation
GraphQL ne gère pas du tout de système d’authentification, ni d’autorisation. L’authentification doit être gérée au préalable. L’autorisation peut être gérée directement via les resolvers. - GraphQL is impossible to monitor
Il est possible de forcer le client à donner un nom aux requêtes afin de le voir.
En résumé, ce premier Forum PHP fut pour moi riche en apprentissage et m’a inspirée à proposer de nouvelles optimisations sur les projets auxquels je participe.
Pour plus de retours sur les événements organisés par l’afup en 2019, vous pouvez retrouver notre article sur la 1ère édition de Symfony Live à Lille.
De plus, nos collaborateurs participent régulièrement à des événements phares du monde de la Tech. N’hésitez donc pas à vous abonner à notre compte Medium pour suivre nos prochains retours de conférences et réaliser votre veille professionnelle.
Retrouvez aussi nos publications et notre actualité via notre newsletter, ainsi que nos différents réseaux sociaux : LinkedIn, Twitter, Youtube, Twitch et Instagram
Vous souhaitez en savoir plus ? Consultez notre site web et nos offres d’emploi.
L’autrice
Web developer @M6Web & Partner Tech Linkvalue
