Est-ce que quelqu'un sait s'il existe un outil pour attribuer un numéro à la dette technique d'une base de code, comme une sorte de métrique de code? Si non, est-ce que quelqu'un est au courant d'un algorithme ou d'un ensemble d'heuristiques pour cela?

Si aucune de ces choses n'existe jusqu'à présent, je serais intéressé par des idées sur la façon de commencer avec une telle chose. Autrement dit, comment puis-je quantifier la dette technique contractée par une méthode, une classe, un espace de noms, un assemblage, etc.

Je suis particulièrement intéressé par l'analyse et l'évaluation d'une base de code C #, mais n'hésitez pas à choisir d'autres langues, en particulier si les concepts sont transcendants.

La dette technique n’est qu’une idée abstraite selon laquelle, dans le cadre de la conception, de la construction, du test et de la maintenance d’un système, certaines décisions ont été prises de telle sorte que le produit est devenu plus difficile à tester et à maintenir. Avoir plus de dettes techniques signifie qu'il sera plus difficile de continuer à développer un système - vous devez soit gérer la dette technique et consacrer de plus en plus de temps à des tâches qui seraient autrement simples, soit vous devez investir des ressources (temps et ressources). réduction de la dette technique en refacturant le code, en améliorant les tests, etc.

Un certain nombre de métriques peuvent vous donner une indication de la qualité du code:

• Couverture de code. Il existe différents outils qui vous indiquent quel pourcentage de vos fonctions, les déclarations et les lignes sont couvertes par des tests unitaires. Vous pouvez également mapper les tests système et les tests d'acceptation sur les exigences pour déterminer le pourcentage d'exigences couvertes par un test au niveau du système. La couverture appropriée dépend de la nature de l'application.
• Couplage et cohésion . Le code qui présente un faible couplage et une forte cohésion est généralement plus facile à lire, à comprendre et à tester. Il existe des outils d’analyse de code permettant de signaler le degré de couplage et de cohésion dans un système donné.
• La complexité cyclomatique est le nombre de chemins uniques à travers une application. Il est généralement compté au niveau de la méthode / fonction. La complexité cyclomatique est liée à la compréhensibilité et à la testabilité d'un module. Non seulement les valeurs de complexité cyclomatique plus élevées indiquent que quelqu'un aura plus de difficultés à suivre le code, mais la complexité cyclomatique indique également le nombre de tests élémentaires nécessaires pour obtenir la couverture.
• Les différentes mesures de complexité de Halstead permettent de mieux comprendre la lisibilité du code. Ceux-ci comptent les opérateurs et les opérandes pour déterminer le volume, la difficulté et l'effort. Celles-ci indiquent souvent à quel point il sera difficile pour quelqu'un de saisir le code et de le comprendre, souvent dans des cas tels qu'une révision du code ou un nouveau développeur.
• Quantité de code en double. Du code en double peut indiquer un potentiel de refactorisation des méthodes. Avoir un code en double signifie qu'il y a plus de lignes pour qu'un bogue soit introduit et une probabilité plus élevée que les mêmes défauts existent à plusieurs endroits. Si la même logique métier existe à plusieurs endroits, il devient plus difficile de mettre à jour le système pour prendre en compte les modifications.

Souvent, les outils d'analyse statiques peuvent vous alerter des problèmes potentiels. Bien sûr, le simple fait qu’un outil indique un problème ne signifie pas qu’il existe un problème - il faut du jugement humain pour déterminer si quelque chose pourrait poser problème à l'avenir. Ces mesures vous avertissent simplement qu'il est peut-être temps d'examiner de plus près un système ou un module.

Cependant, ces attributs sont centrés sur le code. Ils n'indiquent pas facilement une dette technique dans l'architecture ou la conception de votre système qui pourrait être liée à divers attributs de qualité.

Sonar possède une heuristique technique de la dette ainsi que plusieurs autres fonctionnalités utiles à un projet logiciel.

Il prend également en charge un assez large éventail de langues.

SonarQube (anciennement Sonar ) est une plate-forme open source d'inspection continue de la qualité du code ...

