La qualité logicielle

Nous incorporons dans nos méthodes de développements des outils et des principes (principalement issus de l’Extreme Programming) visant à favoriser la qualité logicielle et nous en sommes fiers. Cependant, il est difficile pour nos interlocuteurs, souvent futurs clients, d’en apprécier la valeur. Nous avons pour cela mis au point une brève démonstration des ces outils et principes que nous proposons à nos visiteurs. Elle est généralement très appréciée car, à défaut de rendre compréhensible ce qu’est le développement ou la qualité dans le développement, elle démontre notre démarche à vouloir rendre un travail de meilleure qualité et nous permet de concrétiser nos contrats. Pourtant cette qualité reste toujours complexe à prouver et encore plus à justifier, face à des offres de confrères qui ne les appliquent pas ou peu (et sont donc moins chers mais pas toujours). Essayons ici d’expliquer ce qu’est la qualité logicielle telle que nous la concevons, et ses atouts. Nous utilisons le terme de qualité « logicielle » car bien que nous fassions des applications web, nous pensons que ce concept s’applique à tous les développements informatiques.

Préambule : La qualité du code ne fait pas la qualité du produit 

On pourrait penser qu’un code de qualité entraîne forcément la réussite de votre produit. Si votre produit ne répond pas aux besoins des utilisateurs, aussi bien conçu techniquement soit-il, votre produit ne sera pas un succès. Cependant des développeurs ayant une bonne approche sur le code ont de fortes chances d’avoir également une bonne approche sur l’accompagnement du porteur de projet.

Nous avons l’habitude de pouvoir juger d’une qualité de produit à l’achat

Pour la plupart des achats que l’on peut réaliser, nous avons des repères qui permettent de juger par soi-même ou par l’intermédiaire de tests les produits ciblés. Cette voiture est plus confortable et mieux équipée qu’une autre, cette maison est mieux isolée et de plus climatisée, cette perceuse a plus de fonctionnalités et de garantie, cette opérateur téléphonique a une meilleure assistance, cette revue décrypte les 10 points clés des smartphones actuels et le meilleur est <truc>, etc. Pourtant, même sur ces critères, la qualité ne sera réellement perceptible qu’à l’usage et sur la durée.

Le mythe du zéro défaut

Il serait réducteur de penser qu’un logiciel qui ne comporte aucune anomalie est de qualité. Imaginez une voiture qui soit garantie pendant 10 ans mais qui consomme 50L / 100km et ne dépasse pas les 30 km/h, serait-ce à vos yeux une voiture de qualité ? La qualité d’un logiciel dépend d’autres critères qui ne sont pas forcément perceptibles par le client, et le bug c’est-à-dire l’erreur reste humaine.

La qualité est un objectif à la conception

Ce que l’on ne peut contester, c’est que les produits de qualité ont été pensés dès leur conception pour répondre à des normes qui les rendent meilleurs, et qu’en revanche les produits pensés pour être le moins cher possible sont rarement de qualité. Il y a donc une intention de départ qui va conditionner la qualité à l’arrivée. Et dans la mesure où le code est de la rédaction et possède un niveau d’imbrication important, il ne faut pas croire qu’il est aisé à posteriori de remplacer un « morceau » de mauvaise qualité par de la bonne qualité. La « dette technique » est très longue à rattraper, et il n’est pas facile de trouver les développeurs compétents et motivés pour reprendre une mauvaise base de code (voir l’abandon du logiciel de paie de l’armée « louvois »).

Le développement logiciel est un artisanat

Ecrire un programme consiste à écrire des lignes de codes, des mots. On peut même y trouver une démarche littéraire justement quand on vise la qualité, pour que son code soit lisible et compréhensible par les autres, et déjà par soi-même car au final on écrit du code pour les humains qui feront évoluer le projet plus tard, et pas pour la machine. Il y a une infinité de possibilités pour écrire le code qui va réaliser une même action. Ce qui va justement déterminer la qualité, c’est quels choix vont être pris pour faire un code simple, compréhensible et testé. Ces trois critères vont déterminer la maintenabilité du code (sa capacité à être maintenu, donc éventuellement corrigé et amélioré). Pour répondre à ces besoins, le développeur doit donc être sensibilisé (comment faire un code simple et compréhensible), expérimenté (quels sont les outils les plus efficaces pour répondre au besoin client) et respecté. Il/Elle n’est pas une machine, son travail est intellectuel et complexe, il doit avoir une vision du projet très en amont, son avis est à prendre en compte pour estimer les tâches, il a besoin d’être formé continuellement. L’artisanat c’est aussi une organisation différente de celle de l’industrie : équipes plus petites, contact client facilité, souplesse.

