Quelle est la fascination des métriques de code? [fermé]

StackOverflow https://stackoverflow.com/questions/195887

  •  10-07-2019
  •  | 
  •  

Question

J'ai vu un certain nombre de questions sur les "métriques de code" sur SO récemment, et je me demande quelle est la fascination? Voici quelques exemples récents:

Dans mon esprit, aucune métrique ne peut remplacer une révision de code:

  • certaines métriques peuvent parfois indiquer des lieux à revoir, et
  • des changements radicaux dans les métriques sur une courte période peuvent indiquer des lieux à revoir

Mais je ne peux pas penser à une métrique unique qui indique toujours un code "bon" ou "mauvais" - il y a toujours des exceptions et des raisons pour des choses que les mesures ne peuvent pas voir.

Y a-t-il une idée magique à tirer des métriques 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 présentés avec des bases de code héritées géantes et cherchent-ils un endroit où commencer? Que se passe-t-il?

Remarque: j'ai posé certaines de ces questions sur les thèmes spécifiques, réponses et commentaires, mais je n'ai pas reçu de réponse. J'ai donc pensé que je devrais demander à la communauté en général, car il me manque peut-être quelque chose. Ce serait bien d'exécuter un travail par lots de mesures sans avoir à lire le code des autres (ou le mien), je ne pense pas que ce soit pratique!

EDIT: Je connais la plupart des métriques en cours de discussion, si ce n’est tout, je ne vois pas l’intérêt de ces métriques isolément ou en tant que standards de qualité arbitraires.

Était-ce utile?

La solution

Les réponses à ce sujet sont plutôt bizarres car elles parlent de:

  • "l'équipe", comme "le seul et unique bénéficiaire" de ces métriques;
  • "les mesures", comme si elles ne voulaient rien dire en elles-mêmes.

1 / Les métriques ne concernent pas une population, mais pour trois :

  • développeurs: ils s'intéressent aux analyses instantanées du code statique relatives à l'analyse statique de leur code (complexité cyclomatique, qualité des commentaires, nombre de lignes, ...)
  • chefs de projet: ils s'intéressent aux quotidiens indicateurs de code actifs provenant des tests unitaires, de la couverture de code, des tests d'intégration continue
  • sponsors commerciaux (ils sont toujours oubliés, mais ce sont eux qui paient pour le développement): ils s'intéressent à l'hebdomadaire les métriques de code globales concernant la conception architecturale , sécurité, dépendances, ...

Tous ces indicateurs peuvent bien sûr être regardés et analysés par les trois populations, 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 un instantané du code, ce qui ne signifie rien du tout!

C’est la combinaison de ces paramètres et des combinaisons de ces différents niveaux d’analyse qui peut indiquer un "bon" résultat. ou "mauvais" code, mais plus important encore, c’est la tendance de ces métriques qui est significative.

