Quelle est la fascination pour les mesures de code ?

Question

J'ai vu un certain nombre de questions relatives à la métrologie du code sur SO ces derniers temps, et je me demande pourquoi il y a une telle fascination. Voici quelques exemples récents :

• Quelles sont les mesures de code qui vous convainquent que le code fourni est mauvais ?
• quand, si jamais, le nombre de lignes de code est-il une mesure utile ?
• la rédaction de tests de qualité

Selon moi, aucune mesure ne peut remplacer un examen du code :

• certaines mesures peuvent parfois indiquer des endroits qui doivent être revus, et
• Des changements radicaux dans les mesures sur de courtes périodes peuvent indiquer des endroits qui doivent être révisés.

Mais je ne peux pas imaginer une seule mesure qui, à elle seule, indiquerait toujours un "bon" ou un "mauvais" code - il y a toujours des exceptions et des raisons pour lesquelles les mesures ne sont pas visibles.

Y a-t-il des informations magiques à tirer des mesures de code que j'ai négligées ? Les programmeurs/gestionnaires paresseux cherchent-ils des excuses pour ne pas lire le code ? Les gens sont-ils confrontés à des bases de code gigantesques et cherchent-ils un point de départ ? Que se passe-t-il ?

Note : J'ai posé certaines de ces questions dans les fils de discussion spécifiques, à la fois dans les réponses et les commentaires, et je n'ai pas reçu de réponses, alors j'ai pensé que je devais poser la question à la communauté en général, car j'ai peut-être manqué quelque chose. Ce serait bien d'exécuter un travail de métrique par lots et de ne plus jamais avoir à lire le code des autres (ou le mien), mais je ne pense pas que ce soit pratique !

EDIT : Je connais la plupart, sinon la totalité, des mesures discutées, mais je ne vois pas l'intérêt de les prendre isolément ou de les considérer comme des normes de qualité arbitraires.

Answer 1

Les réponses données dans ce fil de discussion sont assez étranges :

• "l'équipe", comme "le seul et unique bénéficiaire" de ces métriques ;
• "les métriques", comme si elles avaient une signification en elles-mêmes.

1/ Metrics n'est pas pour un de la population, mais pour les trois :

• les développeurs : ils sont concernés par instantané métriques de code statique concernant l'analyse statique de leur code (complexité cyclomatique, qualité des commentaires, nombre de lignes, ...)
• les chefs de projet : ils s'occupent de quotidien métriques de code en direct provenant de test unitaire, couverture de code, test d'intégration continue
• les sponsors commerciaux (on les oublie toujours, mais ce sont les parties prenantes, celles qui paient pour le développement) : ils s'intéressent à hebdomadaire métriques globales du code concernant la conception architecturale, la sécurité, les dépendances, ...

Toutes ces mesures peuvent être observées et analysées par les trois populations, bien sûr, mais chaque type est conçu pour être mieux utilisé par chaque groupe spécifique.

2/ Les métriques, en elles-mêmes, représentent une instantané du code, et cela ne veut rien dire !

C'est la combinaison de ces mesures et de ces différents niveaux d'analyse qui peut indiquer un "bon" ou un "mauvais" code, mais plus important encore, c'est la combinaison de ces mesures et de ces différents niveaux d'analyse qui peut indiquer un "bon" ou un "mauvais" code. la tendance de ces paramètres qui est significatif.

C'est la répétition ce sont ces mesures qui apporteront la véritable valeur ajoutée, car elles aideront les chefs d'entreprise/chefs de projet/développeurs à établir des priorités parmi les différentes corrections de code possibles

---

En d'autres termes, votre question sur la "fascination des métriques" pourrait faire référence à la différence entre.. :

• un code "beau" (bien que cela soit toujours dans l'œil de l'observateur-codeur)
• un "bon" code (qui fonctionne et qui peut être prouvé)

Ainsi, par exemple, une fonction d'une complexité cyclomatique de 9 pourrait être définie comme "belle", par opposition à une longue fonction alambiquée d'une complexité cyclomatique de 42.

MAIS, si :

• cette dernière fonction a une stable complexité, combinée avec une couverture de code de 95 %,
• tandis que le premier a un en augmentation complexité, combinée avec une couverture de ... 0%,

pourrait-on dire :

• ce dernier représente un " bon "(il fonctionne, il est stable, et s'il doit être modifié, on peut vérifier s'il fonctionne toujours après les modifications),
• le premier est un " mauvais "(il faut encore ajouter quelques cas et conditions pour couvrir tout ce qu'il doit faire, et il n'y a pas de moyen facile de faire des tests de régression)

---

Donc, pour résumer :

une mesure unique qui, à elle seule, indique toujours [...]

: pas grand chose, si ce n'est que le code est peut-être plus "beau", ce qui en soi ne veut pas dire grand-chose...

