Comprendre les métriques de code

Question

J'ai récemment installé le plug-in Eclipse Metrics et exporté les données de l'un de nos projets.

C’est très bien d’avoir ces beaux graphiques, mais j’aimerais vraiment comprendre plus en profondeur ce qu’ils signifient. Les définitions des métriques ne vous disent que très loin ce que cela signifie vraiment.

Est-ce que quelqu'un connaît de bonnes ressources, livres, sites Web, etc., qui peuvent m'aider à mieux comprendre ce que toutes les données signifient et à comprendre comment améliorer le code si nécessaire?

Je suis intéressé par des éléments tels que le couplage efférent et la complexité cyclomatique, etc., plutôt que par des lignes de code ou des lignes par méthode.

Answer 1

Je ne pense pas que les métriques de code (parfois appelées métriques de logiciel ) fournissent des données précieuses en termes d’améliorations possibles.

Avec les métriques de code, il est intéressant de voir la quantité de code que vous écrivez en une heure, etc., mais au-delà, ils vous informent de la qualité du code écrit, de sa documentation et de sa couverture. C’est à peu près une tentative d’une semaine pour mesurer les domaines dans lesquels vous ne pouvez pas vraiment mesurer.

Les métriques de code distinguent également les programmeurs qui résolvent les problèmes les plus difficiles, car ils ont évidemment réussi à coder moins. Pourtant, ils ont résolu les problèmes difficiles et un programmeur junior produisant beaucoup de code de merde a bonne apparence.

Le très populaire Ohloh est un autre exemple d'utilisation de métriques. Ils utilisent des métriques pour attribuer un prix à un projet opensource (en utilisant un nombre de lignes, etc.), ce qui en soi est une tentative imparfaite - comme vous pouvez l'imaginer.

Après avoir dit que l'entrée de Wikipedia fournit une idée générale du sujet, désolée de ne pas répondre à votre question de manière plus constructive avec un site ou un livre vraiment génial, mais je parie que vous avez compris que je ne suis pas un énorme ventilateur. :)

Pour vous aider à améliorer, il vous faut une intégration continue et le respect d’une norme en matière de code, de documentation, etc. C'est comme ça que tu peux t'améliorer. Les métriques ne sont que des bonbons pour les réunions - "Regardez, nous avons déjà codé ça déjà beaucoup".

Mettre à jour

D'accord, mon point d'être un couplage efférent ou même une complexité cyclomatique peut indiquer que quelque chose ne va pas - cela ne doit pas forcément être faux. Cela peut être un indicateur de refactoriser une classe, mais il n’ya pas de règle empirique qui vous indique quand.

IMHO une règle telle que plus de 500 lignes de code, un refactor ou le DRY principal sont plus applicables dans la plupart des cas. Parfois, c'est aussi simple que cela.

Je vous ai bien dit que, puisque la complexité cyclomatique est représentée graphiquement dans un organigramme, cela peut être une révélation. Mais encore une fois, utilisez-le avec précaution.

Answer 2

À mon avis, les métriques sont un excellent moyen de trouver des difficultés dans votre base de code. Ils sont également très utiles pour montrer à votre responsable pourquoi vous devriez passer du temps à l’améliorer.

C’est un article que j’ai écrit à ce sujet: http: / /blog.jorgef.net/2011/12/metrics-in-brownfield-applications.html

J'espère que ça aide