(Par Damien Le Troher)

Après un bon petit-déjeuner et l’ouverture de ce Forum PHP 2019, Frédéric Bouchery nous a livré son approche au sujet du “code parfait”. Et si ce code n’était pas cette chose systématiquement sur-architecturée, sur-sécurisée, sur-patternisée dont beaucoup d’entre nous, techniciens, rêvent ?

Frédéric, avec son humour habituel, nous a apporté quelques éléments de réponses. Selon lui, nous sommes “notre propre futur Legacy” et un retour à la simplicité s’impose dans certains cas.

La PR parfaite serait donc celle qui enlève plus de code qu’elle n’en rajoute ?

Nous codons pour les autres et pour notre “futur nous-même”. En ce sens, nous souhaitons avoir un code lisible, court, simple à appréhender. Dans certains cas, il serait donc de bon goût d’éviter de sur-sécuriser notre code (trop d’exceptions, trop de conditions, etc). Il serait également bon de se demander pourquoi nous utilisons des abstractions : “Ai-je besoin de Doctrine ou bien, puis-je utiliser un bon vieux MySQLi pour cette opération ?”.

Ce sont, je trouve, d’excellentes questions.

Frédéric a aussi rappelé qu’il vaut mieux “pas d’abstraction qu’une mauvaise abstraction”... Qu'y a t-il de plus vrai que cette affirmation ? Il va plus loin : Quid des getters/setters ? Finalement, une classe “Point” ne pourrait-elle pas se contenter de propriétés publiques “x” et “y” ? Il va même jusqu’à s’attaquer aux contraintes de codage : pourquoi vouloir limiter la longueur d’une ligne lorsque c’est important (par exemple pour le message d’une exception) ?

Ce qu’il faut retenir de cette conférence selon moi ? Les règles ne sont pas immuables et nous donnent un cadre mais, selon le contexte, il faut savoir les ignorer. Finalement, les développeurs en devenir devraient nous remercier d’avoir fait preuve de recul !

Pour en savoir plus

Par Damien Le Troher

Quand j’ai découvert le programme du Forum PHP, j’ai absolument voulu assister à cette conférence ! En effet, le sujet de l'accueil des nouveaux collaborateurs me tient particulièrement à coeur, surtout depuis la mise en place du Synolia Camp.

Et l’intervenante, Cindy Liwenge, a comblé mes attentes ! Durant son colloque, elle a donné de précieux conseils ! Des choses qui peuvent paraître élémentaires mais qui, malheureusement, ne le sont pas tant que ça dans nos métiers.

Par exemple, connaître parfaitement l’application sur laquelle la personne en reconversion va travailler (contexte, intention, etc) est un prérequis indispensable : on ne place pas une personne sur un projet Legacy sans documentation ni mentor ! Il est essentiel de l’aider à “apprendre à apprendre”. Dans notre secteur, nous avons l’habitude de nous former en permanence, à tel point que cela est devenu évident. Nous savons où et comment chercher mais il faut ensuite être capable de transmettre ce savoir aux juniors.

Une autre notion m’a particulièrement marqué : “valoriser les compétences transférables”. C’est pour moi l’élément le plus intéressant dans le recrutement des profils en reconversion : la diversité des compétences. Cindy (Lien LKN) suggère également de proposer des bootcamps internes ou des sides projects pour aider les nouveaux arrivants à appréhender le métier.

Un autre aspect de la conférence m’a particulièrement intéressé : elle a invité les entreprises à se poser des questions spécifiques sur l’entrée des personnes en reconversion : “Comment est-ce que tu veux apprendre ?”, “Qu’est ce que tu peux apporter ?” - en opposition à “tu es un enfant...” Autant de réalités qui étaient difficiles à formuler et que Cindy a parfaitement su nous restituer.

Pour en savoir plus

Par Laurent Conroux

Pour Marco Pivetta, garantir la qualité de son code est plus difficile en PHP que dans d’autres langages. Pour autant, l’évolution récente du langage et des frameworks va dans le sens d’une nette amélioration, et cela va continuer.

