Sofia Lescano, Jean Baptiste Nahan

8 Nov 2019

Code Rhapsodie s’est rendu au Forum PHP 2019 organisé par l’AFUP.

Ce forum a été placé sous le signe de l’inclusion et le respect en mettant en place cette année la vélotypie et rappelant le code de conduite de l’AFUP. L’écologie a eu aussi une place importante avec un grand effort de recyclage et la mise en place d’une boite à troc de goodies. Les conférences ont été variées même si certains thèmes tels que le Domain Driven Development (DDD), les tests, la programmation défensive et la résilience ont été très présents.

L’événement s’est conclu en rappelant que le Call For Papers pour l’AFUP day est ouvert jusqu’au 25 novembre.

WRITING EFFECTIVE PHP

Nuno Maduro nous conseille dans sa conférence de faire de la programmation défensive, en pensant ainsi que la pire situation possible arrivera.

Ils nous a présenté ses idées en 7 points:

Faire des objets à état immuable
Toujours valider les variables
API public = contrat clairement défini
Faire des classes final par défaut
Faire des tests de haute qualité
Réduire le nombre de fonctionnalités
Faire de l'analyse statique avec phpstan et phpinsights

Une conférence en anglais très abordable, claire et avec des exemples pratiques.

LA CLEAN ARCHITECTURE : POURQUOI ? COMMENT ? POUR QUI ?

Clean Architecture = Architecture Hexagonale + Onion Architecture + Streaming Architecture + MVP + Use-Case Driven Approach

Pour éviter que vos projets deviennent impossibles à maintenir, et ne plus savoir où mettre le nouveau code, Nicolas de Boose recommande de mettre en place la clean architecture.

Le code métier doit être découplé de toute librairie externe et de tout framework.
Les connexions avec les outils et frameworks externes se font via des adaptateurs qui implémentent une interface définie dans le code métier.
Le code métier ne sait pas comment les données sont sauvegardées, ni comment sont envoyés les courriels par exemple.
Le code métier doit être très bien couvert par les tests.
Utilisation du pattern MVP pour le traitement des requêtes HTTP.

Suivre cette architecture demande en général d’avoir plus de classes et il y a besoin d’un certain temps pour s’y adapter, cependant cela rendra votre code indépendant et facilement testable. Elle peut s’avérer très utile quand le métier est complexe et qu’un simple CRUD n’est pas suffisant. Sur un site web vitrine, il y a peu de chance que cela soit nécessaire, par exemple.

Une question qui revient souvent avec ce type d’architecture : où mettre le code ?

Pour répondre il faut d’abord répondre à la question : qui demande l’ajout du code ?

un besoin technique : dans les adaptateurs
un besoin métier : dans le code métier

Retrouvez les slides ici.

UNE APPLICATION RÉSILIENTE, DANS UN MONDE PARTIELLEMENT DÉGRADÉ

“Les choses vont échouer, c’est un fait”.
Pour Pascal, quand on parle de disponibilité d’une application, nous ne visons pas une application qui fonctionne toujours mais plutôt une application qui fonctionne bien presque tout le temps.
Ainsi, nous pouvons envisager d’attribuer une quantité de 9 que l’on souhaite pour notre application. Par exemple une application qui soit disponible 99.9% du temps ou que 99.9% des requêtes réussissent.
Il peut être tentant de partir sur une structure de microservices, mais il faut être vigilant à ce que l’on promet à notre client puisque les temps de disponibilité se multiplient entre des services qui dépendent les uns des autres. Avec des schémas simples fait à la main et plein d’humour, Pascal nous explique tout cela.

Il introduit ainsi trois concepts :

Le SLI (Service Level Indicator) qui mesure la qualité d’un aspect du niveau de service. On peut par exemple mesurer le taux d’erreur ou le temps de disponibilité.
Le SLO (Service Level Objective) qui va constituer la valeur cible pour un niveau de service mesuré par un SLI. Par exemple nous souhaitons que moins de 0.01% des requêtes d’un certain type échouent.
Le SLA (Service Legal Agreement) qui spécifie les conséquences si les SLO ne sont pas atteints.

