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

14

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?

Johnv2020
la source
7
La recherche de bogues n'est pas le seul objectif des revues de code. Ils sont également utiles pour renforcer les normes de codage, la formation croisée, la pollinisation croisée des idées et des technologies, etc.
Jason
Merci Jason et compris, mais dans ce cas, j'essaie de comprendre comment garantir que le processus atteint son objectif principal de prévention des défauts le plus tôt possible dans le processus de développement
@ Johnv2020 Ce n'est cependant pas son objectif principal ... Vous manquez complètement le point d'une révision de code. Ce serait comme mettre en place une nouvelle fonctionnalité de sécurité sur une flotte d'avions à réaction, puis essayer de juger de son efficacité en fonction du nombre d'accidents. Il y a trop de variables et d'autres facteurs à considérer pour affirmer avec précision que la fonction de sécurité a amélioré les chances qu'un accident ne se produise pas.
maple_shaft
@maple_shaft: faible analogie. Essayer de mesurer les taux de bogues, c'est plus comme essayer de mesurer le nombre de cercueils utilisés pour les morts des accidents.
S.Lott
1
Dans toutes les révisions de code auxquelles j'ai assisté, de nombreux bogues ont déjà été corrigés dans les tests unitaires et de niveau supérieur. Autrement dit, le code n'est pas prêt à être révisé simplement parce qu'il se compile.
Pete Wilson

Réponses:

7

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 .

Thomas Owens
la source
2

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.

Dipan Mehta
la source
1
Bien qu'il ne s'agisse pas d'un "bogue", un manque de lisibilité, de maintenabilité ou d'évolutivité est un défaut du code et doit être traité comme tel. Il n'y a aucune raison pour que ceux-ci ne puissent pas être suivis dans un outil de suivi des défauts, en même temps que les bogues de fonctionnalité réels. Ce faisant, vous ouvrez également la possibilité de suivre un certain nombre d'autres mesures liées aux défauts dans la phase de codage.
Thomas Owens
1
En tant que développeur, j'aime bien voir du code propre. Cependant, les revues de code sont très coûteuses. Donc, en tant que gestionnaire finançant un projet, un code propre n'est vraiment pas une raison impérieuse d'ajouter 5 à 10% de coûts et de temps à mon budget de développement. Surtout quand (en tant que manager) mon bonus / avis est lié à l'achèvement du projet en cours dans les délais / dans le budget. Donc, votre opinion selon laquelle la principale raison des révisions de code est d'obtenir un code propre ferait que tout bon gestionnaire dirait que le retour sur investissement n'en vaut pas la peine. Vous pouvez discuter des rendements à long terme, mais d'ici là, le gestionnaire qui livre à temps / dans les limites du budget aura été promu loin de ce problème
Dunk
...problème. Bien que le gestionnaire qui a promu les revues de code ait des projets de maintenance réussis, mais qu'il aura été alésé pour ne pas avoir terminé le projet d'origine à temps / dans le budget comme le gestionnaire qui ne l'a pas fait. OTOH, si les révisions de code ont aidé à trouver des bogues que l'absence de révision n'a pas permis et qui ont permis au gestionnaire de révision de code de terminer son projet plus à temps / dans le budget, alors c'est une autre histoire. C'est l'histoire qui doit être vendue. Ce qui signifie également qu'un code propre ne peut pas être la raison des révisions de code.
Dunk
@Dunk Le coût d'une révision de code dépend du type de révision de code. Une inspection formelle avec 3-5 lecteurs, un modérateur et la présence de l'auteur (5-7 personnes dans une salle) coûte cher. Une vérification sur place qui consiste en un autre développeur regardant le code pendant 10 à 15 minutes est également une révision du code, mais beaucoup moins formelle et beaucoup moins chère. Même la programmation par paires peut être considérée comme une technique de "révision de code". La technique appropriée est déterminée par des facteurs comprenant (mais sans s'y limiter) la criticité du code, le taux de défaut souhaité et la quantité de temps / argent à investir.
Thomas Owens
@Dunk - Je pense que vous avez avancé un argument en faveur de la décision "devrait-on réviser le code" des mains du chef de projet, et de la remettre entre les mains du responsable qui est responsable de la plate-forme logicielle à long terme. L'OMI, d'une manière générale, dépensant 5 à 10% supplémentaires pour le développement de révisions de code décentes est un investissement intéressant en termes de longévité du système en cours de développement. Mais probablement pas en termes de budget et de calendrier du projet en cours.
Dawood dit de réintégrer Monica le