Aujourd’hui, en 2019, qu’est-ce qui garantit la production d’un code de qualité ? Avant tout, la Quality Assurance n’est pas une question de personne. L’erreur est humaine et nous sommes tous susceptibles de nous tromper sans garde-fou. Il faut tout d’abord limiter les opérations manuelles qui sont sources d’erreurs. On ne peut pas non plus compter sur le regard des autres pour débusquer ces fautes. Le soft testing est donc mort. L’automatisation des tests est par conséquent capitale car, en plus d’éviter les erreurs humaines, elle favorise la mise à jour fréquente des librairies : les outils et les tests sont là pour garantir le bon fonctionnement du programme.

Pour cela il faut :

• Mettre les règles de gestion, ou users stories, à l’intérieur du code et de préférence au format behat (en utilisant par exemple ads-operator).
• Automatiser les tests pour que chaque modification du code soit bloquée dès que l’un d’eux ne passe plus.
• Utiliser des outils d’analyse statique du code, y compris au niveau du repository (psalm et deptrac sont cités comme exemples). Par conséquent, il est donc préférable de concentrer tout le code sur un seul repository.
• Ne pas se limiter à phpunit pour les tests. L’intégration continue permet de détecter des erreurs qui échappent parfois aux tests unitaires.
• Infection permet de multiplier l’efficacité des tests en introduisant des mutations dans les données fournies aux fonctions testées.
• Le style de codage est aussi important : un outil comme phpbench permet de s’améliorer.
• Le monitoring de son application apporte également des informations intéressantes.
• L’intégration des spec dans les API permet de les tester correctement et donc d’obtenir une plus grande stabilité… et on ne craint plus les mises à jour !

Par Damien Le Troher

Durant sa conférence, Adrien Lucas a parlé de tests automatisés et de développements pilotés par les tests (Test Driven Development). Cette technique de développement, issue de l’extreme programming, paraît idéale pour la plupart des développeurs mais n’est pas toujours facilement réalisable.

Tout d’abord, Adrien est revenu sur l’intérêt des tests et sur la raison pour laquelle nous, développeurs, devons tester. Il a rappelé à juste titre que cela faisait partie intégrante de notre travail et que ce n’était pas une option.

Il a également rappelé des évidences que nous avons tendance à oublier : avec le temps, notre code s’érode ; chaque modification est un bug potentiel ; le coût de l’évolution s’élève avec le temps ; le client est mécontent, etc. Derrière son discours, se cache l’ombre de la dette technique.

Les tests sont une réponse à ces problématiques. S’ils ont un certain coût, ils nous évitent néanmoins un avenir chaotique, et encore une fois, ils devraient faire font partie de nos développements.

Durant son discours, l’intervenant a également parlé de la façon de produire en TDD (test en échec, codage, test réussi, refactorisation et on réitère), ainsi que les règles de base qui régissent le TDD :

• On n’écrit pas de code de production tant qu’on n’a pas un test en erreur.
• On n’écrit pas plus de lignes de test qu’il n’en faut pour le mettre en erreur.
• On n’écrit pas plus de lignes de code de production qu’il n’en faut pour avoir le test en succès.

Adrien nous a également donné sa vision sur l’outil Panther. Il nous a même fait une démonstration d’utilisation (pour du test fonctionnel). L’outil permet de piloter un navigateur pour effectuer de véritables tests fonctionnels (Si vous ignorez ce qu’est un test fonctionnel, je vous l’explique ici).

Suite à cette conférence, je retiens que l’utilisation de Panther en PHP semble relativement simple. La suite ? Effectuer un bench de l’outil en interne à mon retour.

Pour en savoir plus

Par Damien Le Troher

Venant du monde Magento, je manipule beaucoup les caches ! Pour ceux qui ne connaissent pas Magento, sachez que la question “t’as vidé ton cache ?” est probablement la plus posée dans un openspace travaillant sur cette technologie.

Bref, les caches, on aime bien ! Et depuis un certain temps maintenant, Magento conseille d’utiliser le service Redis pour la gestion des caches et de la session.

Je pensais savoir utiliser la chose quand Grégoire Pineau est venu nous parler de Redis en tant que “Base De Donnée pour de vrai” !