Dans sa conférence, Pascal nous donne aussi plein de conseils et nous rappelle de penser utilisateur, les métriques sont importantes mais si l’utilisateur n’est pas content, il ne reviendra pas. Parfois, fonctionner en mode dégradé est plus intéressant que ne pas fonctionner du tout.

CONCEVOIR DES APPLICATIONS PHP RÉSILIENTES EN 2019

Faisant suite à la conférence de Pascal, Mickaël Andrieu nous a parlé d’un cas précis d’application résiliente.

Suite à une mauvaise expérience avec le dashboard de PrestaShop qui avait arrêté de fonctionner à cause d’une petite partie de celui-ci, il nous rapporte les clés de ce qui leur a permis d’améliorer la plateforme.

D’abord, il nous conseille d’améliorer notre infrastructure : faire appel à des services à haute disponibilité.
Puis, d’améliorer notre code : faire des requêtes avec des timeout, du code non bloquant, prévoir des fallback en cas de problèmes et surtout pouvoir fonctionner en mode dégradé.
Ainsi, il nous a présenté le pattern du circuit breaker et la librairie qu’il a développé et intégré à Prestashop. L’idée est d’avoir la maîtrise sur le comportement dégradé, d’être capable de fournir une réponse dégradée mais aussi de réessayer auprès d’un service externe.

Combinée avec la conférence de Pascal, ces deux conférences donnent un bel aperçu de comment rendre son application résiliente.

WHEN YOU GET LOST IN API TESTING

Paula et Antonio nous ont mis en garde de l’importance de faire des tests. Entre autres pour réduire les bugs, faciliter le refactoring et gagner du temps et de l’argent.
Ainsi, ils nous ont parlé de tests unitaires, tests d’intégration et tests fonctionnels à travers un exemple de puzzle simple et clair.
La conférence est en anglais, mais très abordable également. Si vous avez encore des doutes sur l’importance des tests, on vous la recommande !

SE PRÉMUNIR CONTRE L’IMPRÉVISIBLE : UNE ANALYSE DES FAILLES LES PLUS COURANTES EN PHP

Paul Molin est venu nous parler des failles le plus courantes en PHP à travers d’exemples concrets et quelques conseils. Dans sa conférence, il aborde le XSS, les problèmes de droits d’accès, les injections SQL, les exécutions de code en remote, les CSRF, le déni de service, les XXE et les dépendances vulnérables.

NEURO-ATYPIE ET IT : QUELQUES CONSEILS

Alex Rock se confie à nous dans sa conférence pour nous avouer qu’il est autiste et nous parler des personnes neuro-atypiques en général et des difficultés rencontrées au quotidien.
Il nous explique que pour les autistes, le comportement social doit être acquis et non pas induit ce qui peut rendre les interactions sociales difficiles. Ainsi, même si cela paraît évident, le mieux à faire lorsqu'on rencontre quelqu’un est de suspendre son jugement et d’être à l’écoute.
Dans sa conférence, Alex nous montre qu’il y a différentes neuro-atypies ainsi que différentes causes et conséquences de celles-ci.

Il nous donne quelques conseils pour le recrutement de personnes neuro-atypiques :

se renseigner sur la personne
être clair et précis sur les process
lui donner des conditions de travail adaptées (en particulier pas d’open space)
communiquer

Une conférence très intéressante et touchante que l’on vous recommande !

CONCEVOIR POUR DES FUTURS SOUHAITABLES

Avec un duo théâtral, Marie-Cécile Godwin et Thomas Di Lucco nous invitent à réfléchir sur le futur en nous partageant des futurs fermés, qui ne sont plus possibles et des futurs ouverts vers lesquels on peut toujours aller. Si le développement durable vous intéresse et que vous rêvez d’un meilleur futur, on vous recommande cette conférence.

SI DARWIN AVAIT RAISON, L'AGILITÉ FONCTIONNE PAR HASARD.

Encore une conférence théâtrale et atypique de François Zaninotto. Cette fois-ci, il incarne Eugène Fournier un professeur en sciences spécialisé en insectes. A travers une métaphore comparant agilité et sélection naturelle, il nous invite à réfléchir sur pourquoi l’agilité fonctionne en entreprise et de plus en plus d’entreprises l’adoptent.