Le mythe de l’industrie logicielle

Il faut avant tout un encadrement favorable à cette qualité. ROLEX ne fait pas des montres d’exception parce qu’elle emploie des orfèvres mais parce qu’elle le souhaite, et que cela amène à employer des orfèvres, et à utiliser des matériaux de qualité et des outils adaptés. Malheureusement la plupart du temps, ce sont des personnes non-compétentes en développement qui vont écrire les devis et imposer ensuite à leurs développeurs de tenir les délais vendus (qui vont souvent s’avérer intenables), ne laissant aucune place à leur formation et à l’écriture d’un code bien conçu. On considère le développeur comme une ressource qu’on place dans un planning face à des « jours/hommes » et on essaie de faire tenir tout cela… Comme le rappelle Brooks dans Le Mythe du mois-homme : « Neuf femmes ne font pas un enfant en un mois ». La « motivation » est inhérente à la marge de manœuvre qu’on va laisser à une personne pour s’exprimer, on a plus de chances d’obtenir de bons résultats d’une équipe auto-organisée que de développeurs considérés comme des ouvriers, « pisseurs de code ».

Un développeur motivé comme point de départ

Si vous prenez un développeur motivé, que vous le formez, que vous lui « permettez » de faire un travail de qualité, de tester de nouvelles idées, l’impliquez dans le projet et surtout lui faites confiance, le résultat est forcément différent en mieux d’une « ressource » d’open-space mise en perpétuelle pression. Vous aurez une personne prête à s’investir pour le projet et pour le client en donnant le meilleur de soi.

Concrètement, la qualité au cœur du code

Nous l’avons dit plus haut, un code de qualité est simple (mais pas simpliste), compréhensible (« expressif ») et testé.

Un code simple

Cette notion tend à rendre le code plus léger en réutilisant au maximum les logiques du programme dans des fonctions, en faisant attention à ne pas avoir des portions trop lourdes. Plus le code est correctement compartimenté avec logique, plus il sera aisé de le comprendre à posteriori.

Un code compréhensible

Les développeurs utilisent beaucoup les commentaires pour décrire leur code. Or on se rend compte qu’avec le temps le code évolue mais pas forcément les commentaires, qui du coup ne servent plus à rien. Il est plus intéressant de faire en sorte que son code soit expressif, c’est-à-dire utiliser des noms de fonctions, variables, objets, etc… qui suffisent de façon intrinsèque à comprendre leur fonction. Les tests unitaires remplissent également à leur manière un rôle de documentation.

Un code testé

La plupart des langages permettent d’ajouter des tests unitaires : ces tests constituent un « sous-programme » qui pourra être exécuté à la demande pour vérifier que le logiciel fait bien ce qu’on veut qu’il fasse. Par exemple on peut vérifier que les règles métier n’ont pas été modifiées par une modification récente (ex : si mon email est invalide, je reçois un message d’erreur). Plus un logiciel est testé, plus son évolution sera facilitée car le développeur à la quasi-certitude de ne pas avoir créé de régression si les tests passent toujours. Alors que les tests unitaires vérifient une logique « métier », les tests fonctionnels (ou d’acceptance) vérifient les écrans affichés aux utilisateurs. La fonction « suppression » d’un produit peut par exemple très bien fonctionner, mais si le bouton n’est plus affiché il sera impossible de supprimer un produit. On simule alors des scénarios d’utilisation en vérifiant que s’affichent bien les éléments attendus. C’est un gain de temps énorme sur les gros projets ou fonctionnalités complexes (gros formulaires par exemple).
Le choix et la rédaction de ces tests est également un très bon moyen de communiquer autour du besoin réel, améliorant ainsi la compréhension entre les développeurs et le métier (client, utilisateur …).