• Supporte plus de 25 langues: Java, C / C ++, C #, PHP, Flex, Groovy, JavaScript, Python, PL / SQL, COBOL, etc.
• SonarQube est également utilisé dans le développement Android.
• Offre des rapports sur les codes dupliqués, les normes de codage, les tests unitaires, la couverture des codes, le code complexe, les éventuels bugs, les commentaires, la conception et l'architecture.
• Time machine et vues différentielles.
• Analyses entièrement automatisées: s'intègrent avec Maven, Ant, Gradle et des outils d'intégration continue (Atlassian Bamboo, Jenkins, Hudson, etc.).
• S'intègre à l'environnement de développement Eclipse
• S'intègre avec des outils externes: JIRA, Mantis, LDAP, Fortify, etc.
• Extensible avec l'utilisation de plugins.
• Implémente la méthodologie SQALE pour calculer la dette technique ...

Je déteste utiliser une analogie de la finance, mais cela semble vraiment approprié. Lorsque vous évaluez quelque chose (actifs de toutes sortes), cela peut avoir une valeur intrinsèque et extrinsèque. Dans ce cas, le code existant a une valeur intrinsèque qui serait une quantité correspondant à la qualité relative dudit code et aurait également une valeur extrinsèque (valeur de ce qui pourrait être fait au code) et ces quantités seraient additives. La valeur intrinsèque peut être décomposée en crédits et débits (bons ou mauvais) en utilisant la méthode que vous utilisez pour noter le code (+5 pour les commentaires / lisibilité, -10 pour la couverture de code, etc.).

Je ne connais certainement pas d’outil permettant de quantifier cette situation aujourd’hui et je pense que vous auriez une discussion entièrement nouvelle si vous discutiez des mérites de différentes stratégies «d’évaluation de la dette», mais je suis d’accord avec Matthew - la dette est la Le coût cumulatif pour obtenir le code aussi bon que possible, en utilisant la méthode que vous utilisez pour chiffrer les heures de travail nécessaires pour y parvenir.

Une autre chose à considérer est qu’il existe certainement une mesure de rentabilité par laquelle, à mesure que l’on se rapproche de la «perfection», la valeur d’une heure passée sur la base de code diminue très probablement de manière exponentielle, de sorte qu’il existe probablement un problème d’optimisation supplémentaire. maximiser l'utilité du travail effectué.

Entre développeurs, une mesure assez fiable de la dette technique semble être le WTF / minute .

_{Le problème avec cette "métrique" est qu’il est généralement assez difficile de communiquer "en dehors".}

La mesure qui a fonctionné pour moi dans la communication de la dette technique à des "étrangers" était la quantité de tests et d'efforts de correction de bogues (en particulier pour la correction de bogues de régression ) nécessaires à une livraison réussie.

Un mot de prudence: bien que cette approche soit assez puissante, il serait préférable de vérifier avec de bons vieux WTF / minute avant d'y avoir recours. Le problème, c'est que c'est assez compliqué: pour obtenir les données, il faut suivre soigneusement le temps et le consigner avec précision selon les catégories appropriées.

• Il est tellement plus facile d'indiquer le total des 3 semaines consacrées à la mise en œuvre de la fonctionnalité A à
   
  14 heures à la brouillon de la mise en œuvre de la fonctionnalité A, puis à 29 heures pour le test de la fumée. mise en œuvre de fonctionnalité. Après cela, les responsables de l'assurance qualité ont passé 17 heures à tester la version initiale du candidat. Après cela, j'ai passé 13 heures à analyser les bogues soumis par QA pour la version initiale du candidat et 3 heures à mettre en œuvre les correctifs. Après cela, j'ai passé 11 heures sur la fumée à tester les modifications apportées à la première version du candidat. Après ça...

Quoi qu'il en soit, les données sur les tests et les efforts de correction de bugs ont été assez faciles à communiquer selon mon expérience.

Pour la version récente, nous avons passé environ 90% du temps à tester et à corriger les bogues de régression. Pour la prochaine version, suggérez de faire des efforts pour réduire cette valeur à 60-70%.

Un autre mot de prudence. Des données telles que 90% ci-dessus pourraient être interprétées non seulement comme une indication de dette technique, mais également (surprise surprise) comme une indication indiquant que l'une d'entre elles n'est pas assez compétente en programmation / technologie particulière. "Vous faites juste trop de bugs dans votre code".

