Métriques de code source pour mesurer la stabilité du code?

17

Compte tenu de la façon dont le logiciel est développé au cours d'un cycle de publication (implémentation, test, correction de bogues, publication), je pensais que l'on devrait pouvoir voir un modèle dans les lignes de code qui sont modifiées dans la base de code; par exemple vers la fin d'un projet, si le code devient plus stable, on devrait voir que moins de lignes de code sont modifiées par unité de temps.

Par exemple, on a pu voir qu'au cours des six premiers mois du projet, la moyenne était de 200 lignes de code par jour alors qu'au cours du dernier mois c'était 50 lignes de code par jour, et au cours de la dernière semaine (juste avant les DVD du produit ont été expédiés), aucune ligne de code n'a été modifiée (gel du code). Ce n'est qu'un exemple, et différents modèles pourraient émerger en fonction du processus de développement adopté par une équipe particulière.

Quoi qu'il en soit, existe-t-il des mesures de code (de la littérature à leur sujet?) Qui utilisent le nombre de lignes de code modifiées par unité de temps pour mesurer la stabilité d'une base de code? Sont-ils utiles pour se faire une idée si un projet arrive quelque part ou s'il est encore loin d'être prêt à sortir? Existe-t-il des outils qui peuvent extraire ces informations d'un système de contrôle de version et produire des statistiques?

code-metrics

— Giorgio
source

1

ndepend.com/Features.aspx#BuildComparison

— AakashM

4

"Deuxièmement, le mécanisme étant abstrait, sa production est subsumée dans sa conception. À cet égard, un programme est comme un poème: vous ne pouvez pas écrire un poème sans l'écrire. Pourtant, les gens parlent de programmation comme s'il s'agissait d'un processus de production et de mesure" productivité du programmeur "en termes de" nombre de lignes de code produites ". Ce faisant, ils enregistrent ce nombre du mauvais côté du grand livre: nous devons toujours faire référence au" nombre de lignes de code dépensées "". - Les fruits d'un malentendu , Edsger W. Dijkstra.

— yannis

3

@Yannis Rizos: Je ne suggère nullement de mesurer la productivité ou la complexité du code par LOC car je sais que ce n'est pas une bonne mesure. En revanche, si 300 lignes de code étaient modifiées deux jours avant l'expédition, en tant que manager j'aurais en tête une grosse lampe "RED ALERT" (sauf si cela était prévu et résulte d'une évaluation très attentive des risques ). En général, je suppose que le code qui a été utilisé (et testé) sans être modifié depuis longtemps est "plus stable" que le code dans lequel 100 lignes sont modifiées chaque jour.

— Giorgio

2

@Giorgio Argh, j'ai été interrompu (au milieu de la journée de travail ici) pendant que je publiais un autre commentaire (atteignez la limite de caractères dans le premier). Cela ne voulait pas dire que vous parliez de productivité, la citation de Dijkstra vient juste à l'esprit et j'ai pensé que ce serait intéressant. Dans tous les cas, les mesures de désabonnement de code sont assez proches de ce que vous recherchez, et il y a des tonnes de documentation à leur sujet. Quant aux outils, le FishEye d'Atlassian est spectaculaire.

— yannis

@Yannis Rizos: C'est en effet une lecture très intéressante. Quant à FishEye, nous l'utilisons sur notre lieu de travail (pour les révisions), donc je vais immédiatement regarder dans le manuel et voir quel genre de statistiques nous pouvons produire.

— Giorgio

17

Une mesure que Michael Feather a décrite est " L'ensemble actif de classes ".

Il mesure le nombre de classes ajoutées par rapport à celles "fermées". Le décrit la fermeture de classe comme:

Un cours est fermé à la date à laquelle aucune autre modification ne lui est apportée depuis cette date jusqu'à aujourd'hui.

Il utilise ces mesures pour créer des graphiques comme celui-ci: Graphique de classe actif

Plus l'écart est petit entre les deux lignes, mieux c'est.

