Tendre vers un idéal de qualité logicielle

L’idéal de qualité logicielle n’est pas un concept inconnu pour vous. Notamment côté développeur, vous êtes convaincus que la propreté du code et la façon dont il est testé, a une influence directe sur votre activité. Sans forcément le mesurer, c’est un sentiment qui paraît réaliste. Il se traduit par de nombreux aspects : la facilité à collaborer sur le code, le plaisir que vous prenez à travailler dessus, le nombre de bugs à régler, la rapidité avec laquelle vous pouvez faire évoluer le logiciel ou sortir des mises à jour, et j’en passe. C’est pourquoi vous avez commencé à mettre un certain nombre d’initiatives en place. Concernant les outils, il y en a peut-être un qui tourne et qui vous remonte des métriques sur le code et/ou des linters, vous avez peut-être défini des quality gates, que vous vous astreignez à respecter, vous faites attention à votre couverture de test etc. Côté culture d’entreprise, vous parlez ponctuellement de qualité de manière informelle quand vos indicateurs sont au rouge, de manière plus formelle dans certains rituels, rencontres, partages, et ainsi de suite. Vous allez peut-être même jusqu’à alimenter un ensemble de bonnes pratiques de développement.

Les outils et processus

Avec tout ça, vous êtes bien plus avancés sur le sujet que beaucoup d’entreprises : des outils et des processus. Et pourtant, on dirait que la mayonnaise ne prend pas. Ces initiatives sont trop éclatées, il n’y a pas de véritable esprit de corps autour de la qualité. Et en définitive, ces préoccupations sont les plus susceptibles d’être mises de côté dans une livraison importante, pressés par le temps, les coûts. Bref, vous avez atteint un seuil, qui vous empêche peut-être de franchir une nouvelle étape dans le développement de votre activité. Que faire pour tirer un meilleur bénéfice des outils, et insuffler une véritable culture de la qualité ?

Pourtant, ce n’est pas le moment de baisser les bras. Si vous tirez parti d’outils et de process, vous allez voir des résultats sur le court terme, et encore plus à long terme. Par exemple,le nombre de bugs qui diminue, donc des coûts de maintenance moindres, et du temps gagné employé à sortir plus de mises à jour et plus fréquemment. Il ne faut pas négliger l’impact positif que d’avoir le sentiment de travailler ensemble, avec des référentiels et des efforts partagés, qui améliorent et facilitent le travail de tous au jour le jour. Négliger l’idéal en qualité logicielle peut se payer très cher, très vite : impossibilité ou très grande difficulté à faire évoluer le code, équipes qui croulent sous les tickets de bugs… Alors qu’en l’incorporant directement dans vos développements dès le départ, le coût en temps est indolore et permet des mutations profondes, en douceur et durables.

Cet article se propose d’apporter une réponse. Il s’agira de comprendre ce qui éventuellement n’est pas encore abouti dans les choses que vous avez mises en place, et de voir ce qui peut être facilement implémenté pour voir des effets positifs sur votre idéal de qualité logicielle.

Tirer parti des outils existants

Ne me faites pas dire ce que je n’ai pas dit, on est TRÈS outils chez ProMyze. Mais chacun des outils qu’on utilise répond à un besoin. Son adoption est expliquée et comprise, afin que l’outil puisse s’intégrer facilement à l’équipe. L’outil est personnalisé pour coller au plus près à nos besoins, et on n’hésite pas à faire participer l’équipe.

Ainsi, en termes d’outils, on fait référence ici aux linters et autres solutions de qualimétrie permettant de suivre la qualité du code. Un linter est dans la majorité des cas un utilitaire dont l’objectif est d’aider à maintenir un code uniforme, sans vulnérabilités et avec certaines optimisations de performance. Installer un linter et l’exécuter n’est pas en soi le plus dur. On comprend d’ailleurs rapidement les informations produites par un tel outil. Partons donc du principe que vous avez ce type d’outils en place : comment s’en servir autrement pour en tirer d’autres bénéfices ?

Savoir placer les linters dans son environnement

Finalement, où placer un linter dans l’environnement de développement ? On le retrouve le plus souvent dans une étape d’intégration continue, où son rapport d’exécution est ensuite retranscris graphiquement pour informer les équipes. Malheureusement, un premier problème se pose ici : tout le monde ne consulte pas les outils d’intégration continue, et les personnes qui le font obtiennent des données sans savoir précisément que faire (corriger les problèmes ou pas ? est-ce à moi de le faire ?).

Par conséquent, pour diminuer les risques d’introduire du code non-conforme aux standards des linters, la plupart des environnement de développement (IDEs), tel que Atom, Sublime Text ou encore WebStorm, intègrent les linters sous forme de plugins. Grâce à eux, les linters s’exécutent en temps réel sur le code en cours d’édition. Cela permet éventuellement de se corriger avant de soumettre sa modification. On diminue ainsi les risques d’introduction de défauts.

