Comment déterminer l'efficacité d'un processus de révision de code?

Nous avons introduit un processus de révision du code au sein de notre organisation et il semble bien fonctionner. Cependant, j'aimerais pouvoir mesurer l'efficacité du processus au fil du temps, c'est-à-dire que nous ne trouvons pas de bogues parce que le code est propre ou que les gens ne détectent tout simplement pas les bogues?

Actuellement, nous n'avons pas de processus de test entièrement automatisé efficace. Nous utilisons principalement des tests manuels, nous ne pouvons donc pas nous fier aux défauts détectés à ce stade pour garantir le bon fonctionnement du processus de révision du code.

Quelqu'un a-t-il déjà rencontré ce problème ou a-t-il des réflexions sur ce qui fonctionne bien pour mesurer les revues de code?

Il existe un certain nombre de métriques qui peuvent être recueillies à partir des revues de code, certaines s'étendant même tout au long du cycle de vie du projet.

La première mesure que je recommanderais de collecter est l'efficacité de la suppression des défauts (ERD) . Pour chaque défaut, vous identifiez dans quelle phase le défaut a été introduit et dans quelle phase il a été éliminé. Les différentes techniques de détection de défaut que vous utilisez sont toutes évaluées simultanément, de sorte qu'elles s'appliquent également aux revues d'exigences, revues de conception, revues de code, tests unitaires , etc. Vous seriez particulièrement intéressé par le nombre de défauts détectés dans la phase de code, car cela engloberait probablement vos tests unitaires ainsi que les révisions de code. Si de nombreux défauts de la phase de code parviennent à la phase de test d'intégration ou même sur le terrain, vous savez que vos pratiques de post-codage doivent être évaluées.

Divers paramètres de réunion seraient également pertinents. Ceux-ci incluent le temps de préparation, le temps de réunion, les lignes de code lues, les défauts trouvés dans la revue, etc. Certaines observations peuvent être faites à partir de ces données. Par exemple, si vos réviseurs passent beaucoup de temps à lire le code pour préparer la révision, mais trouvent très peu de problèmes. Couplé aux données du DRE, vous pouvez tirer la conclusion que si des défauts sont testés lors des tests d'intégration ou sur le terrain, votre équipe doit se concentrer sur ses techniques de révision pour pouvoir trouver des problèmes. Une autre note intéressante serait les lignes de code (ou une autre mesure de taille) lues dans une réunion par rapport à l'heure de la réunion. La recherche a révélé que la vitesse d'une revue de code typique est de 150 lignes de code par heure.

Avec n'importe laquelle de ces mesures, il est alors important de comprendre leur impact sur le processus. L'analyse des causes profondes, à l'aide de techniques telles que les diagrammes pourquoi-parce , Five Whys ou Ishikawa, peut être utilisée pour identifier les raisons pour lesquelles les revues de code (ou toute autre technique d'amélioration de la qualité) sont (in) efficaces.

Vous pourriez également être intéressé par cet article sur les inspections du groupe Ganssle et un article de Capers Jones dans Crosstalk sur les potentiels de défaut et le DRE .

Bien qu'il soit en grande partie vrai que la révision du code détecterait des problèmes qui sont plutôt latents que les tests peuvent ou non être détectés. Cependant, à mon avis, vous pouvez avoir un code vraiment stable (pratiquement sans bug) mais toujours écrit de telle manière qu'il est extrêmement illisible ou pas tout à fait maintenable. Il se peut donc que la révision du code ne trouve PAS de bogues s'il n'y a pas vraiment de problèmes dans le code.

Cela dit, je demanderais vraiment, pourquoi voudrait-on faire un examen du code? La raison simple pour laquelle il est important est que le code devrait être amélioré pour être rendu plus lisible, maintenable et évolutif. Beaucoup de gens devraient être capables de lire un code plus propre et d'en tirer un sens. En ce sens, l'objectif le plus simple du processus de révision de code est de produire du code propre. Donc, la mesure de l'efficacité est à quel point le code est maintenant plus propre.

Comme vous vouliez avoir une efficacité mesurable - voici ce que je suggérerais:

1. Mesure liée à la quantité de retouches - Le nombre de fois où la retouche est appliquée dans un même module / objet / élément de travail donné est une mesure de la médiocrité de ce code en termes de maintenabilité. Lorsqu'une révision de code efficace est appliquée, à quelle fréquence pouvons-nous réduire la demande de reprise de travail sur le même module?

2. Mesure liée à la quantité de changement que chaque demande de changement entraîne. À chaque fois qu'une demande de changement se produit - un code mal factorisé aura toujours un plus grand nombre de modules affectés. Une mesure indiquerait probablement qu'après un examen du code - a-t-il été une réduction de cette propagation du changement pour une demande de changement similaire dans le passé?

3. Mesure liée à la vitesse moyenne à laquelle une demande de changement peut être répondue. Lorsque le code est plus propre - plus vite et mieux c'est pour répondre aux changements requis. Une fois que le code a été nettoyé dans le processus de révision, nous constatons une accélération dans la réponse à la demande de taille similaire.

Je ne mets pas des unités de mesure exactes - vous pouvez probablement créer une mesure plus précise à ce sujet à partir de cette approche. Il peut y avoir plus de formalisme d'extension dans les approches ci-dessus à ce sujet.

Fondamentalement, mon point est qu'au lieu de regarder le nombre de bogues que le processus de révision de code identifie; nous devons mesurer l'efficacité pour déterminer si la révision du code a été en mesure de rendre le code plus propre, plus léger et plus facile à entretenir; par conséquent, nous pouvons mesurer cette efficacité si nous constatons que des demandes de changement similaires à l'avenir deviennent plus efficaces pour y répondre.