Automatiser la qualité

La qualité dans le développement, c’est un peu ce qu’on appelle volontiers la software craftsmanship : c’est le souci du travail bien fait, avec des choix techniques réfléchis, du code rempli de bonnes pratiques qui optimise sa maintenabilité, le soin de ne pas perdre du temps à travailler sur des points inutiles ou à faire manuellement ce qui peut être automatisé…

Tout le monde en veut, tout le monde (ou presque) dit le faire… mais dans la vraie vie, on est souvent loin de cette vision idyllique.

Améliorer votre qualité logicielle repose en fait sur deux piliers. Il faut :

• que vos devs aient le bon état d’esprit, et
• qu’un maximum d’aspects fastidieux soient automatisés, afin qu’ils·elles puissent se concentrer sur de la valeur ajoutée.

L’état d’esprit : comment faire ?

Créer cette culture craft (qui conçoit la production logicielle comme un artisanat, et recherche donc une haute qualité de résultat à même de créer une fierté légitime), ce n’est ni évident ni rapide. Ça se bâtit avec une combinaison de formation et d’expérience.

Les formations doivent ainsi s’assurer que l’apprentissage technique ne fasse jamais l’impasse sur les aspects qualité, et s’attache au contraire à mettre en avant les meilleures pratiques et la facilité de leur mise en œuvre. Chez Delicious Insights, nous avons toujours eu à cœur de proposer dans nos formations des fils rouges de développement qui bannissent le classique et déprimant « bon, en production, on ne ferait pas comme ça… », et qui prouvent qu’on peut mettre en place des meilleures pratiques critiques (par exemple des tests automatisés pertinents et performants) avec très peu de code, et donc en très peu de temps.

Pour capitaliser sur l’expérience de production, il est indispensable de propager au plus tôt les meilleures pratiques au sein de la base de code du projet et dans sa gestion de projet (par exemple dans l’utilisation qualitative des issues et pull requests / merge requests sur GitHub ou GitLab). Les devs restent des humains, et apprennent donc beaucoup par mimétisme : à force de voir du code quali, des pratiques soignées, des revues de code réfléchies et constructives, on tend progressivement vers le même standard de qualité pour son propre travail.

Il se trouve justement qu’en automatisant au maximum ce qui peut l’être, tant dans la production de qualité que dans son contrôle, on élimine le « bruit » des phases de revue de code (notamment le fameux bikeshedding), ce qui permet à chacun·e de se concentrer sur de la revue à valeur ajoutée : parler de l’archi, de l’approche technique, de la performance, des meilleures pratiques établies, etc.

Que peut-on automatiser ?

Beaucoup de choses, tant au sein des livrables que dans le contrôle de leur conformité. Et on priorisera tout ce qui est fastidieux à faire manuellement, car les devs, comme tous les humains, sont un peu paresseux (et devraient avoir mieux à faire).

Voici une liste non exhaustive :

• Pour le code (au sens large), on peut analyser statiquement que le contenu est conforme aux règles syntaxiques, qu’il respecte les meilleures pratiques (génériques et « maison »), et qu’il est exempt de problèmes bien connus. C’est notamment le travail des linters. On peut aussi le formater automatiquement selon des règles faisant consensus en interne et le plus près possible des normes établies de l’industrie. Tout ceci peut se faire aussi bien dans l’éditeur (à la volée et à la sauvegarde) qu’en vérification voire correction automatique avant un commit ou lors d’un push.
• Afin d’optimiser la lisibilité et donc l’exploitation de l’historique de gestion de sources, on peut garantir une norme bien établie d’écriture des messages de commits et de nommage des branches.
• On peut aussi exécuter automatiquement des vérifications « maison » sur le contenu d’un commit imminent (par exemple pour éviter des éléments dangereux ou obsolètes, des réductions normalement temporaires de la suite de tests, etc.)
• Les tests automatisés peuvent être lancés automatiquement à chaque push, sur tout ou partie des branches, et conditionner l’intégration à la branche principale de développement, par leur bonne exécution mais aussi leur taux de couverture, qui peut être contraint à la non-régression par exemple.
• L’intégration continue ainsi obtenue permet de piloter de la livraison continue en recette (avec un environnement unique ou des environnements automatiques par branche fonctionnelle), voire en production, fiabilisant les mécanismes de version et de déploiement.
• À partir du code et de sa configuration, nombre d’éléments peuvent être produits automatiquement et donc toujours à jour : documentation technique interactive, guide de style et bibliothèque visuelle de composants réutilisables, définitions de type, client API, publication sur référentiel centralisé…
• Avec le bon outillage, les références automatiques croisées entre tickets, revues de code et commits permettent le déplacement automatique des tickets dans les tableaux de suivi (ex. Kanban) au fil de leur évolution, jusqu’à leur cloture automatisée.