L’importance de l’IDE

De plus, il faut garder en tête qu’il est très probable que l’adoption d’un linter dans l’IDE doive rester sur la base du volontariat. Chacun a sa façon de s’approprier les concepts et de se contrôler. Il nuirait à la façon de travailler de certains d’avoir ces indications dans l’IDE. Et ils sauront se réguler a posteriori lors des mises en commun sur les règles des langages, ou lors de la consultation du référentiel. Avec ou sans linters dans l’IDE, on se rend compte que finalement, les développeurs ont une perception subjective de la façon dont ils respectent les conventions. Il leur manquera peut-être une analyse plus poussée de leurs contributions, pour savoir sur quelles pratiques ils ont une attention à porter et surtout, comment faire. De plus, les informations remontées directement dans l’IDE restent un support préventif. Rien ne force leur consultation et la prise de décision. Ce n’est pas parce qu’on a un linter installé dans son IDE, qu’on se force à respecter toutes les règles du langage. L’adoption de l’outil passe par la compréhension de son rôle, sa personnalisation par rapport au contexte du projet et l’intégration de la qualité dans les processus de travail des équipes.

Enfin, un autre positionnement est de croiser a posteriori les données d’un linter avec d’autres sources de données, pour délivrer une valeur nouvelle aux équipes. C’est le parti que nous avons d’ailleurs pris chez ProMyze avec Themis. Il faut donc garder en tête qu’un linter amène toujours la même donnée brute, mais qu’elle sert différents acteurs à différentes étapes suivant la façon dont on s’en sert.

Intégrer la nécessité de les personnaliser

Nous l’avons vu dans un précédent article, les linters constituent un socle qu’il est important de s’approprier et de personnaliser. D’ailleurs, vous remarquerez que la très grande majorité d’entre eux sont configurables à des niveaux parfois très fins. On notera d’ailleurs que cette liberté de configuration provoque parfois l’effet inverse, comme le très populaire linter standards pour JavaScript qui se veut prêt à l’emploi et n’autorise aucune configuration, voyant cela comme une complexité à éviter.

Mais pourquoi personnaliser un linter ? Il y a d’abord l’aspect technique. La configuration du linter détermine les bonnes pratiques à suivre sur la rédaction du code source : si l’on n’est pas d’accord avec une règle, autant mettre à jour sa configuration. C’est avant tout à l’équipe de décider ensemble comment le code doit être écrit. Ensuite, il y a un aspect concernant la dynamique d’équipe. Par exemple chez ProMyze, on se réunit pour discuter des règles jusqu’à atteindre un consensus. Faut-il mettre à jour une règle, voire la désactiver ? Heureusement, tout cela renforce la culture du code chez nous grâce à l’implication collective. Une équipe qui s’implique dans l’appropriation de l’outil est une équipe qui est la plus à même d’en faire un bon usage.

Echanger sur les indicateurs d’objectifs 

Par ailleurs, plusieurs outils d’analyse statique de code permettent plus généralement de calculer des niveaux de dette technique, de couverture de code, de taux de duplication… Pour autant, si on installe ce type d’outil sans savoir véritablement ce qu’on cherche à en faire et sans le personnaliser, on risque très vite d’être désemparé par les métriques qui nous sont remontées et ne pas savoir quoi faire. Pas de panique, commençons par le commencement. Pourquoi est-ce que tout le monde monitore généralement des métriques sur son code ? Essentiellement car cela permet de moduler les efforts par rapport aux niveaux de criticité. Le but est de communiquer sur des indicateurs objectifs entre nous, avec le management, avec le client. Et on espère que ces métriques nous permettront d’agir.

Mieux communiquer à partir des métriques

Vous me voyez venir ? Dans beaucoup de cas, c’est loin d’être suffisant. La présence d’un référentiel de règles ne garantit pas son respect. Les stratégies qu’on peut adopter par rapports aux indicateurs sur les violations et la dette technique ont leurs limites. Il est difficile de savoir si les actions entreprises sont efficaces ou contre productives. Elles ne travaillent pas toujours sur l’engagement des développeurs dans l’idéal de qualité logicielle (la prise de conscience, l’envie d’agir, la motivation sur le long terme). Nous pensons qu’il faut adopter une gestion de la qualité logicielle, qui couple outils et processus, stratégie itérative et engagement.

En ce sens, il est important de rappeler les objectifs de la démarche et que tout le monde en ait bien compris le sens. Ensuite, il y a deux points importants à voir au niveau de l’équipe :

1. Des objectifs doivent être fixés pour aboutir à des résultats (réduction de dette, augmentation de couverture de code…) Comment les communiquer au niveau de l’équipe ? Quelles actions mettre en place (formation, sensibilisation…) derrière ?

