Cet article contient des témoignages de nombreux chefs de projet détaillant les processus qu’ils utilisent afin d’avoir une faible densité de défauts selon l’analyse Coverity.
Récemment publié, le rapport Coverity Scan 2012 contient les résultats issus de l’analyse du top 118 des projets open source participants pour un nombre de lignes culminant à 68 millions, une augmentation significative comparativement aux 37 millions de lignes de code analysées lors de l’édition précédente. Coverity effectue l’analyse statique de code afin de découvrir des erreurs moyennement ou hautement graves comme la corruption de la mémoire, des variables non initialisées, la gestion des erreurs, etc. puis calcule une densité de défauts par projet ainsi qu’une densité moyenne sur tous les projets.
Pendant les cinq dernières années, la densité moyenne de défauts a fluctué entre sa valeur la plus faible 0.25 en 2009 et celle la plus élevée 0.81 atteinte en 2010. Une partie de cette fluctuation pourrait être attribuée à l’introduction, avec le temps, de nombreux algorithmes pour trouver des défauts alors “qu’en 2010 de nombreux projets ont rejoint le service d’analyse de Coverity. Cela signifie que nous avons eu un certain nombre de projets analysés pour la première fois contribuant ainsi à une augmentation significative de la densité de défauts” nous confia Zack Samocha, Directeur de Projet pour Coverity Scan.
En 2012, la densité de défauts moyenne pour les projets open source était de 0.69, une valeur considérablement plus faible que la moyenne de l’industrie qui est de 1.5, selon Samocha :
La densité de défauts moyenne basée sur une première analyse avec la technologie Coverity (avant qu’aucune défauts ne soit corrigé) est de 1.5. Après la première année du déploiement de la technologie Coverity, nous avons typiquement vu ce nombre baisser à 1.0 - même avec l’ajout constant de nouveaux codes et la détection de plus de sortes de défauts les développeurs sont capables de corriger davantage de défauts. Avec le rapport d’analyse Coverity de 2012 nous avons vu ce nombre chuter encore pour atteindre 0.69 à 0.68 pour les projets open source et le code propriétaire respectivement. Ceci indique que les développeurs améliorent constamment la qualité du code avec le test.
Le rapport contient les témoignages de nombreux chefs de projet ayant réussi à obtenir une faible densité de défauts avec leurs projets. Ils expliquent leurs processus pour améliorer la qualité du code. Même si les approches sont différentes, ils semblent tous utiliser la revue de code ou une certaine forme de tests unitaires en plus de l’analyse Coverity. Voici quelques extraits des témoignages.
AMANDA - une solution de backup pour les administrateurs IT
Base de code : 160 800 lignes de code
Densité de défaut : Zéro
Interviewés : Jean-Louis Martineau, responsable du projet et Paddy Sreenivasan, développeur
Q : Comment avez-vous pu obtenir le niveau de qualité de code le plus élevé ?
A : La première chose est d’avoir un responsable de projet qui met un processus en application. Tous les patchs et changements doivent passer par cette personne. La taille de notre projet fait qu’il peut facilement être géré par une seule personne. Tous les changements sont revus. Ils subissent de nombreux tests. Nous lançons régulièrement les tests sur les distributions afin de nous assurer qu’ils passent avant d’accepter un patch. Nous maintenons une compatibilité descendante et nous nous assurons que les pages web ainsi que la documentation sont toutes mises à jour lorsque des changements interviennent.
Nos développeurs sont habitués à ce processus qui existe depuis un certain temps déjà et ils savent s’y conformer. Cependant nous sommes flexibles sur les dates de livraison ; nous ne nous mettons pas sous pression afin de respecter une date livraison spécifique, donc cela aide.
Q : Quelles autres techniques avez-vous adoptées pour tester la qualité en dehors de Coverity ?
A : La revue de code manuelle. Nous utilisons également buildbot (un autre outil open source) pour exécuter des cas de tests génériques.
Q : Quel est le top 3 des choses vous permettant de livrer une qualité de code élevée ?
A :
- La taille de la base de code—elle est gérable, nous permettant ainsi de garder la qualité sous contrôle
- La stabilité et l’expertise des développeurs—notre responsable de projet fait ce travail depuis plus de 10 ans
- L’absence de pression par rapport à une date de livraison—nous n’avons pas à compromettre la qualité au profit d’un délai de livraison
Mesa - une implémentation d’OpenGL
Base de code : 1 038 075 lignes de code
Densité de défaut : 0.5
Interviewés : Brian Paul, initiateur de Mesa (et ingénieur chez VMware)
Q : Comment avez-vous pu obtenir un tel niveau de qualité de code ?
A : Nous sommes méticuleux avec la revue par les pairs. Tout changement apporté au code, à quelques exceptions près, est soumis à la liste de discussion pour l’examiner. Nous avons un processus de validation pour un changement de code avant même qu’il soit intégré. Nous avons 30 à 50 développeurs actifs sur le projet dont une quinzaine que je qualifierai de prolifique.
Q : Qu’arrive-t-il lorsqu’un développeur travaillant sur le projet soumet un code qui ne répond pas au niveau de qualité requis ?
A : Nous n’avons pas vraiment rencontré de cas où une personne persiste à soumettre un mauvais code. J’ai commencé le projet il y a 20 ans et continue à soumettre mon code à la revue par les autres. Les développeurs impliqués dans le projet sont fiers de leur travail. Il ne s’agit pas de jeter du code dans la nature. Ce code est utilisé par des millions de personnes et les développeurs prennent cette responsabilité très au sérieux.
Q : Quelles autres techniques avez-vous adoptées pour tester la qualité en dehors de Coverity ?
A : Nous avons, en open source, une suite de tests qui compte approximativement 10 000 tests. Nous utilisons également Valgrind pour les problèmes de mémoire et de concurrence. Puisque Mesa est multi-plateforme, nous utilisons différents compilateurs qui trouvent des bugs différents et de bas niveau. Nous utilisons Git comme système de gestion des bugs et pour le dépôt.
Network Time Protocol (NTP) - une implémentation du protocole NTP utilisée pour synchroniser les horloges des ordinateurs sur un réseau.
Base de code : 286 295 lignes de code
Densité de défaut : 0.32
Interviewé : Harlan, manager du projet
Q : Quelles autres techniques avez-vous adoptés pour tester la qualité en dehors de Coverity ?
A : Nous utilisons BitKeeper comme gestionnaire de source. En outre, les tests unitaires constituent une part de plus en plus importante de notre test de qualité. Nous faisons habituellement travailler des étudiants de Google Summer of Code sur nos suites de tests unitaires mais tous les développeurs ne peuvent pas être des ingénieurs de tests unitaires ; ainsi nous sommes limités par les compétences disponibles dans le projet. L’un de nos objectifs est d’avoir un ensemble assez robuste de ce type de tests ; ils pourraient servir d’exemples ainsi nos développeurs traditionnels pourraient inclure des tests dans leurs patchs.
Q : Quelles sont les choses les plus importantes vous permettant de livrer une qualité de code élevée ?
A : Les personnes sont l’élément le plus important du projet : avoir les compétences adéquates est clé. Les personnes travaillant sur ce projet ont des décennies d’expérience. Elles savent ce qui fonctionne.
La revue du changement : même en ayant 20 ans d’expérience, un changement que j’effectue est exécuté par 3 ou 4 personnes avant d’être ajouté au code. Elles peuvent me faire signe si elles ont des questions.
XBMC - lecteur multimédia et centre de divertissement.
Base de code : 1 201 946 lignes de code
Densité de défaut : 0.17
Interviewé : Kyle, développeur
Q : Comment avez-vous pu obtenir un tel niveau de qualité de code ?
A : Pour garder une qualité de code élevée pour la variété de plate-formes que nous supportons nous essayons d’être flexibles et testons de nombreux cas d’utilisation.
Q : Décrivez-nous la communauté des développeurs de votre projet.
A : L’équipe est petite et dispersée géographiquement. Nous avons 20 à 30 développeurs avec un noyau dur de 5 à 10 développeurs qui font des contributions régulières.
Q : Qu’arrive-t-il lorsqu’un développeur travaillant sur le projet soumet un code qui ne répond pas au niveau de qualité requis ?
A : Cela arrive régulièrement. Le code est ajouté à la branche principale et nous devons revenir là-dessus et résoudre les problèmes à travers l’outil de suivi des erreurs. C’est là que Coverity nous a été très utile. Si un développeur connaît régulièrement des problèmes de qualité il risque de voir ses pouvoirs de “merger” révoqués. Il existe un jugement fort de la communauté et les attentes de qualité sont élevées. Les développeurs qui contribuent du code de grande qualité ont un rang élevé et leur voix a du poids dans la communauté. Les développeurs ayant eu des problèmes de qualité de code dans le passé prendront typiquement plus de temps pour s’assurer de la qualité de leurs futurs commits.
Nos développeurs sont fiers de leur travail. Tous les jours ils utilisent eux-mêmes ce logiciel, ils sont donc motivés pour écrire du code de qualité. La communauté n’essaie pas seulement de cocher une case.
Q : Avez-vous des critères d’acceptation formels du code ?
A : Nous avons un processus assez souple sans métriques ou d’objectifs formels. Nous conduisons des revues manuelles et j’analyse le code avec Coverity lors de la phase d’intégration dans le trunk. J’essaie moi-même de corriger les erreurs signalées par Coverity et publie ensuite les changements pour qu’ils soient revus par les pairs. Ainsi les développeurs peuvent donc discuter de ces changements.
Q : Quelles autres techniques avez-vous adoptées pour tester la qualité en dehors de Coverity ?
A : Nous utilisons GitHub et Trac pour le suivi des bugs. Pour l’instant nous lançons les builds manuellement. Nous n’avons aucune cible pour les tests unitaires. Nous avons une très bonne qualité vu la taille de notre base de code mais nous sommes conscients de la valeur d’une gestion formelle de projet et des processus pour maintenir la qualité. Aujourd’hui nous n’avons pas d’objectifs définis de développement autres que ceux que les individus souhaitent eux-mêmes développer. Nous avons besoin de délais, d’objectifs et métriques mieux définis et formalisés.