Première slide, premier choc : Redis se persiste “sérieusement” via deux systèmes : RDB et AOF. Je mets des guillemets à “sérieusement” car malgré tout, Grégoire nous a rappelés qu’on ne met pas des factures ou des commandes dans Redis. Ce n’est pas fait pour ça !

Il est longuement revenu sur les types de Redis et sur les opérations possibles avec ceux ci (Hash, Sets, Sorted sets, Lists, Geo, etc), puis nous a montrés quelques exemples de scripts LUA (et oui, on peut scripter dans Redis).

Il nous a aussi présentés quelques outils :

• phpredis vs predis
• redis cluster pour la scalabilité
• redis sentinel pour la haute disponibilité
• de nombreux plugins, RedisJSON, RediSearch, Neural Redis, etc.

Ce que je retiens de cette conférence ? Redis est une base de données ultra réactive qui peut être utilisée dans les opérations du quotidien ne nécessitant pas de persistance trop critique. Cela m’a donné envie de me lancer dans un petit POC interne sur un cas d’usage sur lequel Redis serait parfait : la mise en mémoire des tables à plat de Magento.

Pour en savoir plus

Par Sylvain Plançon

Le sujet de cette conférence animée par Pascal Martin ? La disponibilité et la résistance de nos applications. Nous savons qu’il est impossible d’être certain que les applications que nous développons soient fonctionnelles à 100% pendant 100% du temps. D’autant plus qu’aujourd’hui, les applications sont quasiment tout le temps dépendantes d’une autre application ou d’un service qui lui même n’assure pas d’être disponible à 100%.

Pascal Martin nous a justement rappelés l’importance d’avoir une application capable de répondre malgré un service tiers qui est tombé. Il vaut mieux présenter des données légèrement dégradées que pas de données du tout, surtout si ce service tiers n’est pas un service essentiel au bon fonctionnement de l’application.

Par exemple, si votre application doit afficher en temps réel des informations en provenance d’un service tiers, conservez en cache une réponse valide de ce service pour pouvoir continuer de l’afficher tant que le service ne répond pas.

Autre sujet de ce colloque : la SLA, le SLO et la règle X-nines pour définir les règles de disponibilités des applications. L’intervenant a évoqué la nécessité de bien prendre en comptes les SLA des services tiers pour ne pas mettre une contrainte de disponibilité plus élevée qu’un service essentiel au fonctionnement de l’application, comme par exemple votre hébergeur. Si celui-ci assure une disponibilité de 99,99%, vous ne pourrez pas assurer une disponibilité de 99,9999%

Pour en savoir plus

Par Laurent Conroux

Dans le cadre d’un live coding, Nuno Maduro a exposé sa vision des bonnes pratiques pour produire du code robuste. Concrètement, il est fortement adepte du defensive programming… quand le contexte et l’équipe du projet s’y prêtent, bien sûr (pas pour un poc par exemple).

Après de nombreuses années à contribuer à des projets open sources (Laravel ou encore PHP Insights), voilà les principes qu’il a retenus et qu’il applique à ces projets :

• L’immutabilité des classes est capitale : le constructeur doit être le seul à avoir la possibilité d’altérer la classe. Pas de setter donc, et les attributs sont toujours private. Oui private, et pas protected, parce que...
• Les classes doivent être finales par défaut. Ensuite, dans des cas particuliers, cela dépend. Si une classe n’est pas étendue, cela évite de mauvaises surprises lorsque l’on touche au code. Privilégions-la.
• Toujours vérifier la validité des paramètres de ses fonctions. Cela vous sauvera à un moment donné. Nuno conseille même de créer ses propres helpers pour simplifier son quotidien, ou bien utiliser la librairie beberlei/assert.
• En matière d’API, le contrat doit être clair et écrit explicitement dans le code lui-même. Un commentaire n’est jamais très évident pour celui qui découvrira le code plus tard, c’est à dire bien souvent nous-mêmes, deux ans après. La précision des commentaires est particulièrement importante et doit décrire les contrats de l’API le plus complètement possible : précisez bien les cas qui renvoient un résultat, ainsi que la forme qu’il prend (array ne suffit pas, préférez array<string, string> si le tableau comporte des clés). Enfin, les commentaires doivent énumérer les erreurs qui peuvent être renvoyées, car elles font aussi partie du contrat.
• Si les tests sont importants, il est encore plus important d’aller à l’essentiel dans son code : si l’on peut réduire le code, il est plus simple à tester.
• Et bien sûr, même si Nuno n’est pas revenu en détail sur les bienfaits de l’analyse statique du code, couverte par d’autres conférences, il est bon de rappeler que c’est un outil indispensable pour rendre son code efficace et robuste.

