Quelles sont les métriques utiles pour le code source? [fermé]


33

Quelles sont les métriques utiles à capturer pour le code source?

Comment les métriques, comme par exemple les lignes de code (exécutable?) Ou la complexité cyclomatique peuvent-elles aider à l'assurance qualité ou en quoi sont-elles bénéfiques en général pour le processus de développement logiciel?


37
La seule mesure valide est le WTF / s. :)
terminus


Réponses:


30

"Mesurer la productivité d'un logiciel à l'aide de lignes de code revient à mesurer l'avancement d'un avion en fonction de son poids." - Bill Gates


3
S'il vous plaît ne mettez pas à jour les non-réponses.
Eric Wilson

3
Bien qu’il s’agisse d’une anecdote amusante, cette réponse ne contribue guère à la réponse à cette question.
Chris Knight

7
@Chris Cette réponse a reçu beaucoup de votes positifs (ou "mises à jour" comme FarmBoy veut l'appeler) parce que de nombreux développeurs pensent que les métriques logicielles sont inutiles. Si vous n'êtes pas d'accord ou estimez que vous avez une meilleure réponse à la question, postez votre propre réponse. Commenter comme vous l'avez fait ici n'est pas productif; vous n'avez rien apporté vous-même.
Chrisaycock

7
Mon vote par défaut et mon commentaire sont destinés à décourager les réponses qui manquent de profondeur et qui ne répondent pas directement à la question du PO. Cela pourrait être une bien meilleure réponse si vous décriviez plus en détail les raisons pour lesquelles vous estimez que les métriques de logiciel sont inutiles en termes de développement de logiciel et d'assurance qualité et que vous vous concentrez sur plus que le LOC.
Chris Knight le

Les métriques logicielles sont en réalité très utiles si vous les utilisez correctement. C'est-à-dire que plus la LdC -> plus le nombre d'insectes -> la qualité est mauvaise. Je n'ai jamais vu cela échouer en tant que mesure de la qualité. Et un avion est définitivement meilleur s'il fait le même trajet à la même vitesse mais demande beaucoup moins de poids. De toute évidence, Bill Gates ne savait pas grand chose des avions quand il avait dit ça, pas plus qu’il n’en savait assez sur les logiciels non plus.
Pablo Ariel

12

Jetez un coup d'œil aux articles de Jeff sur le sujet:

Une visite de la femme de chambre Metrics

Génie logiciel: mort?

Il y a aussi un article ancien, mais bon, de Joel, étroitement lié aux métriques logicielles, et je vous le recommande vivement: La méthode de gestion Econ 101

Le point clé, pour moi, est la suivante, citant Jeff: "Une utilisation responsable des métriques est tout aussi importante que leur collecte en premier lieu".


+1 pour citer l'unique ligne de Jeff. Une sagesse pure, endurcie au combat, juste là.
luis.espinal

11

Ce qui me déroute au sujet des métriques de code, c'est que cela ne se fait pas davantage. La plupart des entreprises font état de l'efficacité de leurs employés, de leurs fournisseurs et des systèmes en place, mais personne ne semble vouloir signaler le code. Je suis tout à fait d’accord avec les réponses qui indiquent qu’un plus grand nombre de lignes de code constitue un passif, mais que votre code est plus important.

Lignes de code: Comme je l'ai déjà mentionné, cette mesure est essentielle et doit être prise au sérieux, mais à chaque niveau. Les fonctions, les classes, les fichiers et les interfaces peuvent indiquer un code «tout faire» difficile à maintenir et coûteux à long terme. Il est extrêmement difficile de comparer le nombre total de lignes de code par rapport à ce qu'un système fait. Ce pourrait être quelque chose qui fait beaucoup de choses et dans ce cas, il y aura beaucoup de lignes de code!

Complexité: cette mesure est utile pour les bases de code sur lesquelles vous n'avez pas travaillé et peut vous donner une bonne indication des zones à problèmes. En tant qu’anecdote utile, j’ai mesuré la complexité sur l’une de mes propres bases de code, et le domaine de complexité le plus élevé était celui que je passais le plus de temps à changer. Travailler à réduire la complexité a entraîné une réduction massive du temps de maintenance. Si la direction avait ces mesures à portée de main, elle pourrait planifier des itérations de refactorisation ou des modifications de la conception de zones spécifiques d'un système.

Duplication de code: C'est une mesure très importante en ce qui me concerne. La duplication de code est un très mauvais signe et peut indiquer des problèmes graves liés à la conception d'un système ou aux développeurs qui sont en train de copier-coller, ce qui entraîne des problèmes énormes à long terme et des systèmes non maintenus.

Graphes de dépendance La recherche de dépendances mauvaises et circulaires est une mesure importante du code. Cela indique presque toujours une conception de haut niveau incorrecte nécessitant une révision. Parfois, une dépendance peut absorber une foule d’autres inutiles, car une personne utilise addNumber dans une bibliothèque de courrier électronique pour effectuer ses calculs financiers. Tout le monde est choqué lorsque la bibliothèque de courrier électronique est modifiée et que les finances sont interrompues. Si tout dépend d'une chose, cela peut également indiquer des bibliothèques complètes difficiles à maintenir et mal conçues.

Une bonne mesure vous indiquera toujours que chaque fonctionnalité d’un système a un faible encombrement. Moins de dépendances, moins de complexité, moins de duplication. Cela indique un couplage lâche et une grande cohésion.


8

Cette "métrique de code source" ne va-t-elle jamais mourir?

Les lignes de code source brutes (SLOC) sont la métrique la plus ancienne, la plus simple et la plus fondamentale.

Halstead avait initialement proposé toute une série de métriques. Beaucoup de gens ont eu beaucoup de plaisir à écrire des programmes de mesure jusqu'à ce que quelques recherches de spoils fassent l'étude évidente et démontrent que chaque mesure de Halstead est fortement corrélée avec le SLOC.

À ce stade, les métriques de Halstead ont été abandonnées, car le SLOC est toujours plus facile à mesurer.


1
Des liens vers l'étude?
Jon Hopkins

Google est votre ami, mais en voici un pour vous aider à démarrer. ecs.csun.edu/~rlingard/comp589/HoffmanArticle.pdf
John R. Strohm Le

6
Étude intéressante, bien que leur étude ne porte que sur des programmes comprenant généralement entre 50 et 100 lignes de code. Avec un si petit problème bien défini à résoudre, le résultat final ne semble pas si surprenant.
Chris Knight le

Je dirais que dans le monde réel, toutes ces études tournent à la boue.
Warren P

C'est vrai. Plus les lignes de code sont nombreuses, plus la qualité est bonne.
Pablo Ariel

8

Les métriques de code source pour l’assurance qualité visent deux objectifs:

  • écrire du code avec moins de bugs à l'intérieur
  • écriture de code pour un entretien facile

Les deux conduisent à l'écriture de code aussi simple que possible. Ça signifie:

  • unités de code courtes (fonctions, méthodes)
  • peu d'éléments dans chaque unité (arguments, variables locales, instructions, chemins)
  • et de nombreux autres critères plus ou moins complexes (voir Métrique du logiciel dans Wikipedia).

7

À ma connaissance, le nombre de bogues détectés est directement lié aux lignes de code (probablement le désabonnement), au langage modulo, au programmeur et au domaine.

Je ne connais aucune autre métrique simple et pratique bien corrélée avec les bogues.

Une chose que j'aimerais faire est de commencer à exécuter les numéros de différents projets sur lesquels je suis en cours - Couverture du test: kLOC, puis de discuter de la "qualité perçue" pour voir s’il existe une corrélation.


1
Donc, plus il y a de code, plus il y a de bugs?

3
@Thor: l yep yep. shocker, hein?
Paul Nathan

Autant que je me souvienne, les chiffres types de l’industrie représentent environ 2 à 3 erreurs par 1 000 lignes de code pour des projets moyens, mais environ 0,5 erreur pour 1 000 lignes de code pour des logiciels de contrôle de centrales nucléaires ou des projets de la NASA où ils ont consenti des efforts considérables. , contrôle, test, examen, etc., car les échecs peuvent avoir des conséquences très graves. Quelqu'un a-t-il des références à des chiffres en ce sens?
hlovdal

2
@hlovdal: 2-3 erreurs par KSLOC sont déjà un chiffre très bas. Les chiffres les plus bas que je connaisse des domaines de l'aérospatiale et de la sécurité sont de l'ordre de 0,1 erreur par KSLOC. Les chiffres typiques semblent être de 20 à 50 erreurs par KSLOC. Pour référence, Google pour le document de Andy German intitulé "Analyse de code statique de logiciel - Leçons apprises".
Schedler

1
Je conteste ces chiffres - cela dépend entièrement de la langue, du compilateur et de l'environnement exécutable. Les typos dans le code JavaScript peuvent prendre des années à trouver, mais une typo dans un langage compilé se trouve lors de la première compilation.
JBRWilkinson

7

Les métriques ne sont utiles que si vous savez quoi faire avec les réponses que vous obtenez. Essentiellement, une métrique logicielle est comme un thermomètre. Le fait de mesurer quelque chose à 98 ° C ne signifie rien jusqu'à ce que vous sachiez quelle est la température normale . La température supérieure est bonne pour la température corporelle mais vraiment mauvaise pour la crème glacée.

Les métriques courantes qui peuvent être utiles sont:

  • Bugs découverts / semaine
  • Bugs résolus / semaine
  • Nombre d'exigences définies / version
  • Nombre d'exigences mises en œuvre / libérées

Les deux premières tendances mesurées. Trouvez-vous des bogues plus rapidement que vous ne pouvez les corriger? Deux résultats possibles: peut-être avons-nous besoin de plus de ressources pour résoudre les bugs, peut-être devons-nous arrêter d'implémenter de nouvelles fonctionnalités jusqu'à ce que nous rattrapions notre retard. Les deux autres fournissent une image de la proximité de votre tâche. Les équipes agiles appellent cela un «burn down» chart.

Complexité Cyclomatique est une métrique intéressante. Au concept de base, il s'agit du nombre de chemins d'exécution uniques dans une fonction / méthode. Dans un environnement lourd de tests unitaires, cela correspond au nombre de tests nécessaires pour vérifier chaque chemin d'exécution. Néanmoins, ce n’est pas parce qu’une méthode a une complexité cyclomatique de 96 que le code est bogue - ou que vous devez écrire 96 tests pour obtenir un degré de confiance raisonnable. Il n'est pas rare que du code généré (via WPF ou des générateurs d'analyseurs syntaxiques) crée quelque chose d'aussi complexe. Cela peut donner une idée approximative du niveau d'effort requis pour déboguer une méthode.

Ligne de fond

Chaque mesure que vous prenez doit avoir la définition suivante ou elle est inutile:

  • Une compréhension de ce qu'est "normal". Cela peut être ajusté au cours de la vie du projet.
  • Un seuil en dehors de "normal" où vous devez prendre des mesures.
  • Un plan pour traiter le code lorsque le seuil est dépassé.

Les mesures que vous prenez peuvent varier considérablement d'un projet à l'autre. Vous pouvez utiliser quelques métriques sur tous les projets, mais la définition de "normal" sera différente. Par exemple, si un projet découvre en moyenne 5 bugs / semaine et que le nouveau projet découvre 10 bugs / semaine, cela ne signifie pas nécessairement que quelque chose ne va pas. L'équipe de test est peut-être plus méticuleuse cette fois-ci. De plus, la définition de «normal» peut changer au cours de la vie du projet.

La métrique est juste un thermomètre, ce que vous faites avec ça dépend de vous.


Un autre bogue lié à cela peut être utile dans certains cas est celui des bogues par lignes de code. En général, les bases de code matures devraient avoir un nombre assez faible de bogues par lignes de code, par opposition aux applications en cours de développement.
rjzii

@Rob Z, quelle que soit la métrique, les gens en feront juste assez pour l'optimiser. Au niveau des bogues par ligne de code, un développeur peut introduire une variable inutilisée qu’ils incrémentent uniquement pour augmenter le nombre de LOC sans bogues (car les compteurs SLOC peuvent détecter plusieurs points-virgules). Bien sûr, cela augmente aussi artificiellement la quantité de code à parcourir.
Berin Loritsch le

6

Le code source est un passif, pas un atout.En gardant cela à l’esprit, mesurer des lignes de code revient à suivre les dollars dépensés lors de la construction d’une maison. Cela doit être fait si vous voulez rester en-deçà du budget, mais vous ne penseriez pas nécessairement que dépenser 1 000 dollars par jour soit mieux que dépenser 50 dollars par jour; vous voudriez savoir combien de maison a été construite pour cet argent. C'est la même chose avec les lignes de code dans un projet logiciel.

En bref, il n’existe aucune métrique utile pour le code source car la mesure du code source n’est pas utile en soi.


4

Puisque le code source est simplement une combinaison de séquence, de sélection et de répétition. Si je devais décrire le logiciel le plus optimal que nous puissions raisonnablement espérer produire, ce serait comme suit. Logiciel avec une couverture de code de test de près de 100%, utilisant le moins de lignes de code nécessaires pour effectuer le travail, mais suffisamment flexible pour supporter les modifications.


2
Une couverture à 100% n'est que 100% si elle couvre tous les chemins, pas seulement toutes les lignes. Dans tout logiciel réaliste, une couverture de 100% des chemins est un mauvais objectif, car elle sera très coûteuse à atteindre et ne vous dira que que votre code se comporte comme prévu, et non pas que le design est sain. Vous pourriez avoir des failles de sécurité béantes et une couverture de 100%.
Joeri Sebrechts

+1 Plus de code source n'est pas nécessairement meilleur.
Larry Coleman

Seules les applications très simples permettent une couverture de test à 100% (rendant la couverture redondante). Il est coûteux en termes de calcul (sinon infaisable) d’atteindre une couverture de test de 100% pour les logiciels complexes. Nous connaissons ce fait de manière solide depuis environ six décennies. Deuxièmement, les tests vous indiquent uniquement que vous n’avez pas trouvé de bogue - cela ne vous garantit pas qu’il n’ya pas de bogues qui ne concernent pas la qualité structurelle, la taille ou la complexité (quelque chose également connu depuis assez longtemps.) Ne connaissant pas ces faits lorsque vous travaillez dans le logiciel, c'est comme si un physicien ne connaissait pas les lois de la thermodynamique.
luis.espinal

@ luis.espinal Un logiciel si gros qu'il est trop coûteux à tester est un logiciel incroyablement mal écrit. C'est près de ne pas avoir la moindre idée sur la façon de faire fonctionner un logiciel.
Pablo Ariel

@PabloAriel - "Un logiciel tellement gros qu'il est trop coûteux à tester" << Ce n'est pas ce que j'ai dit. Lisez le commentaire (peut-être deux ou trois fois) pour vous assurer que vous lisez réellement ce que vous pensez lire.
luis.espinal

4

Une anecdote pour montrer pourquoi les comptages KLOC sont inutiles (et même nuisibles) pour évaluer les performances.

Il y a des années, j'ai travaillé sur un grand projet (plus de 70 personnes dans notre société, plus de 30 chez notre client), qui utilisait le décompte KLOC comme seule mesure de la performance des équipes et des individus.

Pour notre effort de l'an 2000 (vous indique depuis combien de temps c'était :)), nous avons effectué un grand nettoyage de la section du code dont mon équipe était responsable. Nous avons fini par écrire environ 30 000 lignes de code, ce qui n’est pas un mauvais 3 mois de travail pour 5 personnes. Nous avons également fini par éliminer 70 000 lignes de code supplémentaires, un très bon travail pour 3 mois de travail, surtout en combinaison avec le nouveau code.