C’est la répétition de ces métriques qui donnera la vraie valeur ajoutée, car elles aideront les chefs d’entreprise / chefs de projet / développeurs à hiérarchiser parmi les différents correctifs de code possibles

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

  • "beau" code (bien que cela soit toujours dans l'oeil du spectateur)
  • "bon" code (qui fonctionne et peut prouver que cela fonctionne)

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

MAIS, si:

  • la dernière fonction a une complexité constante , combinée à une couverture de code de 95%,
  • alors que le premier a une complexité croissante , combiné à une couverture de ... 0%,

on pourrait dire:

  • le dernier représente un " bon " code (ça marche, il est stable, et s’il faut changer, on peut vérifier s’il fonctionne toujours après les modifications),
  • le premier est un " mauvais " code (il faut encore ajouter des cas et des conditions pour couvrir tout ce qu’il a à faire, et il n’existe pas de moyen facile de faire un test de régression)

Donc, pour résumer:

  

une seule métrique qui indique toujours par elle-même [...]

: pas grand chose, sauf que le code peut être plus "beau", ce qui en soi ne veut pas dire grand chose ...

  

Y a-t-il une idée magique à tirer des métriques de code que j'ai négligées?

Seules la combinaison et la tendance des métriques donnent le véritable "aperçu magique". vous êtes après.

Autres conseils

Il y a un mois, j'avais un projet personnel, mesuré pour la complexité cyclomatique. Ce fut ma première exposition à ce type de métrique.

Le premier rapport que j'ai reçu était choquant. Presque toutes mes fonctions ont échoué au test, même les plus simples (à mon humble avis). J'ai contourné le problème de la complexité en déplaçant la sous-tâche logique en sous-routines, même si elles ont été appelées une seule fois.

Pour l’autre moitié des routines, ma fierté en tant que programmeur a commencé et j’ai essayé de les réécrire de manière à ce qu’ils fassent de même, tout simplement, de manière plus lisible. Cela a fonctionné et j'ai été en mesure de tirer le meilleur parti du seuil de complexité yclomatic de nos clients.

Au final, j’ai presque toujours été en mesure de proposer une meilleure solution et un code beaucoup plus propre. La performance n'en a pas souffert (croyez-moi, je suis paranoïaque à ce sujet et je vérifie assez souvent le désassemblage de la sortie du compilateur).

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

Les métriques sont des guides et des aides, pas des fins en soi.

La meilleure mesure que j’ai jamais utilisée est celle du C.R.A.P. But. http://www.artima.com/weblogs/viewpost.jsp?thread=215899

Fondamentalement, il s’agit d’un algorithme qui compare la complexité cyclomatique pondérée à la couverture de test automatisée. L'algorithme ressemble à ceci: 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) la couverture de code de test fournie par des tests automatisés.

Les auteurs de l'article mentionné ci-dessus (lisez-le, ça vaut vraiment la peine) suggèrent un maximum de C.R.A.P. score 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 de récompenses métriques n’est pas complexe, elle est assortie d’une bonne couverture de test (si vous écrivez des tests unitaires, vous devriez le faire et ne mesurez pas la couverture ... eh bien, vous apprécierez probablement de cracher dans le vent aussi). ; -)

Pour la plupart de mes équipes de développement, j’ai vraiment essayé d’obtenir le logiciel C.R.A.P. obtiennent un score inférieur à 8, mais s’ils avaient des raisons valables de justifier la complexité supplémentaire, ils étaient acceptables tant qu’ils couvraient cette complexité avec suffisamment de tests. (L'écriture de code complexe est toujours très difficile à tester ... un avantage caché pour cette métrique).

Au début, la plupart des gens avaient du mal à écrire du code qui transmettrait le code C.R.A.P. But. Mais au fil du temps, ils ont écrit un meilleur code, un code qui posait moins de problèmes et un code beaucoup plus facile à déboguer. Parmi toutes les mesures, c'est celle qui présente le moins de préoccupations et le plus grand avantage.

Une bonne révision de code ne remplace pas un bon outil d'analyse statique, qui bien sûr ne remplace pas un bon ensemble de tests unitaires. Désormais, les tests unitaires ne sont pas bons sans un ensemble de tests d'acceptation ......

Les métriques de code sont un autre outil à mettre dans votre boîte à outils. Elles ne sont pas une solution à part entière, elles ne sont qu’un outil à utiliser de manière appropriée (avec bien sûr tous les autres outils de votre boîte!).

Pour moi, la métrique la plus importante identifiant un code incorrect est la complexité cyclomatique. Presque toutes les méthodes de mes projets sont inférieures à CC 10 et les bogues se retrouvent invariablement dans les méthodes traditionnelles avec CC sur 30. Un CC élevé indique généralement:

  • code écrit à la hâte (c’est-à-dire qu’il n’avait pas le temps de trouver une solution élégante et non parce que le problème nécessitait une solution complexe)
  • code non testé (personne n'écrit des tests pour de telles bêtes)
  • code qui a été corrigé et corrigé de nombreuses fois (c'est-à-dire rempli de ifs et de commentaires à faire)
  • une cible de choix pour la refactorisation

Les gens sont attirés par l'idée de méthodes mécanistes pour comprendre et décrire le code. Si cela est vrai, pensez aux conséquences pour l'efficacité et la productivité!

Je conviens qu'une métrique de "qualité du code". est à peu près aussi raisonnable qu'une métrique pour "une bonne prose". Toutefois, cela ne signifie pas que les mesures sont inutiles, mais peut-être mal utilisées.

Par exemple, les valeurs extrêmes de certaines métriques indiquent la voie aux éventuels problèmes. Une méthode longue de 1000 lignes est probablement inaccessible. Le code sans couverture de code de test unitaire probablement a plus de bogues que le code similaire avec beaucoup de tests. Un grand saut de code ajouté à un projet juste avant la publication qui ne soit pas une bibliothèque tierce est probablement un motif d'attention supplémentaire.

Je pense que si nous utilisons les métriques comme suggestion - un drapeau rouge - elles pourraient peut-être être utiles. Le problème, c’est lorsque les gens commencent à mesurer la productivité dans le SLOC ou la qualité en pourcentage des lignes testées.

Mon opinion très subjective est que les métriques de code expriment la fascination institutionnelle irrésistible de pouvoir quantifier quelque chose par nature non quantifiable.

Cela a du sens, d’une certaine manière, au moins psychologiquement - comment pouvez-vous prendre des décisions sur quelque chose que vous ne pouvez pas évaluer ou comprendre? En fin de compte, bien sûr, vous ne pouvez évaluer la qualité que si vous maîtrisez le sujet (et êtes au moins aussi performant que ce que vous essayez d’évaluer) ou demandez à quelqu'un de compétent, ce qui ne fait bien sûr que remettre le problème en place. un pas.

En ce sens, une analogie raisonnable consisterait peut-être à évaluer les étudiants inscrits au collège en se basant sur les scores au SAT. C’est injuste et néglige toute subtilité, mais si vous devez quantifier, vous devez faire quelque chose.

Ne dis pas que je pense que c'est une bonne mesure, mais seulement que je peux voir l'irrésistabilité initiale de celle-ci. Et, comme vous l'avez fait remarquer, il existe probablement quelques mesures raisonnables (beaucoup de méthodes de 500 lignes, complexité élevée, probablement mauvaise). Je n'ai jamais été à un endroit qui a acheté dans cela, cependant.

Il y a une métrique de code en laquelle je crois.

Je travaille sur un gros système. Quand une nouvelle exigence me parvient, je commence à la coder. Quand j'ai terminé et que les bugs ont été corrigés, je les vérifie dans le système de contrôle de version. Ce système fait une différence et compte toutes les modifications que j'ai apportées.

Plus ce nombre est petit, mieux c'est.

Les mesures et les tests automatisés ne sont pas censés remplacer les critiques de code complètes.

Ils accélèrent les choses. Avec un vérificateur automatisé, il est très facile de voir quelles conventions vous avez oublié de suivre, que vous utilisez les paquetages et les méthodes désignés, etc. Vous pouvez voir ce que vous pouvez corriger sans utiliser le temps des autres.

Les gestionnaires les apprécient également parce qu'ils estiment avoir un chiffre exact sur la productivité (bien que ce ne soit souvent pas le cas) et qu'ils devraient pouvoir mieux jongler avec les gens.

Les mesures ne sont utiles que si:

  • L'équipe les a développés
  • L'équipe les a acceptés
  • Ils sont utilisés pour identifier une zone spécifique

En général, toute métrique qui ne rentre pas dans cette catégorie souffrira de l’optimisation de l’équipe. Vous voulez mesurer des lignes de code? Par Dieu, regardez combien ils peuvent écrire! Vous voulez mesurer la couverture du code, bon sang, regardez-moi couvrir ce code!

Je pense que les métriques peuvent être utiles pour identifier les tendances, et en fait, j'en ai vu quelques-unes utiles, telles que le traçage lorsque la construction est interrompue, le renversement de code (le nombre de lignes de code changeant au cours du projet), etc. Mais si l’équipe ne les présente pas ou ne les accepte pas et ne les comprend pas, vous êtes probablement dans un monde de souffrances.

Voici quelques métriques de complexité de stan4j (http://stan4j.com/).

Outil d'analyse de la structure de classe eclipse.

J'aime cet outil et les métriques. Je traite les métriques comme des statistiques, des indicateurs et des messages d’avertissement. Parfois, à cause de certaines méthodes ou de certaines classes, une logique compliquée les a rendues complexes, il faut les surveiller, examinez-les pour voir s’il est nécessaire de les reformater ou de les examiner attentivement, car ils sont généralement sujets à des erreurs. De plus, je l'utilise comme outil d'analyse pour apprendre le code source, car j'aime apprendre du plus complexe au plus simple. En réalité, il inclut d'autres mesures telles que Robert C. Martin Metrics, Chidamber & amp; Kemerer Metrics, Count Metrics Mais j'aime celui-ci le mieux

Mesures de complexité

Métriques de complexité cyclomatique

Complexité cyclomatique (CC) La complexité cyclomatique d'une méthode est le nombre de points de décision dans le graphe de flux de contrôle de la méthode incrémenté de un. Les points de décision se produisent dans les instructions if / for / while, les clauses case / catch et les éléments de code source similaires, où le flux de contrôle n'est pas simplement linéaire. Le nombre de points de décision (code en octets) introduits par une seule instruction (code source) peut varier, selon le cas. sur la complexité des expressions booléennes. Plus la valeur de complexité cyclomatique d'une méthode est élevée, plus le nombre de tests requis pour tester toutes les branches du graphe de contrôle de la méthode est important.

Complexité cyclomatique moyenne Valeur moyenne de la métrique de complexité cyclomatique sur toutes les méthodes d'une application, d'une bibliothèque, d'une arborescence de packages ou d'un package.

Métriques de graisse La métrique Fat d'un artefact est le nombre d'arêtes dans un graphique de dépendance approprié de l'artefact. Le type de graphe de dépendance dépend de la variante de métrique et de l'artefact choisi:

Fat La métrique Fat d'une application, d'une bibliothèque ou d'une arborescence de packages est le nombre d'arêtes du graphe de dépendance de sa sous-arborescence. Ce graphique contient tous les enfants de l'artefact dans la hiérarchie de l'arborescence du package, ce qui inclut également les packages feuille. (Pour voir le graphique approprié dans la vue Composition, vous devez désactiver la bascule Paquets plats de l'explorateur Structure. La bascule Afficher les bibliothèques doit être activée si l'artefact choisi est une bibliothèque, sinon il doit être désactivé.)

La métrique Fat d'un package est le nombre d'arêtes du graphe de dépendance d'unité. Ce graphique contient toutes les classes de niveau supérieur du package.

La métrique Fat d'une classe est le nombre d'arêtes de son graphe membre. Ce graphique contient tous les champs, méthodes et classes membres de la classe. (Ce graphique et la valeur Fat ne sont disponibles que si l'analyse du code a été effectuée avec un membre de niveau de détail, et non en tant que classe.)

Fat pour les dépendances de bibliothèque (Fat - Bibliothèques) La métrique Fat for Library Dependencies d'une application est le nombre d'arêtes du graphique de dépendance de bibliothèque. Ce graphique contient toutes les bibliothèques de l'application. (Pour voir le graphique approprié dans la vue Composition, vous devez activer la bascule Afficher les bibliothèques de l'Explorateur Structure.)

Fat pour les dépendances de colis plats (Fat - Paquets) La métrique Fat for Flat Package Dependencies d'une application correspond au nombre d'arêtes du graphique de dépendance de ce dernier. Ce graphique contient tous les packages de l'application. (Pour afficher le graphique approprié dans la vue Composition, vous devez activer la bascule Paquets à plat de l'Explorateur Structure et la bascule Afficher les bibliothèques.)

La métrique Fat for Flat Package Dependencies d'une bibliothèque correspond au nombre d'arêtes du graphique de dépendance de ce dernier. Ce graphique contient tous les packages de la bibliothèque. (Pour voir le graphique approprié dans la vue Composition, vous devez activer les bascules Paquets simples et Afficher les bibliothèques de l'Explorateur Structure.)

Fat pour Top Le

Les métriques peuvent être utiles pour déterminer l’amélioration ou la dégradation d’un projet, et peuvent certainement détecter des violations de style et de conventions, mais rien ne remplace l’évaluation de code par les pairs. Vous ne pouvez pas connaître la qualité de votre code sans eux.

Oh ... cela suppose qu’au moins un des participants à votre révision du code ait un indice.

Je conviens avec vous que les métriques de code ne doivent pas remplacer une révision de code, mais qu'elles devraient compléter les révisions de code. Je pense que cela revient au vieil adage selon lequel "vous ne pouvez pas améliorer ce que vous ne pouvez pas mesurer". Les métriques de code peuvent fournir à l’équipe de développement des "odeurs de code" quantifiables. ou des modèles qui peuvent nécessiter une enquête plus approfondie. Les métriques qui sont capturées dans la plupart des outils d'analyse statiques sont généralement des métriques identifiées au cours de recherches dans la courte histoire de notre domaine qui ont une signification significative.

Les métriques ne remplacent pas la révision de code, mais elles sont beaucoup moins chères. Ils sont un indicateur plus que tout.

Une partie de la réponse est que certaines métriques de code peuvent vous donner une première idée rapide de la réponse à la question: à quoi ressemble ce code?

Même des "lignes de code" peuvent vous donner une idée de la taille de la base de code que vous regardez.

Comme mentionné dans une autre réponse, la tendance des statistiques vous donne le plus d'informations.

Les métriques en elles-mêmes ne sont pas particulièrement intéressantes. C'est ce que vous faites avec eux qui compte.

Par exemple, si vous mesuriez le nombre de commentaires par ligne de code, que considéreriez-vous comme une bonne valeur? Qui sait? Ou peut-être plus important encore, chacun a sa propre opinion.

Maintenant, si vous collectez suffisamment d'informations pour pouvoir corréler le nombre de commentaires par ligne de code avec le temps nécessaire pour résoudre un bogue ou le nombre de bogues trouvés attribués au codage, vous pouvez commencer à rechercher nombre empiriquement utile.

Il n’existe aucune différence entre l’utilisation de métriques dans un logiciel et l’utilisation de toute autre mesure de performance sur tout autre processus: vous mesurez puis analysez, puis améliorez le processus. Si vous ne faites que mesurer, vous perdez votre temps.

edit: En réponse aux commentaires de Steven A. Lowe, c'est tout à fait correct. Dans toute analyse de données, il faut prendre soin de faire la distinction entre une relation de cause à effet et une simple corrélation. Et le choix des métriques sur la base de la pertinence est important. Il est inutile d'essayer de mesurer la consommation de café et d'attribuer la qualité du code (même si je suis sûr que certains ont essayé ;-))

Mais avant de pouvoir trouver la relation (causale ou non), vous devez disposer des données.

La sélection des données à collecter dépend du processus que vous souhaitez vérifier ou améliorer. Par exemple, si vous essayez d'analyser le succès de vos procédures de révision de code (en utilisant votre propre définition du mot "succès", que ce soit pour réduire le nombre de bogues ou réduire le nombre de bogues de codage, ou pour raccourcir les délais), vous devez sélectionner des métriques qui mesurer le taux total de bogues et le taux de bogues dans le code examiné.

Donc, avant de collecter les données, vous devez savoir ce que vous voulez en faire. Si la métrique est le moyen, quelle est la fin?

Je ne pense pas que de petits changements dans les métriques soient significatifs: une fonction avec une complexité 20 n'est pas nécessairement plus propre qu'une fonction avec une complexité 30. Mais cela vaut la peine d'exécuter des métriques pour rechercher de grandes différences.

Une fois, je surveillais une vingtaine de projets et l'un des projets avait une complexité maximale d'environ 6 000 points, tandis que tous les autres projets avaient une valeur d'environ 100 ou moins. Cela m'a frappé à la tête comme une batte de baseball. De toute évidence, quelque chose d'inhabituel, et probablement de mauvais, se passait avec ce projet.

Nous sommes des programmeurs. Nous aimons les chiffres.

De plus, qu'allez-vous faire, NE PAS décrire la taille de la base de code car "les lignes de métriques de code ne sont pas pertinentes"?

Il existe bel et bien une différence entre une base de code de 150 lignes et une de 150 millions, par exemple. Et ce n’est pas un chiffre difficile à obtenir.

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top