Pour en savoir plus

Par Laurent Conroux

C’est avec beaucoup d’enthousiasme et une présentation décalée que François ZANINOTTO a réalisé sa conférence dans la grande salle du Forum PHP. Mais c’est vraiment le fond de son discours qui nous a passionnés !

Il a notamment comparé les développeurs à des insectes et s’est présenté comme un entomologiste. Ce parti pris a renforcé l’idée que le raisonnement exposé était obtenu par la méthode scientifique. Il s’est également appuyé sur de nombreuses références à des études tout au long de sa présentation. Ce qui a permis une meilleure adhésion aux conclusions, à condition de ne pas décrocher (la forme étant tout de même très distrayante).

Pour le fond, François a d’abord rappelé que l’agilité augmente réellement le chiffre d’affaires des sociétés qui privilégient cette méthode. Il nous a ensuite indiqué ce qui rend les méthodes agiles meilleures que les autres.

Selon lui, les rituels, s’ils ne sont pas forcément inutiles, ne sont pas non plus nécessaires et n’ont pas d’impact particulier sur l’efficacité des méthodes agiles. Il s’agit juste d’un choix de communication interne.

Ce qui compte, c’est le nombre de propositions faites au client et le rythme soutenu des retours qu’il fait sur ces propositions. Le volume et le degré d’innovation des propositions sont favorisés par un environnement positif et la “sécurité mentale” des équipes est indispensable pour obtenir les meilleurs résultats.

En conclusion, pour progresser vers la croissance, il faut rendre les gens fantastiques et maintenir un rythme très soutenu d’échanges avec le client. De quoi réfléchir pour améliorer - encore, toujours - nos pratiques quotidiennes !

Pour en savoir plus

Par Laurent Conroux

Lors de cette conférence, Benoit Viguier a présenté le retour d’expérience de M6 Web sur le fonctionnement asynchrone de php en production.

Le choix initial entre Amp ou Reactphp s’est finalement porté sur Amp en raison de sa meilleure gestion des erreurs. On utilise donc Yield pour résoudre les promesses en faisant attention au piège des boucles. Pour pouvoir changer de serveur, la team s’est créée un jeu d’interfaces, baptisé Tornado. C’est une EventLoop locale qui lance le fonctionnement asynchrone. Tout ce qui suit ensuite fonctionne en mode asynchrone.

Une méthode promiseAll permet de regrouper les appels concurrents pour tous les lancer en même temps. Evidemment, si les appels ne sont pas concurrents, c’est-à-dire s’ils ont besoin des réponses des appels précédents, le mode asynchrone est inutile.

Un exemple de gain de temps en mode asynchrone a été fourni et montre l’intérêt du système. Mais quels en sont les inconvénients ?

Tout d’abord, les promesses génèrent beaucoup de code supplémentaire. On perd également le typage car toutes les méthodes appelées deviennent des promesses (tous les return sont des promises quelles que soient les données retournées). Il faut donc sur-commenter dans l’IDE pour conserver les informations que le typage aurait fournies.

La stack trace est également parasitée par énormément de bruit car elle contient tous les events quand l’un d’eux rencontre un problème. C’est la même chose pour les informations données par blackfire qui en deviennent illisibles.

Pour l’anecdote, si la call stack est lisible, c’est que la fonction asynchrone est mal faite et que les appels ne sont pas concurrents : un bon moyen de repérer une erreur de construction de son code ! Sinon, il peut y avoir un ralentissement du CPU dû au fait que l’EventLoop tourne en permanence ou s’il y a un abus de requêtes.

Enfin, pour les développeurs, il est nécessaire de prévoir plus de temps de réflexion pour savoir comment optimiser tout cela.

Pour en savoir plus