2. La réalisation et le suivi des objectifs doivent être efficacement orchestrés. Comment peut-on ritualiser des échanges dédiés à la qualité logicielle ? Se demander par rapport à nos processus habituels, quand est-ce qu’il est le plus pertinent d’en parler ? De quelle manière ? Sans rien chambouler, intégrer progressivement la qualité logicielle au travail quotidien fait émerger d’une appropriation de la culture de l’idéal en qualité logicielle.

Adapter ses processus à la démarche

On a déjà évoqué au fil de l’eau dans cet article qu’il était important de faire émerger une culture de la qualité logicielle au sein d’une organisation. Et ce n’est pas facile, pourtant, c’est le garant d’une stratégie réussie. Tous les outils du monde ne se suffisent pas à eux même. Sans prétendre avoir la science infuse, nous partageons ici un petit retour d’expérience.

S’intégrer naturellement au quotidien

Dans un premier temps, ne faut pas que cette mutation prenne plus de temps, sinon la qualité logicielle est la première chose sur laquelle on fera l’impasse quand on sera pris par les délais et les coûts. Bien sûr, il y aura peut-être un petit surcoût en temps à l’adoption, qui devrait rapidement se lisser.

Dans un deuxième temps, la meilleure chose à faire, c’est de passer un peu de temps à regarder comment l’équipe est organisée. Quels sont les rituels ? Quand communique-t-on ? De quelle manière ? Il y a sûrement des initiatives individuelles qui sont très bonnes à prendre, et dont on n’a pas toujours conscience. Certains s’investissent dans des initiatives extra professionnelles, participent à des événements. Par ailleurs, il y apprennent des choses qu’ils aimeraient peut-être transposer à leur projet, pour peu qu’ils y reçoivent une oreille attentive. N’hésitez pas à faire émerger des rencontres informelles, de partage sur un livre, etc.

Plus formellement, essayez de déterminer quand on peut itérer sur la qualité logicielle. Imaginons par exemple, une rétrospective de fin de projet ou de sprint. C’est un bon moment. A-t-on respecté les objectifs qualité qu’on s’était fixé ou qu’on avait évoqué avec le client ? Comment on l’explique ? Quelles actions peut-on simplement mettre en place pour faire mieux la fois suivante ? Pourquoi ne pas les codifier dans la répartition des tâches ? Les évoquer quand nécessaire au daily meeting ? En parler, c’est avoir l’idéal de qualité logicielle souvent présente à l’esprit et induire une forme de responsabilisation.

Induire un cercle vertueux

En effet, quand personne ne consulte les métriques de qualité de code, ne fait d’efforts pour tester, on pourrait être tenté de mettre en place des mécanismes de blocage. C’est tout à fait compréhensif mais j’ai malheureusement le sentiment que cela fait plus de mal que de bien :

1. Cela ne résoud pas le problème de fond. Il y a quelque chose qui n’a pas été compris. Le déclic ne s’est pas produit pour donner envie d’agir. Il y a des événements extérieurs qui gênent. Il faut pouvoir analyser les causes et agir dessus, afin de construire quelque chose de durable. Cela prend du temps mais ça évite les effets pervers.

2. Quand on veut tricher, on peut toujours. Et on est capable de déployer des stratagèmes, peut-être plus complexes que de se conformer au système. A être restrictif, on peut dégrader de manière encore plus importante la qualité logicielle.

3. On peut briser la confiance. Admettons qu’on bloque l’acceptation de pull requests qui ne respectent pas certains standards. Tout le monde n’est peut-être pas d’accord sur les critères. On risque de créer un sentiment de frustration. Enfin si les objectifs n’ont pas été correctement véhiculés et qu’ils créent un climat de défiance, on peut aboutir à une situation très difficile.

Pour conclure

En conclusion, l’idéal de qualité logicielle doit faire partir de la normalité et atteindre un consensus. Il est facile de commettre quelques erreurs sur le chemin sur les outils ou les pratiques d’entreprises. Avec patience et pédagogie, n’importe quel projet peut franchir cette étape et favoriser son fonctionnement ou son passage à l’échelle. De plus, si vous avez le sentiment que la qualité stagne, vous pouvez pouvez travailler sur la culture de la qualité au sein de votre projet, en tirant partie des métriques de code, en créant une dynamique autour des outils et en les configurant tous ensemble. Enfin, mettez en place une dynamique interne qui promeut les échanges autour de la qualité, et qui fait passer le message que la qualité c’est important, et qu’elle peut s’intégrer sans surcoût en temps dans les développements quotidiens.

Enfin, n’hésitez pas à en parler avec d’autres entreprises autour de vous qui peuvent rencontrer les mêmes défis, ou même avec nous. Entre autre, si vous voulez un avis ou un retour d’expérience sur la gestion de la qualité logicielle, vers un idéal de qualité logicielle. Nous ne nous substituons absolument pas à toutes les initiatives que vous avez pu mettre en place.