Que peut-on mesurer ?

Sans mesure, il est difficile de savoir si on progresse, ou simplement de déterminer si la mise en place d’une politique a eu un effet bénéfique ou adverse, ou simplement acceptable au regard de l’investissement en ressources qu’elle a nécessité.

La plupart des automatismes ont un impact mesurable qui permet la mise en place de nombreux indicateurs parmi lesquels vous êtes libres de choisir les KPI (Key Performance Indicators) les plus pertinents pour vous. Voici quelques possibilités :

• Les manipulations automatiques au niveau du commit (en particulier les reformatages) sont mesurables en volume. Leur réduction au fil du temps peut indiquer qu’elles sont intégrées de plus en plus tôt (ex. à la volée dans les éditeurs) voire que les devs se sont approprié les bons usages directement.
• De nombreux modes d’évaluation de la complexité de code existent, pour la plupart des langages populaires. On peut les mesurer automatiquement pour chaque revue de code, et grapher l’évolution au fil du temps à divers niveaux d’agrégation.
• Les taux de succès et de couverture des tests automatisés sont historisables (et peuvent conditionner l’acceptation de revues de code), et devraient augmenter avec le temps pour tendre vers 100%.
• Le recours à des messages et descriptifs normalisés pour les commits, tickets et revues de code permet l’analyse automatique du cycle de vie du code au sein du projet voire de projets croisés. On peut ainsi mesurer finement la vélocité du travail, de la phase de spécification au déploiement en production, à divers niveaux de granularité.
• Les performances back-end mais aussi front-end (ex. Core Web Vitals) sont mesurables et historisables, tout comme les tailles des artefacts produits (bundles JS, CSS, images, vidéos, binaires, images Docker…)
• La survenue d’erreurs en tout point de la base de code (back et front) devrait faire l’objet d’un reporting systématique à l’équipe pour leur traitement, à partir de quoi on peut analyser l’évolution de leur fréquence, de leur temps de résolution, du taux de récurrence, etc.

En quoi peut-on vous aider ?

Dans un premier temps, nous définissons ensemble vos priorités et objectifs quantifiés, ainsi qu’un budget global (en temps ou coût par exemple), qu’on peut imaginer sur plusieurs tranches révisables. Pour faire cela finement et justement, nous avons besoin de nous imprégner de votre activité : environnement métier, équipes, processes et outils existants…

À partir de là, nous pouvons vous faire de nombreuses recommandations sur tous les aspects : outillage, technologies, frameworks et bibliothèques, bonnes pratiques, conventions, etc. Si vous le souhaitez, nous pouvons vous accompagner dans la mise en place concrète de tous ces points, ainsi que dans la formation de vos équipes pour qu’elles s’approprient pleinement ces évolutions (ou à tout le moins, nous pouvons produire la documentation interne des nouvelles pratiques associées).

Nous vous aidons enfin à mettre en place un reporting automatisé des métriques qui vous importent, afin d’aider tout le monde à suivre la progression qui résultera de ces nouvelles pratiques, ce qui est toujours plus motivant !

Parlons-en !