Des développeurs qui s’entraident

Parmi les bonnes pratiques de développement, il y en a en particulier deux qui visent à produire un code de meilleure qualité, mais aussi à favoriser le transfert de compétences ou l’appropriation collective du code.

Pair programming : deux développeurs travaillent sur la même machine pour développer une fonctionnalité. Bénéficier immédiatement de la réflexion et l’expérience de deux développeurs maximise les chances d’avoir un code plus solide et durable. De plus c’est l’occasion idéale pour apprendre des petites astuces de la part d’un autre afin d’être plus efficace (raccourcis claviers, outils …)

Revues de code : chaque développeur qui le souhaite peut soumettre son code à relecture auprès de ses collègues. Cela permet de détecter très vite des erreurs, de recevoir des conseils d’optimisation ou d’échanger des techniques ou pratiques permettant de s’améliorer.

Des indicateurs

Il est possible d’extraire des indicateurs du code qui vérifient que les concepts ci-dessus ont été appliqués. Toutefois il faut garder à l’esprit que tout indicateur se trafique et qu’ils ne sont pas parole d’évangile. On trouvera notamment :

• Complexité cyclomatique : cette mesure comptabilise le nombre de « chemins » au travers d’un programme représenté sous la forme d’un graphe.
• Couverture de test : proportion du code couvert par les tests unitaires.
• Taille du code : nombre de lignes d’une méthode, d’une classe. En général si le code est trop long c’est qu’il fait trop de choses et nécessiterait d’être redécoupé afin de faciliter sa maintenance

Le nombre d’anomalies trouvées par le client pendant ou après la recette peut également être considéré comme un indicateur de qualité. Il faut cependant garder à l’esprit que l’erreur est humaine : aucun logiciel n’est exempt de bug à son lancement ! Ce qui est réellement important, c’est la rapidité de correction des bugs, tant qu’ils restent bien sur en quantité limitée.

La qualité n’est pas négociable

On ne créé pas un logiciel pour un usage limité dans le temps; il sera très souvent, voire toujours, amené à évoluer. Ainsi plus la structure de départ est propre et propice à évoluer, plus la maintenance sera facilitée et donc moins coûteuse. Il faut absolument que le client sache que son produit va évoluer et que le prix de départ peut facilement être une fraction du coût global sur quelques années. Après sa mise en production, un logiciel doit être mis à jour rapidement et avec le moins d’anomalies possibles; la qualité prend ici tout son intérêt.

Nous sommes donc là en train de justifier son intérêt : un code de qualité est écrit par des personnes motivées, mieux éduquées et plus compétentes sera plus facile donc moins cher à faire évoluer en moins de temps. Si ces pratiques sont peu connues des porteurs de projet et malheureusement de beaucoup de développeurs, elles sont très largement utilisées dans le monde Open-Source et les plus connues (et moins connues) des applications web grand public.

Conclusion

Une personne non avertie ne pourra jamais juger de la qualité d’un code logiciel, et ce n’est d’ailleurs pas un objectif pertinent pour un client. En revanche elle pourra apprécier l’effort et l’objectif du prestataire qui s’y tient. Elle aura également une certaine assurance quant aux compétences de son équipe et donc de la pertinence des choix qui sont faits pour son produit. Elle pourra ensuite s’attendre à une évolution de son produit facilitée, voire pourquoi pas une transition vers une autre équipe possible sans accroc si celle-ci possède les mêmes valeurs. S’assurer que son investissement a la capacité de tenir dans le temps est primordial.

Enfin, un prestataire qui vise la qualité peut généralement apporter d’autres atouts dans la conception du produit en terme de gestion de projet avec des méthodes plus adaptées et plus souples. Ça peut paraître présomptueux, mais c’est ainsi que nous travaillons au quotidien et c’est ce que nous espérons apporter à nos clients. Pour nous la qualité n’est pas négociable, et nous essayons de nous améliorer en ce sens (par la tenue régulière de rétrospectives par exemple). C’est une démarche qui est à la portée de tous les développeurs passionnés et nous pensons qu’il y a une clientèle émergente pour ces pratiques.