[:fr]La parole est aux speakers : Jean-François Lépine[:]

Publié le

[:fr]Jusqu’au Forum PHP 2017, retrouvez nos interviews de speakers pour mieux comprendre leur parcours et le sujet qu’ils aborderont lors de leur conférence !

La conférence

Faut-il faire du travail de qualité ?

Laissez moi vous raconter l'histoire de Bob et Alice, dont les enjeux sont assez complexes (spoiler : ça sent le vécu) : Deux développeurs (Bob et Alice) doivent estimer le temps de développement d'un site ; Bob pense finir en une semaine ; Alice en 8 semaines.
Lorsqu'on interroge Bob, il répond qu'il s'agit là d'un site vite fait ; comme il ne fait que peu de bugs, il n'aura pas à déployer souvent, alors un simple serveur FTP devrait suffire. D'ailleurs il a déjà un serveur pour un autre client, il suffira de tout mettre dessus et d'ajouter un vhost ni vu ni connu. Pour les tests, ça prend trop de temps (et c'est vraiment désagréable !), donc pas la peine. Pour les spécifications, on est agiles non ?
Lorsqu'on interroge Alice, elle explique qu'elle ne peut travailler sans Jira, Jenkins, Gitlab, PHPUnit, Capistrano, Docker, Yarn, Bower ni Gulp sous peine de fournir un travail de mauvaise qualité. Elle a donc tenu compte du temps d'intallation et de configuration de ces outils. Elle doit d'ailleurs étudier la Blockchain, ReactJs et Kubernetes pour affiner le temps estimé.
Qui a raison ?

Ta conférence est intitulée « Faut-il faire du travail de qualité ? », et tu vas y dépeindre deux visions du développement diamétralement opposées : y a t-il un de ces profils de développeur-e-s que tu rencontre plus souvent ? D’ailleurs, qu’est-ce qui t’a poussé à proposer un tel sujet ?

Je pense que deux visions opposées du web s’affrontent en ce moment.
Pour être caricatural : les « aigris », qui regrettent le temps où télécharger jQuery et FileZilla suffisait pour faire un site; et les « buzz-addicts », qui aiment utiliser toutes les technologies à la mode au fur et à mesure qu’elles sortent.
Je rencontre principalement des développeurs qui rentrent dans la seconde catégorie ; et c’est bien normal, tout le monde aime apprendre de nouvelles choses. Mais je vois également de plus en plus de développeurs qui regrettent la course à la nouveauté, principalement dans l’écosystème JavaScript.
Quand je discute avec les uns et les autres, l’argument de la qualité ressort quasi systématiquement. Il faut « faire du code de qualité ». C’est une sorte de quête du Graal, mais où chacun semble se faire sa propre idée de ce qu’il faut rechercher.
C’est tout cela qui me pousse à proposer cette conférence : partager mon expérience et mes réflexions sur ce sujet, et voir s’il n’existe pas des outils / pratiques pour savoir vers quel chemin une équipe doit se diriger lorsqu’elle construit un projet.

Peux-tu nous présenter ton projet PHPMetrics ?

PhpMetrics est un outil d’analyse statique de code source ; l’idée générale est de demander à un robot de lire votre code source, puis de vous fournir des indicateurs sur la manière dont votre code source est architecturé et composé.

PhpMetrics est né de mon travail quotidien : lorsque l’on fait un audit de code, une des principales difficultés réside dans la capacité à rendre des éléments très techniques accessibles à tous, y compris aux personnes non-techniques (décideurs, chefs de projet…).

Je souhaite permettre à tous, y compris les non-experts, de comprendre la manière dont le code source est construit.

Au début je calculais à la main un certain nombre de métriques, que je reportais dans un classeur Excel pour en faire des graphiques lisibles. C’est un travail rébarbatif, et assez rapidement, l’envie d’automatiser une partie de ce travail m’est venue.

L’analyse statique est très vite devenue pour moi une passion, et je dois avouer que j’ai dévoré pas mal de thèses sur le sujet, thèses que j’essaie au fur et à mesure de retranscrire en algorithmes, et que j’intègre à PhpMetrics. Aujourd’hui, PhpMetrics fournit plus de quarante métriques, et la liste grandit. Il rivalise largement avec les outils similaires des écosystèmes Java, C++ ou .Net…

Un des enjeux de PhpMetrics n’est pas technique, mais ergonomique : comment rendre tous ces chiffres (très barbares!) lisibles. J’expérimente beaucoup, et d3js m’a beaucoup aidé !

Je suis fier de voir qu’aujourd’hui le projet est assez utilisé, et je suis très curieux de voir comment les contributeurs vont le faire évoluer par la suite.

Tu as lancé autre projet sur le Mutatesting. Qu’est-ce donc que cette pratique ?

C’est une sorte de monstre ! Et je crois que la pratique n’est pas prête de se démocratiser dans l’écosystème PHP, c’est peut-être encore un peu trop tôt…

Les tests de mutations permettent d’évaluer la pertinence des tests unitaires. Les tests unitaires testent le code, mais qui teste les tests unitaires ?

C’est le rôle des tests de mutation : cet outil lance vos tests sur du code source légèrement modifié (muté, par exemple en supprimant un « else » ou en remplaçant « == » par « != ») ; si le test unitaire est pertinent, la modification de code devrait le mettre en échec.

C’est une pratique très ancienne, mais qui commence seulement à se démocratiser, car très longue, coûteuse en CPU et avec beaucoup de faux positifs.

L’originalité de MutaTesting est qu’il utilise PhpMetrics pour évaluer les classes dont la probabilité de bugs est élevée, et ne teste que les tests unitaires associés.

MutaTesting est sorti il y a déjà longtemps, mais il reste expérimental. Si la pratique vous intéresse, je ne peux que conseiller d’utiliser humbug qui reste largement plus utilisé.

Une conférence présentée par

Jean-François LÉPINE
Jean-François LÉPINE
Passionné par la qualité logicielle et l'industrialisation. Créateur de PhpMetrics.

Autres interviews

[:]