Si les données risquent d’être mal interprétées de cette façon, il est utile de disposer de données de référence supplémentaires sur des éléments moins susceptibles d’ être comparés à la WTF .

• Disons que s'il existe deux composants / applications similaires maintenus par le même développeur, en libérant d'abord environ 50% du "taux de perte" et en second lieu à 80-90, cela plaide en faveur du fait que le second est sujet à une dette technique.

S'il y a des testeurs dédiés dans le projet, ils pourraient également contribuer à une évaluation plus objective des données. Comme je l'ai mentionné dans une autre réponse ,

Avec les testeurs, vous demandez à quelqu'un de sauvegarder votre compréhension des problèmes de conception. Lorsque seuls les développeurs se plaignent de la qualité du code , cela ressemble souvent à des WTF subjectifs cachés derrière la porte fermée .
 
Mais lorsque cela a été répété par un responsable de la qualité, qui component Aavaitcomponent B quelque chose comme 100 bogues de régression pour 10 nouvelles fonctionnalités, alors que la communication comportait 10 bogues de régression pour 20 nouvelles fonctionnalités , la communication se transformait soudainement en un tout autre jeu.

Je pense que la question est de savoir combien cela coûterait-il de "racheter" votre dette technique - c’est-à-dire combien de travail cela prend-il pour la régler? Eh bien, c'est à l'équipe de le savoir.

Lors de la planification du sprint, je demande à l'équipe d'évaluer la complexité de la résolution des éléments de dette technique de la même manière que celle d'une histoire d'utilisateur. À ce stade, il est un jeu de négociation entre l’équipe et le responsable du produit afin de déterminer quelle dette technique est suffisamment prioritaire pour être exécutée dans le sprint actuel (déplacement des user stories réelles) et ce qui peut attendre.

Si vous ne faites pas de mêlée, je m'en tiens à mon principe: la dette technique doit être mesurée en fonction du coût du remède.