Résultat final pour le trimestre: -40 000 lignes de code. Lors de l’évaluation des performances qui a suivi le trimestre, nous avons reçu une réprimande officielle de la part de la société qui ne répondait pas à nos exigences de productivité de 20 000 lignes de code produit par trimestre (après tout, les outils avaient montré que nous avions produit -40 000 lignes de code). nous aurions tous été répertoriés comme étant sous-performants et exclus des promotions, formations, augmentations de salaire, etc., etc., si le chef de projet et l'équipe d'assurance qualité n'étaient pas intervenus et avaient fait annuler la réprimande et être remplacés par une recommandation.

Quelques mois plus tard (cela prend du temps), on nous a dit que la société revoyait ses normes de productivité et avait engagé une équipe d'experts pour créer un nouveau système basé sur une analyse par points de fonction.


Pourquoi n'avez-vous pas simplement montré les diffs?!
Reinierpost

Je pense que c'est ce qui a été fait. Mais si un système est si rigide, il ne sonne même pas l'alarme lorsqu'un point de données aussi manifestement faux apparaît, il ne fera pas grand bien.
jwenting

2
Votre réponse ne montre pas que les KLOC sont inutiles, elle montre comment ne pas les utiliser.
Neil N

2
cela montre que compter sur eux comme mesure de la productivité est une vision à court terme, mais que la seule mesure est idiote. Dans d’autres projets utilisant KLOC comme mesure de la productivité et même de la qualité, nous avons facilement gonflé les chiffres en créant des normes de codage qui ont provoqué des charges de lignes 3 lignes, etc.).
Jwenting

