Forum PHP 2019 : Jour 2

Les Jeudi 24 et Vendredi 25 Octobre dernier se tenait à Paris le Forum PHP, organisé par l’AFUP (Association Française des Utilisateurs de PHP).

Le compte rendu par Louis des conférences données le 24 octobre est disponible ici. On y parle de writing effective PHP, d’application résiliente, de tests, de failles PHP et même de neuroatypie dans le milieu de l’IT !

Vous trouverez ci-dessous un compte rendu de plusieurs conférences données le 25 octobre.

1- Le TDD dans la vraie vie avec Panther

Adrien LUCAS, Expert Symfony et coach OOP pour Smile, nous a parlé lors de sa conférence des TDD (Test Driven Development), une méthode de développement qui consiste à écrire le code de production après le code de test.
Il nous a ensuite présenté Panther, un nouveau composant Symfony dont l’objectif est de vous simplifier l’écriture des tests d’intégration et des tests end-to-end.

Avant tout cela, il tient à nous rappeler l’importance des tests dans un projet. En effet, un projet non testé peut coûter de plus en plus cher au fur et à mesure qu’il évolue. Chaque nouvelle implémentation devient un bug potentiel pour le projet, ce qui peut entraîner une perte de temps pour la recherche et la résolution de celui-ci. Le coût final aura un impact au niveau du client, et on le sait tous, moins il est élevé, plus le client est satisfait.

En quoi ces tests offrent un gain de temps ? Et bien, le code est plus flexible, les développeurs n’ont plus peur de casser le système déjà en place, et inutile de devoir refaire des tests manuels, répétitifs et ennuyeux.

Adrien nous présente 3 lois du TDD:

• Vous ne devez pas écrire de code de production tant que vous n’avez pas un test en erreur. En effet pour écrire correctement un TDD, il y a 3 phases (écrire un test en erreur, écrire le code métier qui valide ces erreurs, et refactoriser le code)
• Vous ne devez pas écrire plus de lignes de test qu’il n’en faut pour qu’un test soit en erreur.
• Vous ne devez pas écrire plus de code de production qu’il n’en faut pour que le test passe.

Pour ces 2 derniers points, il est illogique d’alourdir le code avec des implémentations inutiles.

Pyramide des tests

Comme nous le montre la pyramide, le chemin allant de la finition de l’évolution à la fin des tests est long et sinueux.

Les tests se font en 3 étapes:

• Les test unitaires: afin de tester des portions de vos codes qui seront plus nombreux que les autres, mais autant efficaces. Ils sont réalisés le plus souvent avec PHPUnit.
• Les tests d’intégration: Ils permettent, grâce à un client, de tester l’assemblage des portions testées précédemment dans une utilisation concrète du produit. Contrairement aux tests unitaires, ceux-ci ne vont plus travailler avec des mocks mais vraiment avec d’autres services/bases de données internes/externes au projet. On utilisera ici le plus souvent les WebTestCase.
• Les tests de bout en bout ou tests fonctionnels. Pour ces derniers on pourra utiliser Selenium, et on testera le fonctionnement de l’application dans sa globalité, mais cette fois-ci, on s’attachera à vérifier l’intégrité des données reçues, mais également leurs affichages selon les critères d’acceptance préalablement défini.

Malgré tout cela, plus on grimpe dans cette pyramide, plus le coût devient élevé.
C’est donc là que Panther entre en jeu, car il va nous permettre d’effectuer des tests de bout en bout en utilisant notre propre navigateur Chrome ou Firefox (en mode Headless ou non).

Adrien passe donc pour sa deuxième partie sur un live-coding très intéressant qui va nous montrer, sur un cas d’usage basique toute la puissance de Panther.

Il faut savoir que Panther est compatible avec la norme WebDriver du W3C et qu’il implémente également WebTestCase que vous devez connaître si vous avez déjà fait des tests.

La prise en main de l’outil est très simple et est quasiment la même qu’avec le framework de test par défaut de Symfony.
Panther possède tout de même ses spécificités:

• Exécution du javascript directement via le browser
• Les captures d’écrans, très efficace lorsque notre test rencontre une erreur
• Simuler les mouvements du curseur
• Attendre l’affichage d’un élément qui par exemple s’affichera lors de certaines manipulations.

Cette conférence fut simple et efficace. Moi qui n’étais pas un très grand fan des développements pilotés par les tests, je dois avouer que mon avis a changé à la fin de ce talk.
Baser son code de production directement sur les tests nous permet d’être plus efficace lors son écriture, car les spécifications sont alors appliquées dès le début, et non au fur et à mesure que le code grandit.
Quand on produit les tests après le code de production, nos tests vont plus souvent respecter le code produit que les demandes fournies, donc nous pouvons avoir un produit totalement incomplet à la fin.
Pour ce qui est de Panther, pour avoir utilisé un produit similaire en JAVA, je trouve que ses spécificités sont vraiment un atout. La capture d’écran pour relever un bug ou l’attente d’affichage d’un élément en sont la preuve.

2- Tout pour se préparer à PHP 7.4

Damien Seguy, CTO à Exakat, société spécialisée dans les solutions pour la qualité du code source en PHP, nous a présenté les mises à jour effectuées lors de la montée de version vers PHP 7.4. Cette nouvelle version est d’ores et déjà disponible si vous voulez commencer à vous amuser avec vos applications, mais la release sortira le 28 novembre 2019.

Cette release apportera son lot de changements:

2.1- Les incompatibilités

• les ternaires imbriqués (qui ne sont pour moi, pas une bonne pratique, car beaucoup trop illisibles), devront contenir des parenthèses explicites, afin de ne pas avoir d’avertissement.

• Les balises de fin de documents changent.

• L’accès aux éléments d’un tableau via les accolades ne pourra plus se faire.

• Le type real ne sera plus disponible, il est fortement conseillé de les passer sur du float. Attention à vos sites e-commerce !

• La méthode array_key_exists ne fonctionnera plus que sur des tableaux. Néanmoins, elle sera plus rapide grâce à une transformation des valeurs en tokens.

2.1- Les modernisations

• Apparition des fonctions fléchées. Ces fonctions ne seront disponibles qu’avec une seule expression. Attention, fn devient un nom réservé.

• Les propriétés d’objet pourront être typées.
  On ne pourra plus accéder à une propriété tant qu’elle n’a pas été initialisée.
  Afin d’améliorer les performances, il est préférable d’utiliser le typage, ce qui évitera le cast à la compilation.

• Ajout du spread operator (…) pour les tableaux. Il sera également disponible pour la méthode array_merge.

• Ajout de l’opérateur Null coalescent (??). Si la valeur de la variable de gauche est null alors on prendra celle de droite.

• La méthode strip_tags pourra dorénavant gérer les tableaux.

2.3- Divers

• Suite à l’arrivée de FFI(Foreign Function Interface), on pourra écrire du C dans PHP.
• Il y aura un gain de performance allant de 1 à 5%

Cette mise à jour sera pour moi intéressante, grâce notamment aux ajouts des Spread Operator et des fonction fléchées, qui permet au PHP de s’aligner un peu plus aux autres langages. Le typage des propriétés d’objet et lui aussi très intéressant, surtout qu’il nous fait gagner en performance. Néanmoins, j’ai un petit doute sur l’implémentation du FFI, sera-t-elle vraiment utile ?

3- SYMFONY HTTPCLIENT VS GUZZLE VS HTTPLUG

Dans ce talk, Nicolas Grekas, grand contributeur au sein de la communauté Symfony depuis maintenant 6 ans, va nous présenter son nouveau composant, disponible depuis Mai 2019 lors de la release 4.3 de Symfony, nommé HTTPClient.

Il commença sa présentation par nous exposer différentes façons d’effectuer de simples requêtes réseaux en partant de la préhistoire à aujourd’hui avec notamment fopen(), cURL, Guzzle avec ces versions 3 (plus maintenue) et 5, et HTTPlug.

Ce composant a été créer afin d’avoir la meilleur performance HTTP possible. Il est compatible avec HTTP/2 et nous permettra donc de traiter des requêtes asynchrone streamées et multiplexées.

