4 vertus qualité logicielle promyze as

M. Lehman l’a très bien décrit dans ses lois : un logiciel qui évolue continuellement voit sa qualité baisser, si on ne fait rien contre, jusqu’à ce qu’il devienne impossible à maintenir (ou trop coûteux), puis inexploitable. [Source: Wikipédia]

Certains diront que c’est le destin et qu’il n’y a pas grand-chose à faire… d’autres diront qu’il faut se prémunir de ce déclin en investissant massivement dans la qualité logicielle.

Et si la réponse se trouvait au milieu ?

A titre de réflexion, pourquoi ne pas revisiter les 4 vertus cardinales de Platon mais dans un contexte de qualité logicielle ?

En effet, pour Aristote, le disciple de Platon, « la vertu est essentiellement ce dans et par quoi l’homme se rend supérieur au destin, grâce à la maîtrise de ses passions et à l’exploitation de ses possibilités d’action ». [Source: Wikipédia]

La Prudence

Investir dans la qualité logicielle est un investissement prudent, absolument nécessaire.  On le sait, ne pas investir dans la qualité logicielle est imprudent : la dette technique va irrémédiablement augmenter et les coûts de maintenance vont exploser.

Etre prudent c’est au minimum mesurer la qualité de son logiciel. On peut notamment exploiter les linters qui permettent de mesurer automatiquement le nombre de défauts, fortement corrélés avec la qualité du code. On peut aussi mesurer la qualité de son code avec les tests et les notions de couverture.

Etre prudent c’est aussi mesurer a priori l’impact d’une modification sur la qualité de son logiciel. On parle de dette assumée lorsque l’on est conscient de l’impact négatif d’une modification sur la qualité logicielle, mais qu’on la réalise en toute connaissance de cause.

Etre prudent c’est enfin mettre une chaîne d’intégration continue qui va automatiser les contrôles de qualité, en jouant notamment régulièrement les tests (après chaque commit) pour garantir un bon niveau de qualité.

La Tempérance

La qualité logicielle est une préoccupation de tous les jours mais à quel rythme et à quel niveau ? Faut-il imposer un haut niveau de qualité à tout moment ? Ou plutôt se mettre à améliorer la qualité uniquement quand l’impact sur le business devient trop important ? Là encore, il y a un juste milieu.

Etre tempérant c’est se fixer un cadre qui va optimiser notre investissement dans la qualité tout en assurant une efficacité optimale. C’est surtout savoir apprécier dans la durée les efforts appliqués dans la qualité logicielle et mesurer leur plus-value.

Etre tempérant c’est par exemple définir un niveau minimal de qualité logicielle au-dessous duquel il ne faut pas aller. Plusieurs outils proposent notamment des mécanismes bloquant interdisant les commits qui ne respectent pas un certain niveau minimal de qualité. On peut mettre un niveau minimal (quality gate) sur le nombre de défauts ou sur un seuil de couverture du code par les tests.

Etre tempérant c’est aussi mettre en place des mécanismes permettant d’améliorer l’attention portée à la qualité logicielle en fonction des différents moments clés d’un logiciel. S’adapter au rythme des projets est nécessaire. Il n’est en effet pas efficace de régler des problèmes de qualité à quelques jours de la livraison.

Etre tempérant, c’est enfin savoir prendre le temps d’analyser une baisse ou une hausse de qualité, et de prendre les mesures nécessaires en temps voulu. La découverte d’un bug, fusse-t-il important, ne doit pas remettre en cause des mois d’investissement dans la qualité logicielle.

La justice

L’investissement dans la qualité logicielle doit être juste ! C’est-à-dire qu’il doit correspondre intégralement à vos objectifs et à vos contraintes. Il ne sert à rien de vouloir répliquer l’architecture support à la qualité logicielle mise en place par Google etc. si vous ne partagez pas les mêmes contraintes qu’eux.

Etre juste c’est définir les objectifs de qualité au niveau de l’entreprise, du projet, et de l’individu. A chaque niveau correspond un niveau de qualité logicielle. Tous les projets d’une entreprise n’ont certainement pas les mêmes contraintes.

Etre juste c’est aussi proposer un environnement outillé support à la qualité logicielle. Si la qualité logicielle est l’affaire de tous, les moyens doivent être mis en place et les responsabilités doivent être clairement établies. [Voir – Les 3 erreurs à ne pas commettre dans la qualité logicielle]

Etre juste c’est aussi savoir accompagner tous collaborateurs et bien préciser leurs rôles dans la qualité logicielle (développeurs stagiaire ou senior, chef de projet, manager, dirigeant, etc.). Les gains de qualité ne sont efficients que si tous les collaborateurs sont pleinement impliqués et pleinement conscient de leur rôle.

Le courage

Cette vertu est bien connue et est d’ailleurs au centre des approches agiles. En effet, il faut du courage pour améliorer durablement la qualité d’un logiciel !

Etre courageux c’est être capable de modifier même légèrement ses propres pratiques pour intégrer la qualité logicielle.

Etre courageux c’est être capable de mettre en place des environnements supports à la qualité logicielle. Ces environnements sont déstabilisants au début mais offrent des bénéfices plus qu’important.

Etre courageux c’est enfin accepter de moins subir le rythme infernal des livraisons et assurer plus sereinement le futur. C’est quand on n’a pas le temps qu’il est urgent d’en prendre pour s’occuper de la qualité logicielle.

Prudence, Tempérance, Justice et Courage

Si la prudence est la mère de toutes les vertus, tempérance et justice seront nécessaires pour mener avec courage votre stratégie de qualité logicielle.

Notre époque change drastiquement, à une vitesse folle. Et pourtant, ces 4 vertus s’imposent dans tous les services de développement que nous croisons.

Ne reflètent-elles pas simplement le bon sens nécessaire à l’obtention d’une qualité durable sur tous vos développements ?

Pour continuer la réflexion, cet article pourrait vous intéresser :

https://www.promyze.com/blog-comment-demarche-clean-code/

Start connecting developers' knowledge with Promyze

Best coding practices shared from IDEs & Code reviews

Promyze, the collaborative platform dedicated to improve developers’ skills through best practices sharing and definition.

Crafted from Bordeaux, France.

©2023 Promyze – Legal notice