1
L'utilisation du SLOC comme indicateur de productivité est stupide et ne donnera probablement jamais de bons résultats. L'utilisation de SLOC comme métrique de qualité indiquant la maintenabilité et le nombre de défauts est plus rationnelle, avec toutes les mises en garde déjà évoquées sur cette question.
Redcalx

2

Je suis surpris que personne ne mentionne Déclaration / Décision Couverture des tests unitaires (pourcentage de code exercé par les tests unitaires) pour le moment.

La couverture de code est utile car vous savez quel pourcentage de l'application n'échoue pas de façon catastrophique; Le reste de son utilité dépend de la qualité des tests unitaires.


la couverture de code est une fausse mesure (bien que cela puisse avoir une certaine utilité) également. Il invite à rédiger des tests insensés pour obtenir une couverture plus élevée. Et bien sûr, il y a des choses qui ne seront jamais couvertes, et les gens vont commencer à éviter d'écrire ces choses. Par exemple, j'ai vu des outils de couverture de code qui marquaient JavaDoc en tant que code et, bien entendu, il ne serait pas couvert. un autre outil a signalé que toutes les lignes vides n'étaient pas couvertes par des tests. Vous êtes d'accord pour dire que supprimer les commentaires et les espaces dans votre code est pire que de rater des tests unitaires pour certains passeurs, j'espère?
Jwenting

