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

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?

"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

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".

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.

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.

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).

À 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.

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.

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.

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.

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.

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.

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 ...

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.

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.

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.

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 ...

N'oubliez pas: tout code peut être réduit d'au moins 1 instruction. Tout le code a au moins 1 bug. Par conséquent, tout code peut être réduit à une seule instruction qui ne fonctionne pas. J'espère que ça t'as aidé!