Vous pourrez peut-être appliquer une mesure similaire à votre base de code. Il est probable que le nombre de classes soit en corrélation avec le nombre de lignes de code. Il peut même être possible de l'étendre pour incorporer une ligne de code par mesure de classe, ce qui pourrait changer la forme du graphique si vous avez de grandes classes monolithiques.

— Dave Hillier
source

4

Tant qu'il existe un mappage relativement cohérent des fonctionnalités vers les classes, ou d'ailleurs, le système de fichiers, vous pouvez connecter quelque chose comme gource dans votre système de contrôle de version et obtenir très rapidement une idée de l'endroit où la plupart du développement est concentré (et donc quelles parties du code sont les plus instables).

Cela suppose que vous ayez une base de code relativement ordonnée. Si la base de code est une boule de boue, vous verrez essentiellement chaque petite partie en cours de travail en raison des interdépendances. Cela dit, peut-être que cela en soi (le clustering tout en travaillant sur une fonctionnalité) est une bonne indication de la qualité de la base de code.

Cela suppose également que votre entreprise et votre équipe de développement dans son ensemble aient un moyen de séparer les fonctionnalités dans le développement (que ce soit des branches dans le contrôle de version, une fonctionnalité à la fois, peu importe). Si, par exemple, vous travaillez sur 3 fonctionnalités principales sur la même branche, cette méthode produit des résultats sans signification, car vous avez un problème plus important que la stabilité du code entre vos mains.

Malheureusement, je n'ai pas de littérature pour prouver mon point. Il est uniquement basé sur mon expérience d'utilisation de gource sur de bonnes (et pas si bonnes) bases de code.

Si vous utilisez git ou svn et que votre version de gource est> = 0,39, c'est aussi simple que d'exécuter gource dans le dossier du projet.

— Carl
source

gource semble également être un excellent outil! (+1)

— Giorgio

1

Je suis tombé sur cette réponse, puis j'ai passé les six heures suivantes à jouer avec Gource. Je ne sais pas si cela mérite un +1 ou un -1, mais bon sang, c'est un outil sympa.

— RonU

@RonU: Vous pouvez utiliser gource pour visualiser l'état du référentiel dans une plage de temps personnalisée. Le fait est qu'il visualise l'activité sur votre base de code au fil du temps. La facilité d'interprétation des informations dépend de nombreux facteurs, comme je l'ai expliqué dans ma réponse ci-dessus. Oui, c'est un outil incroyable si vous voulez avoir une "vue d'ensemble", donc je pense que cela mérite un +1;)

— Carl

Oui, quand j'ai dit "six heures", je ne voulais pas dire que j'ai exécuté une simulation Gource pendant ce temps ... juste que j'ai joué avec beaucoup d'options, que je l'ai redirigé vers ffmpeg, éventuellement ajouté une bande-son épique, etc. était tout à fait le trou du lapin. :)

— RonU

Laisse-moi deviner. La bande originale était le Harlem Shuffle en boucle;)

— Carl

0

L'utilisation de la fréquence des lignes modifiées comme indicateur de la stabilité du code est au moins discutable.

Dans un premier temps, la répartition dans le temps des lignes modifiées, dépend fortement du modèle de gestion logicielle du projet. Il existe de grandes différences dans les différents modèles de gestion.

En second lieu, la victime dans cette hypothèse n'est pas claire - est le nombre inférieur de lignes modifiées provoqué par la stabilité du logiciel, ou simplement parce que le délai expire et que les développeurs ont décidé de ne pas apporter de changements maintenant, mais de le faire après la Libération?

Au troisième, la plupart des lignes sont modifiées lorsque de nouvelles fonctionnalités sont introduites. Mais la nouvelle fonctionnalité ne rend pas le code instable. Cela dépend de la compétence du développeur et de la qualité de la conception. D'un autre côté, même des bugs graves peuvent être corrigés avec très peu de lignes modifiées - dans ce cas, la stabilité du logiciel est considérablement augmentée, mais le nombre de lignes modifiées n'est pas trop important.

— johnfound
source