Absolument, les mauvais tests unitaires font plus mal qu’ils ne l’aident à bien des égards. Par exemple, vous pouvez obtenir une couverture de code à 100% pour une suite de tests sans assert unique.
StuperUser

1

Plus les commits sont bons, mieux c'est. Il s'agit d'outils SCM, pas de code en tant que tel, mais c'est une métrique très mesurable. Plus le commit est petit, plus il est facile de voir chaque changement comme une unité atomique; plus il est facile de revenir sur des changements spécifiques et de déterminer avec précision lorsque les choses se sont cassées.

Tant qu'aucun commit n'interrompt la construction ...


1

Ce ne sont pas des métriques absolues très utiles en termes de progrès, mais elles peuvent être utilisées pour donner une idée générale de l'état du code.

Il est intéressant de noter que la complexité cyclomatique m'a été utile pour visualiser la modularité d'une base de code donnée. Vous voulez généralement une complexité faible car cela signifie que le nombre de sources par module est faible et qu'il existe de nombreux modules.


1

Je travaille souvent sur un package C ++ géant, et lorsque je cherche un code problématique qui mérite d’être remanié, la complexité Cyclomatic ou l’horrible FanIn / FanOut sont généralement de très bons drapeaux rouges à rechercher. La résolution des problèmes entraînera généralement des améliorations dans l’ensemble de la base de code.

