Le Blog d'un Ninja codeur

Un des trolls favoris dans les discussions entre développeurs est de savoir quelles sont les meilleures pratiques à adopter pour aboutir au Saint Graal : un logiciel sans bug, bien écrit, maintenable, évolutif et respectant les délais. Évidemment, cela fait beaucoup de critères à respecter, et certains tendent à être contradictoires.

Beaucoup de brillants esprits ont écrit sur le sujet, mais étant de nature plutôt pragmatique et méfiant par rapport aux phénomènes de mode qui ont tendance par vagues à submerger l'industrie du logiciel, je suis beaucoup plus sensible aux expériences menées par des professionnels du domaine et non pas par des universitaires qui ne connaissent pas le monde de l'entreprise.

C'est pourquoi je me suis dit qu'il pouvait être est intéressant de se replonger dans un article publié il y a quelques années par une équipe de Microsoft Research, ce qui est déjà un gage de sérieux. Quoiqu'on pense de Microsoft sur le plan des pratiques commerciales, reconnaissons tout de même la qualité de ses logiciels.

L'article se base pour une large part sur les affirmations qu'on peut trouver dans le best-seller Le Mythe du mois-homme de Frederick Brooks.


Couverture des tests
Les tests sont une étapes incontournables de tout code qui se veut professionnel au point que la couverture fonctionnelle des tests est une mesure de la qualité du code produit. Un code ayant un haut taux de couverture fonctionnelle par des tests est considéré en général comme étant plus qualitatif qu'un code ayant un faible taux de couverture fonctionnelle.

A l'encontre de cette intuition, l'équipe de Microsoft Research a trouvé que pris de façon brute, ce taux de couverture fonctionnelle n'est pas un indicateur très pertinent pour mesure la qualité d'un logiciel. Même si un logiciel est couvert à 99% par des tests, il se peut que le 1% restant englobe les fonctionnalités les plus utilisées ou les plus critiques. La couverture fonctionnelle des tests n'est en effet pas une mesure de l'utilité ou de la criticité des fonctions testées.

Les auteurs relèvent également que la complexité du code doit également être prise en compte au niveau de la couverture fonctionnelle. Du code complexe est plus difficile à tester que du code peu complexe. C'est sur ce point que l'équipe de recherche affirme qu'il est plus bénéfique pour la qualité du code de tester le code complexe que du code moins complexe.


Développements dirigés par les tests
Le Test Driven Development (TDD) est un concept en vogue de nos jours, en tout cas dans les discours. Dans ce mode de développement, il conviendrait d'écrire les tests avant le code fonctionnel afin d'améliorer la qualité du code.

Ce que montre l'expérience de Microsoft Research, c'est que les TDD améliore déjà la qualité du code écrit au niveau de la "densité de bugs" de 60 à 90% (soit près du double). Ce qui en soit est assez colossal.

Cependant, ceci as un coût puisque le temps requis par ce mode de développement serait entre 15 à 35% supérieur à un mode de développement plus classique. Sur un projet d'un an, l'approche TDD rajouterait par exemple 4 mois ce qui est loin d'être négligeable.

Par conséquent, lorsque les délais sont un critère primordial sur la réussite d'un projet, le chef de projet devra évidemment réfléchir à deux fois avant d'adopter une approche TDD.


De l'utilité des assertions
Encore confidentielle, l'inclusion d'assertions au sein même du code fonctionnel (et non pas à côté comme cela peut être le cas pour les TDD), est aussi un axe pour améliorer la qualité du code.

C'est en tout cas la conviction de Tony Hoare, célèbre algorithmicien ayant remporté le prix Turing et travaillant pour Microsoft, qui n'a cessé de militer pour une utilisation systématique des assertions dans les programmes.

Il se trouve que l'équipe de Microsoft Research a effectivement constaté que la présence d'assertions était corrélée avec un nombre de bugs plus faible.


Structure de l'équipe de développement
Un aspect qui est souvent oublié dans les discussions sur les bonnes pratiques de développement concerne l'environnement du développeur et notamment l'organisation humaine.

Même si c'est un facteur sur lequel le programmeur de base n'a que peu d'emprise, il n'en reste pas moins déterminant sur la qualité du code produit.

A ce titre, la loi de Conway stipule que "s'il y a N équipes ou sous-équipes, le résultat sera un logiciel avec N versions ou N composants".

Au delà de la connotation humoristique de cet adage, l'équipe de chercheurs a montré qu'il est possible de prédire la qualité d'un logiciel (et sa tendance à produire des erreurs) à partir de son l'organisation humaine et ceci dans 85% des cas.

Autrement dit, un manager qui souhaite délivrer du bon code, doit d'abord réfléchir à son organisation humaine et à l'aspect collaboratif de son équipe.


Travail collaboratif à distance
Un des derniers axes de recherche consistait à étudier l'impact de la distance entre développeurs sur la qualité du code produit.

La tendance managériale dominante étant plutôt à la proximité entre les développeurs car cela favoriserait l'échange d'idées et la communication. D'où d'ailleurs les innombrables parodies des cubicles dans l'univers de l'informatique qu'on peut voir notamment dans la bande-dessinée Dilbert.

La mauvaise nouvelle pour ces managers prônant la proximité (mais surtout un prétexte pour un meilleur flicage, mais c'est un autre sujet), selon une étude statistique menée au sein des dizaines de milliers d'employés Microsoft et de ses innombrables projets (parfaitement localisés pour certains ou partiellement voire totalement délocalisés et distribués pour d'autres), l'équipe de chercheurs n'a pas montré de corrélations significatives entre le nombre de bugs et le fait qu'une équipe était répartie en des sites différents.


source : Exploding Software-Engineering Myths