AGRESSIVE PHP QUALITY ASSURANCE IN 2019

Marco Pivetta commence sa conférence avec entre autres cette diapositive “PHP est horrible, l’expérience est le roi”, son conseil est : “appropriez-vous de la qualité de votre code pour sortir de la boucle infinie des dates boutoir qui enchaînent avec du travail et des missions pompiers où l’on a jamais du temps pour faire de la qualité”.
Pour cela il nous propose quelques conseils :

Mieux coder : faire du pair programming, faire de la relecture de code par les pairs et avoir des discussions dans l’équipe avant d’écrire du code
Comprendre le besoin
Avoir un ADR (Architecture Decision Record) pour avoir un historique de ce qui a été décidé par qui, comment et pourquoi
Automatisation des tâches et du déploiement qui permettent de passer en production que si toutes les tâches se sont réalisées correctement
Analyse statique du code
Tests
Monitorer son application
Trouver de la stabilité, par exemple en testant l’API avec OpenApi. Se prémunir contre les BC Breaks.
Maintenir son application à jour
Coding style

SYMFONY HTTPCLIENT VS GUZZLE VS HTTPLUG

Nicolas Grekas est venu nous présenter le Symfony HTTPClient
C’est un nouveau client HTTP pour PHP qui propose quelques avantages :

Prise en charge de HTTP/2
Stream de l’upload et du download
Asynchrone bien géré
Support de Symfony : gage de qualité et d’évolution lié au framework
Scoped client (cas: token d’auth pour un domaine spécifique et pas les autres)
Protection contre les appels internes (ex: webhook configurable par les utilisateurs)

DE CRUD À DDD, COMMENT MEETIC A SAUVÉ SON LEGACY

Retour d’expérience sur le passage du site Meetic du “MVC = CRUD” au “DDD”.
Le métier de Meetic est complexe et en constante évolution. Ils doivent répondre à des problématiques légales et éthiques dans de bonnes conditions. L’utilisation des entités avec les getters/setters générant de plus en plus de problèmes, il fallait aller vers autre chose.
Le DDD avec ces nombreux concepts (découplage du métier et de la technique, architecture en oignon, architecture hexagonale...) et designs patterns (CQRS, ES, Port & Adapter) leur a apporté de nombreux réponses.
Le découplage des décisions techniques et des décisions métiers leur sert de guide pour savoir où placer le code (dans l'hexagone ou en dehors).
Ainsi, il peuvent être à jour sur l’utilisation de toutes les librairies tierces utilisées (car le code est lié à la technique et donc en dehors de l'hexagone).

L'ARCHITECTURE PROGRESSIVE

Mathieu Napoli nous présente son retour d’expérience sur la recherche de “LA SOLUTION PARFAITE”. Cette dernière n'existant pas la solution dépend du problème et doit être adaptée à la situation.
La solution dépend du métier (complexité, criticité), du business (selon la phase : exploration, extension, extraction) et des humains (compétences, stabilité de l’équipe...).
Selon lui, la complexité technique doit être inférieure ou égale à la complexité métier. Au final, un code legacy c’est un projet qui a réussi.
Le découpage courant des projets est horizontal (ex: DB, ORM, Repository, Entity et Service, Controller) alors qu’un découpage vertical apporte plus de solutions.
Le découpage par module permet de traiter chaque module séparément et parfois avec des solutions complètement différentes. Ainsi, la cohérence n’est plus une priorité.
La duplication du code en fonction du contexte métier n’est pas un gros mot tout comme CRUD, SQL, et HARDCODER.
L’architecture est progressive car elle s’adapte au cas actuel pour y répondre.

Retrouvez les slides ici

PRATIQUONS LA PHYSIQUE AVEC STAR WARS !

Roland Lehouc nous explique avec humour des concepts de physique en s’appuyant sur Star Wars: la force, la puissance, l’effet joule ...
Ainsi nous avons découvert qui est le jedi le plus puissant ! Regardez sa conférence et découvrez la réponse !