Bien entendu, ces chiffres ne peuvent qu’indiquer ce qu’il serait intéressant de regarder. Il serait ridicule de créer un seuil difficile après lequel échouer une construction ou refuser un commit.


1

J'utilise des métriques de code dans mon travail dans de nombreuses situations:

En écrivant du code

L’utilisation la plus importante et peut-être la plus importante dans mon travail quotidien est Checkstyle , un outil destiné aux développeurs Java qui vérifie en permanence les métriques (entre autres) de mon code par rapport à un ensemble de règles que nous avons définies et marque les emplacements où mon code ne fonctionne pas. se conformer à ces règles. Au fur et à mesure que je développe du code, il me dit en temps réel si mes méthodes deviennent trop longues, complexes ou couplées, ce qui me permet de prendre du recul et de réfléchir à une refactorisation plus poussée.

Les développeurs sont totalement libres de casser toutes les règles car elles ne s'appliqueront jamais à toutes les situations. Les "règles" sont là pour stimuler la pensée et dire "Hé, est-ce la meilleure façon de faire cela?"

Pendant les revues de QA / Code

La première chose que je fais généralement lorsque j'effectue une révision de code est de vérifier la couverture de code du code que je vérifie conjointement avec un outil de couverture de code qui met en évidence les lignes de code couvertes. Cela me donne une idée générale de la profondeur du code de test. Peu m'importe que la couverture soit de 20% ou de 100% tant que le code important est bien testé. Ainsi, le pourcentage couvert ne veut rien dire, mais 0% se démarque comme un pouce endolori que je veux examiner avec soin.