"Cela dépend des compétences du développeur et de la qualité de la conception.": Mais vous avez besoin d'au moins un certain temps pour tester les modifications afin d'avoir suffisamment de confiance pour n'avoir introduit aucun bogue. Même les développeurs les plus qualifiés peuvent faire des fautes de frappe, par exemple s'ils sont sous pression, ont fait trop d'heures supplémentaires ou ont trop peu dormi. De plus, si vous appliquez le principe ouvert / fermé, après un certain temps, le nombre de changements (corrections de bugs) devrait diminuer. Quoi qu'il en soit, j'ai explicitement déclaré dans ma question que le résultat d'une telle mesure peut changer en fonction du processus de développement.

— Giorgio

BTW, le code peut être instable non pas parce que les développeurs sont mauvais, mais parce que les exigences ne sont pas claires et que le projet est encore en phase de prototypage.

— Giorgio

@Giorgio: Bien sûr, vous avez raison. Mais c'est exactement ce que j'ai écrit: le nombre de lignes modifiées dépend fortement de trop de facteurs. Certains d'entre eux concernaient la stabilité du code, d'autres non. C'est comme essayer de calculer combien de personnes ont des relations sexuelles, en mesurant la puissance électrique, par hypothèse - moins de puissance - moins de lumières - plus de sexe. Bien qu'il soit prouvé que le taux de natalité augmente après de grandes coupures de courant. ;)

— johnfound le

-1

La robustesse est un terme qui se rapporte à la fonction correcte d'un ensemble d'instructions, et non à la quantité, à la verbosité, à la justesse, à l'exactitude grammaticale du texte utilisé pour exprimer ces instructions.

En effet, la syntaxe est importante et doit être correcte, mais tout ce qui va au-delà, car elle se rapporte à la fonction souhaitée des instructions en regardant les `` métriques '' des instructions s'apparente à tracer votre avenir en lisant le motif des feuilles de thé au bas de vous tasse de thé.

La robustesse est mesurée au moyen de tests. Tests unitaires, tests de fumée, tests de régression automatisés; tests, tests, tests!

Ma réponse à votre question est que vous utilisez la mauvaise approche pour chercher une réponse à la robustesse. C'est un hareng rouge que les lignes de code signifient autre chose que des lignes occupant du code. Vous ne pouvez savoir si le code fait ce que vous voulez qu'il fasse que si vous testez qu'il fait ce que vous en avez besoin.

Veuillez revoir les harnais de test appropriés et éviter le mystisisme de métrique de code.

Meilleurs vœux.

— Sassafras_wot
source

3

J'ai explicitement déclaré que je ne proposais pas la LoC comme mesure de la complexité du code. Je proposais les changements de code comme mesure de la stabilité du code: un morceau de code a-t-il des exigences fonctionnelles stables et une implémentation stable et testée remplissant ces exigences?

— Giorgio

Je ne veux pas discuter avec vous, mais vous guider respectueusement loin de la folie du vide de sens métrique du code. Je vous ai relu votre question et vos exemples indiquent tous un désir d'inférer une relation entre les lignes de code qui sont modifiées et la robustesse qui en résulte. Je comprends que plus vous tapez de mots, plus vous avez de chances de faire une faute de frappe. Mais je suis tellement contre le principe de ce que vous demandez, que je dois vous prononcer fermement en faveur de l'abandon de votre quête de cette manière. Bonnes pratiques de test = bonne probabilité de robustesse.

— Sassafras_wot

"Bonnes pratiques de test = bonnes chances de robustesse.": Je suis totalement d'accord. C'est pourquoi je suggère qu'un morceau de code qui a été modifié récemment doit être testé à nouveau avant de pouvoir être sûr qu'il est correct.

— Giorgio

Il existe plusieurs définitions de la stabilité et l'une d'elles est ce que vous plaidez. C'est une interprétation sémantique différente de celle que j'ai faite. J'ai pris stable pour signifier qu'il n'est "pas soumis à des changements extrêmes" plutôt que "résistant au changement"

— Dave Hillier