Il y a une plate-forme assez forte appelée CASTrechercher une dette technique dans de grandes applications. Nous l'avons utilisé pour un projet dans lequel nous avons apporté une importante amélioration à un système hérité. Cela ne vous dit pas ce qui était dans la tête des gens qui ont écrit le code, mais il examine le code et trouve les défauts de code et d'architecture, puis quantifie la dette technique si vous le souhaitez. L’utilisation réelle de ce point de vue n’est cependant pas le montant, mais la liste des problèmes déjà présents dans le code. Cela vous indique une partie de la dette technique que vous avez (je ne suis donc pas d'accord avec certaines des réponses ci-dessus). Certaines dettes techniques sont purement liées à la conception et très subjectives - comme la pornographie - vous le savez quand vous le voyez et le contexte. Je dirais si c'est vraiment une dette "technique". Il y a une dette technique qui est purement dans la mise en œuvre et je crois que

Voici un webinaire du MIT décrivant la recherche sur la dette technique dans les grands systèmes logiciels: http://sdm.mit.edu/news/news_articles/webinar_050613/sturtevant-webinar-technical-debt.html

Les auteurs ont écrit du code pour analyser un projet et extraire des métriques de «complexité architecturale». Il a été démontré que ces mesures étaient étroitement liées à la densité de défauts, à la productivité du développeur et au roulement du personnel de développement.

Le travail décrit dans le webinaire s'appuie sur la recherche sur la modularité réalisée par Alan MacCormack et Carliss Baldwin de la Harvard Business School. Je regarderais leurs papiers aussi. Leur «coût de propagation» pourrait être ce que vous recherchez.

Je dirais que les métriques de code standard peuvent être utilisées comme une vue relative de haut niveau de l'endettement technique. VS Ultimate inclut un analyseur de code qui vous fournira un "indice de maintenabilité" basé sur la complexité cyclomatique, le couplage, le niveau de contrôle et la profondeur de l'héritage. Vous pouvez plonger dans les points problématiques et voir les détails (jusqu'au niveau de la fonction). Je viens de l'exécuter sur mon projet et les scores les plus bas que nous avons obtenus sont 69 sur notre package de données (configuration et initialisation de EF) et notre suite de tests. Tout le reste était 90 ou plus. Il y a d'autres outils qui vous donneront plus de métriques comme celles discutées dans PPP d' Oncle Bob

Je ne penserais pas à la dette technique comme à des dollars nécessitant un modèle sophistiqué pour la quantifier. Je penserais à cela comme des faveurs. Si quelqu'un vous rend un service et que vous êtes susceptible d'oublier, vous l'écrivez. Lorsque vous prenez un raccourci, écrivez-le. Cela vous aide à vous souvenir et plus impuissant vous oblige à le reconnaître. Aucun outil de fantaisie n'est nécessaire. Le bloc-notes ou Ecxel peuvent faire l'affaire.

Je travaille pour une entreprise qui étudie cette question avec précision. Nous vous recommandons de prendre en compte 3 indicateurs décisionnels lorsque vous traitez une dette technique. Pour plus d'informations sur "comment" et "quand" pour les suivre, nous avons rassemblé un article récapitulatif 3 "Métriques permettant de comprendre et de traiter la dette technique" .

Quelles sont vos pensées? Heureux de répondre à vos questions et désireux d'entendre vos réactions :).

Propriété pour prévenir les défauts et la dette technique non désirée

La propriété est un indicateur avancé de la santé des ingénieurs.

Les parties de la base de code recevant des contributions de nombreuses personnes accumulent des difficultés au fil du temps, tandis que celles recevant des contributions de moins de personnes ont tendance à être dans un meilleur état. Il est plus facile de maintenir des normes élevées dans un groupe restreint, bien informé sur leur partie de la base de code.

Cela donne un certain pouvoir de prévision: les parties faiblement possédées de la base de code risquent d’accumuler des dettes au fil du temps et de devenir de plus en plus difficiles à travailler. En particulier, il est probable que la dette soit contractée par inadvertance , simplement en tant qu'effet secondaire d'informations incomplètes et d'une propriété diluée de la qualité du code.

Ceci est un peu analogue à la tragédie des biens communs .

Cohésion pour améliorer l'architecture

La cohésion est un indicateur final de composants bien définis.

La cohésion et son pendant, le couplage, sont depuis longtemps reconnus comme des concepts importants sur lesquels il faut se concentrer lors de la conception de logiciels.

On dit que le code a une grande cohésion quand la plupart de ses éléments vont ensemble. Une cohésion élevée est généralement préférable car elle est associée à la facilité de maintenance, à la réutilisabilité et à la robustesse. Une cohésion élevée et un couplage lâche ont tendance à aller de pair.

En plus d’être associée à un code plus réutilisable et maintenable, une cohésion élevée minimise également le nombre de personnes devant être impliquées pour modifier une partie donnée de la base de code, ce qui augmente la productivité.

Tournez pour identifier les problèmes

Le roulement (activité répétée) aide à identifier et à classer les zones prêtes à être restructurées dans un système en croissance.

À mesure que les systèmes se développent, les développeurs ont de plus en plus de mal à comprendre leur architecture. Si les développeurs doivent modifier de nombreuses parties de la base de code pour offrir une nouvelle fonctionnalité, il leur sera difficile d'éviter d'introduire des effets secondaires conduisant à des bogues et ils seront moins productifs, car ils doivent se familiariser avec davantage d'éléments et de concepts.

C'est pourquoi il est important de rechercher une responsabilité unique afin de créer un système plus stable et d'éviter les conséquences imprévues. Certains fichiers sont des concentrateurs architecturaux qui restent actifs au fur et à mesure de l’ajout de nouvelles fonctionnalités. Il est donc judicieux d’écrire du code de manière à fermer les fichiers et à examiner de manière rigoureuse les zones de contrôle, de test et d’assurance qualité.

Désactivez ces fichiers actifs afin que vous puissiez décider s'ils doivent être décomposés pour réduire la surface de modification dans votre base de code.

Si vous avez un bon historique via un bugtracker ou une sorte de logiciel agile, vous pouvez rester simple. Temps passé à accomplir des tâches de base. En outre, la fiabilité des estimations lorsque le projet était jeune par rapport à maintenant.