Je vérifie également les métriques acceptées par l'équipe qui ont été "cassées", le cas échéant, pour voir si je suis d'accord avec le développeur pour dire que c'était OK ou si je peux suggérer des moyens de l'améliorer. Le fait de convenir de ces paramètres de développement au sein de notre équipe pour la rédaction d'un nouveau code a grandement contribué à l'amélioration de notre code. Nous écrivons beaucoup moins de méthodes monolithiques et sommes beaucoup mieux au principe de responsabilité unique maintenant.

Améliorations apportées au code hérité Nous aimerions améliorer beaucoup de code hérité. Les métriques à tout moment sont relativement inutiles, mais ce qui est important pour nous, c'est que plus la couverture de code temporel est élevée, plus la complexité et le couplage diminuent. Par conséquent, nos métriques sont connectées à notre serveur d'intégration continue, ce qui nous permet d'analyser le temps pour nous assurer que nous sommes sur la bonne voie.

Se familiariser avec une nouvelle base de code La seule fois où j'utilise des lignes de métrique de code source est lorsque je regarde une base de code que je ne connais pas bien. Cela me permet de jauger rapidement la taille approximative du projet par rapport aux autres avec lesquels j'ai travaillé. En utilisant d'autres indicateurs, je peux également avoir une idée plus précise de la qualité du projet.

Les éléments clés sont d’utiliser les métriques comme points de départ pour les tendances, les discussions ou les voies à suivre et de ne pas les gérer religieusement pour obtenir des chiffres exacts. Mais je crois fermement qu’ils peuvent vous aider à améliorer le code qui vous convient s’il est utilisé correctement.


0

Q: Quelles sont les métriques utiles à capturer pour le code source?

Pour le business:

A: nombre d'heures-homme

Pour le superviseur du codeur:

A: Peu importe. Faisons tout aujourd'hui

Pour l'estime de soi du codeur:

A: Nombre de SLOC (lignes de code source)

Pour la mère du codeur:

A: Mangez plus de ces petits pains français et buvez du thé

continué dans les commentaires ci-dessous ...


En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.