Y a-t-il des informations magiques à tirer des mesures de code que j'ai négligées ?

Seule la combinaison y tendance des mesures donnent la véritable "vision magique" que vous recherchez.

Answer 2

Il y a quelques mois, j'ai réalisé un projet en solo pour mesurer la complexité cyclomatique. C'était la première fois que j'étais confronté à ce type de mesures.

Le premier rapport que j'ai reçu était choquant. Presque toutes mes fonctions ont échoué au test, même les plus simples. J'ai contourné le problème de la complexité en déplaçant les sous-tâches logiques dans des sous-routines, même si elles n'ont été appelées qu'une seule fois.

Pour l'autre moitié des routines, ma fierté de programmeur a joué et j'ai essayé de les réécrire de manière à ce qu'elles fassent la même chose, mais de manière plus simple et plus lisible. Cela a fonctionné et j'ai pu ramener la plupart d'entre elles au seuil de complexité yclomatique des clients.

Au final, j'ai presque toujours réussi à trouver une meilleure solution et un code beaucoup plus propre. Les performances n'en ont pas souffert (croyez-moi, je suis paranoïaque à ce sujet et je vérifie assez souvent le désassemblage des résultats du compilateur).

Je pense que les métriques sont une bonne chose si vous les utilisez comme une raison/motivation pour améliorer votre code. Il est cependant important de savoir quand s'arrêter et demander une subvention pour violation de métrique.

Les mesures sont des guides et des aides, et non des fins en soi.

Answer 3

La meilleure métrique que j'ai jamais utilisée est la Score C.R.A.P. .

Il s'agit en fait d'un algorithme qui compare la complexité cyclomatique pondérée à la couverture des tests automatisés. L'algorithme se présente comme suit : CRAP(m) = comp(m)^2 * (1 – cov(m)/100)^3 + comp(m) où comp(m) est la complexité cyclomatique de la méthode m, et cov(m) est la couverture du code de test fournie par les tests automatisés.

Les auteurs de l'article susmentionné (je vous invite à le lire... il en vaut la peine) suggèrent un score C.R.A.P. maximal de 30, qui se décompose de la manière suivante :

Method’s Cyclomatic Complexity        % of coverage required to be
                                      below CRAPpy threshold
------------------------------        --------------------------------
0 – 5                                   0%
10                                     42%
15                                     57%
20                                     71%
25                                     80%
30                                    100%
31+                                   No amount of testing will keep methods
                                      this complex out of CRAP territory.

Comme vous le voyez rapidement, la métrique récompense l'écriture d'un code qui n'est pas complexe couplé à une bonne couverture de test (si vous écrivez des tests unitaires, et vous devriez le faire, et que vous ne mesurez pas la couverture... eh bien, vous aimeriez probablement cracher dans le vent aussi) ;-)

Pour la plupart de mes équipes de développement, je me suis efforcé d'obtenir un score C.R.A.P. inférieur à 8, mais s'ils avaient des raisons valables de justifier la complexité supplémentaire, cela était acceptable tant qu'ils couvraient la complexité par des tests suffisants. (L'écriture d'un code complexe est toujours très difficile à tester... c'est en quelque sorte un avantage caché de cette mesure).

La plupart des gens ont eu du mal au départ à écrire un code qui passerait le test C.R.A.P.. Mais avec le temps, ils ont écrit un meilleur code, un code qui présentait moins de problèmes et un code beaucoup plus facile à déboguer. De toutes les mesures, c'est celle qui présente le moins de problèmes et le plus d'avantages.

Answer 4

Pour moi, la mesure la plus importante pour identifier un mauvais code est la complexité cyclomatique. Presque toutes les méthodes de mes projets sont inférieures à 10 CC et les bogues sont invariablement trouvés dans des méthodes héritées dont la CC est supérieure à 30. Une CC élevée indique généralement

• le code écrit à la hâte (c'est-à-dire sans avoir le temps de trouver une solution élégante et non pas parce que le problème exigeait une solution complexe)
• code non testé (personne n'écrit de tests pour de telles bêtes)
• un code qui a été patché et corrigé à de nombreuses reprises (c'est-à-dire truffé de "ifs" et de commentaires "todo")
• une cible de choix pour le remaniement

Answer 5

Un bon examen du code ne remplace pas un bon outil d'analyse statique, qui ne remplace bien sûr pas un bon ensemble de tests unitaires. Les tests unitaires ne sont pas utiles sans un ensemble de tests d'acceptation......

Les mesures du code sont un outil supplémentaire à mettre dans votre boîte à outils, elles ne sont pas une solution à part entière, elles sont juste un outil à utiliser de manière appropriée (avec bien sûr tous les autres outils de votre boîte !).