Pour les requêtes HTTPS, par défaut HTTP/2 est activé si la libcurl >= 7.36 est utilisée, tandis que si vous souhaitez l’utiliser pour les requêtes HTTP, il faudra alors le forcer via une option http_version:

Symfony HTTPClient vous permet également d’utiliser les méthodes Native PHP ou son extension Curl pour vos requêtes.

Pour ce qui est d’exécuter une requête, rien de plus simple que ce que nous utilisons actuellement:

Une méthode bien pratique nommée stream() est également disponible pour pouvoir traiter les réponses par ordres d’arrivée, au lieu d’éventuellement attendre toutes les réponses des différents services, ce qui pourra éventuellement nous faire gagner du temps.

Symfony HTTPClient nous propose également un client appelé “ScopingHttpClient” qui nous permettra d’appliquer les headers en fonction de l’url donnée pour une même instance du client. Pour faire simple, si une même instance appelle l’API Github et une autre API, je vais pouvoir customiser mes headers en fonction de l’API consommée, afin d’éviter d’envoyer mes Bearer Github à une autre API par exemple.

Ce nouveau module permettra donc d’avoir des applications plus optimisées avec Symfony. De plus, il ne faut pas oublier qu’une implémentation PSR-18 est disponible via la class Psr18Client qui permettra de passer de l’interface HTTPClientInterface à l’interface PSR18 ClientInterface.

Après cette présentation, Nicolas réalisa une démonstration en live de son nouveau composant. Le but de cette démonstration, est de télécharger 360 images et de comparer les performances de chacun des composants présentés précédemment.
Evidemment, Symfony HTTPClient arrive en tête avec une résolution au bout de 0,5 secondes seulement contre 2,5s pour Guzzle 5 et 2,7s pour HTTPlug.

On peut donc dire qu’HTTPClient tient toutes ses promesses. La démonstration parle d’elle même. La résolution est au moins 4 fois plus rapide que celles des autre composants, ce qui est quand même assez impressionnant. L’intégration aux projets déjà existant se faisant facilement, il ne nous reste plus qu’à essayer tout ça !

4- Symfony Checker

Lors d’un court talk, Valentine BOINEAU, alternante chez Symfony nous a teasé un nouvel outil d’analyse statique de code nommé Symfony Checker.

Ce nouvel outil se basera sur 3 graphes:

• l’AST (Abstract Syntax Tree) utilisé depuis PHP 7 durant la phase de compilation. Il nous permet comme son nom l’indique d’avoir une représentation syntaxique du code écrit. Dans ce type d’arbre, le noeud est l’opérateur et la variable la feuille qui lui sera rattaché. Par exemple pour l’opération suivante: 1+2–3 on obtient l’arbre suivant :

• CFG (Control Flow Graph) qui génére une représentation logique du code, en parcourant tous les chemins possibles. Il permet notamment de découvrir du code mort afin d’améliorer la propreté de notre projet.
• SSA ( Static Single Assignment) qui execute une analyse “lexicale” qui va modifier tous les noms des variables pour les rendre unique. Là encore, on peut voir si l’initialisation d’une variable est utile ou non, par exemple:

On remarque donc que la première initialisation la variable “x” est inutile, on peut donc la supprimer.

Symfony Checker n’est pas encore disponible, mais on sait déjà qu’il sera payant dès sa sortie tout comme l’est son grand frère Symfony Insight
(29 €/ mois/ projet).

Est-ce donc utile de payer pour un outil tel que celui-ci, et ce, même si le code qui en découle verra sa qualité accrue ? Ou faut-il davantage sensibiliser les développeurs sur la qualité de leur code ?

Conclusion

Ce fut ma première participation à un événement tel que celui-ci. J’ai été agréablement surpris de par la qualité des talks proposés ainsi que la qualité des intervenants. Cela ne m’étonne donc pas que l’événement perdure depuis plus de 10 ans.

A noter que l’AFUP nous donne rendez-vous le 15 mai 2020 pour leur prochain cycle de conférence, l’AFUP Day, qui se répartira dans 4 villes: Lille, Lyon, Nantes et Tours. A vos billets !