Comment puis-je quantifier le montant de la dette technique qui existe dans un projet?
Est-ce que quelqu'un sait s'il existe une sorte d'outil pour mettre un nombre sur la dette technique d'une base de code, comme une sorte de métrique de code? Sinon, quelqu'un connaît-il un algorithme ou un ensemble d'heuristiques?
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 encourue par une méthode, une classe, un espace de noms, un assembly, etc.
Je suis le plus intéressé par l'analyse et l'évaluation d'une base de code C #, mais n'hésitez pas à utiliser également d'autres langues, en particulier si les concepts sont transcendants.
La dette technique n'est qu'une idée abstraite selon laquelle, quelque part dans la conception, la construction, les tests et la maintenance d'un système, certaines décisions ont été prises de sorte que le produit est devenu plus difficile à tester et à maintenir. Avoir plus de dette technique signifie qu'il sera plus difficile de continuer à développer un système - soit vous devez faire face à la dette technique et allouer de plus en plus de temps pour ce qui serait autrement des tâches simples, soit vous devez investir des ressources (temps et argent) en réduisant la dette technique en refactorisant le code, en améliorant les tests, etc.
Il existe un certain nombre de mesures qui pourraient vous donner une indication sur la qualité du code:
- Couverture de code. Il y a divers outils qui vous indiquent quel pourcentage de vos fonctions, instructions et lignes sont couvertes par les tests unitaires. Vous pouvez également mapper les tests de système et d'acceptation aux 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 qui peuvent signaler la quantité de couplage et de cohésion dans un système donné.
- 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 des valeurs de complexité cyclomatique plus élevées indiquent que quelqu'un aura plus de mal à suivre le code, mais la complexité cyclomatique indique également le nombre de cas de test requis pour atteindre la couverture.
- Les diverses mesures de complexité Halstead donnent un aperçu de la lisibilité du code. Ceux-ci comptent les opérateurs et opérandes pour déterminer le volume, la difficulté et l'effort. Souvent, cela peut indiquer à quel point il sera difficile pour quelqu'un de récupérer le code et de le comprendre, souvent dans des cas tels qu'une révision de code ou un nouveau développeur dans la base de code.
- Quantité de code en double. Le code dupliqué peut indiquer un potentiel de refactorisation des méthodes. Avoir du code en double signifie qu'il y a plus de lignes pour qu'un bug 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 tenir compte des modifications.
Souvent, outils d'analyse statique pourra vous alerter des problèmes potentiels. Bien sûr, ce n'est pas parce qu'un outil indique un problème qu'il y a un problème - il faut un jugement humain pour déterminer si quelque chose pourrait être problématique sur la route. Ces mesures vous avertissent simplement qu'il peut être temps d'examiner de plus près un système ou un module.
Cependant, ces attributs se concentrent sur le code. Ils n'indiquent pas facilement toute 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 pour l'inspection continue des qualité du code ...
- Prise en charge de plus de 25 langues: Java, C/C++, C #, PHP, Flex, Groovy, JavaScript, Python, PL/SQL, COBOL, etc.
- SonarQube est également utilisé dans Android Deveopment.
- Propose des rapports sur le code dupliqué, les normes de codage, les tests unitaires, la couverture du code, le code complexe, les bogues potentiels, les commentaires et la conception et l'architecture.
- Machine à remonter le temps et vues différentielles.
- Analyses entièrement automatisées: s'intègre à Maven, Ant, Gradle et aux outils d'intégration continue (Atlassian Bamboo, Jenkins, Hudson, etc.).
- S'intègre à l'environnement de développement Eclipse
- S'intègre à des outils externes: JIRA, Mantis, LDAP, Fortify, etc.
- Extensible avec l'utilisation de plugins.
- Implémente SQALE méthodologie pour calculer dette technique ...
Je déteste utiliser une analogie de la finance, mais cela semble vraiment approprié. Lorsque vous évaluez quelque chose (actifs de toute nature), il 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 il 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éthodologie que vous utilisez pour noter le code (+5 pour les commentaires/lisibilité, -10 pour la couverture du code, etc.)
Je ne connais certainement pas d'outils qui permettent de quantifier cela aujourd'hui et je pense que vous auriez une discussion entièrement nouvelle si vous discutez du bien-fondé de différentes stratégies d '"évaluation de la dette", mais je suis d'accord avec Matthew - la dette est le coût cumulé pour obtenir le code aussi bon que possible, en utilisant la méthode que vous utilisez pour calculer les heures-homme nécessaires pour y arriver.
Quelque chose d'autre à 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 façon exponentielle, il y a donc probablement un problème d'optimisation supplémentaire à maximiser l'utilité du travail effectué.
Entre les développeurs, une mesure assez fiable de la dette technique semble être WTF/minute .
Le problème avec cette "métrique" est qu'il est généralement assez difficile de communiquer "à l'extérieur".
La mesure qui a fonctionné pour moi dans la communication de la dette technique aux "étrangers" était la quantité d'efforts de test et de correction de bugs (en particulier pour la correction bogues de régression ) nécessaire pour une livraison réussie.
Un mot d'avertissement: bien que cette approche soit assez puissante, il vaut mieux vérifier avec de bons vieux WTFs/minute avant d'y recourir. Le fait est que c'est assez lourd: pour obtenir les données, il faut suivre attentivement le temps et les enregistrer avec précision par catégories appropriées.
- il est tellement plus facile de préciser semaines au total consacrées à la mise en œuvre de la fonctionnalité A que
J'ai passé 14 heures sur le projet d'implémentation de la fonctionnalité A, puis 29 heures sur le test de fumée, puis 11 heures sur l'implémentation de correctifs pour les régressions que j'ai découvertes, puis 18 heures sur le test d'implémentation de la fonctionnalité compatible QA. Après cela, les gars 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 à implémenter les correctifs. Après cela, j'ai passé 11 heures à tester la fumée des modifications que j'ai apportées à la libération initiale des candidats. Après cela ...
Quoi qu'il en soit, les données sur les tests et les efforts de correction de bogues ont été assez faciles à communiquer dans mon expérience.
Pour la version récente, nous avons passé environ 90% de temps à tester et à corriger les bogues de régression. Pour la prochaine version, suggérez d'allouer des efforts pour réduire cette valeur à 60-70%.
Un autre mot de prudence. Des données comme 90% ci-dessus pourraient être interprétées non seulement comme une indication de l'endettement technique, mais aussi (surprise surprise) comme l'indication d'une personne qui n'est pas très compétente en programmation/technologie particulière. "Vous faites juste trop de bugs dans votre code".
S'il y a un risque que les données soient mal interprétées de cette façon, il est utile d'avoir des données de référence supplémentaires sur quelque chose de moins WTF enclin à comparer.
- Dites s'il y a deux composants/applications similaires maintenus par le (s) même (s) développeur (s), libérant d'abord à un "taux de gaspillage" d'environ 50% et deuxièmement à 80-90, cela plaide en faveur de second = faisant l'objet d'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 ne autre réponse ,
Avec les testeurs, vous obtenez quelqu'un pour sauvegarder votre compréhension des problèmes de conception. Lorsqu'il n'y a que des développeurs qui se plaignent de qualité du code, cela ressemble souvent à WTF subjectifs de derrière la porte fermée .
Mais quand cela est repris par un gars de QA disant quelque chose commecomponent Aavait 100 bogues de régression pour 10 nouvelles fonctionnalités, par opposition àcomponent Bqui avait 10 bogues de régression pour 20 nouvelles fonctionnalités, la communication se transforme soudainement en un tout autre jeu.
Je pense que la question est de savoir combien cela coûterait de "racheter" votre dette technique - c'est-à-dire, combien de travail est-ce pour la réparer? Eh bien, c'est à l'équipe de le comprendre.
Lors de la planification du sprint, je demande à l'équipe d'estimer la complexité de la fixation des éléments de dette technique de la même manière qu'ils estimeraient la complexité d'une user story. À ce stade, c'est un jeu de négociation entre l'équipe et le propriétaire du produit pour déterminer quelle dette technique est suffisamment prioritaire pour être effectuée dans le sprint actuel (déplacer les histoires d'utilisateurs réelles) et ce qui peut attendre.
Si vous ne faites pas de mêlée, je m'en tiendrai à ma prémisse - la dette technique devrait être mesurée par le coût du remède.
Il existe une plate-forme assez puissante appelée CAST pour rechercher des dettes techniques dans les grandes applications. Nous l'avons utilisé sur un projet où nous avons repris une grande amélioration d'un système hérité. Il ne vous dit pas ce qui se passait 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. Cependant, l'utilisation réelle n'est 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 (donc je ne suis pas d'accord avec certaines des réponses ci-dessus). Il y a une dette technique qui est purement basée sur le design et qui est très subjective - comme la pornographie - vous le savez quand vous le voyez et connaissez le contexte. Je dirais que c'est vraiment une dette "technique". Il y a une dette technique qui est purement dans la mise en œuvre et je pense que cela vaut la peine d'être mesuré et suivi.
Voici un webinaire sur 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- dette-technique.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 ont une forte relation avec la densité des défauts, la productivité des développeurs et le roulement du personnel de développement.
Le travail décrit dans le webinaire s'appuie sur la recherche sur la modularité effectuée par Alan MacCormack et Carliss Baldwin à la Harvard Business School. Je regarderais aussi leurs papiers. Leur "coût de propagation" pourrait être ce que vous recherchez.
Je dirais que les mesures de code standard peuvent être utilisées comme une vue de haut niveau relative de l'endettement technique. VS Ultimate comprend un analyseur de code qui vous donnera un "indice de maintenabilité" basé sur la complexité cyclomatique, le couplage, la LoC et la profondeur d'héritage. Vous pouvez plonger dans tous les points chauds 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 étaient de 69 sur notre package de données (configuration et initialisation EF) et notre suite de tests. Tout le reste était de 90 ou plus. Il existe d'autres outils qui vous donneront plus de mesures comme celles discutées dans l'oncle Bob PPP
Je travaille pour une entreprise qui s'intéresse exactement à cela. Vous trouverez ci-dessous 3 mesures exploitables que nous vous recommandons d'examiner lorsque vous abordez la dette technique. Pour plus d'informations sur "comment" et "quand" pour les suivre, nous avons rassemblé un article récapitulatif métriques pour comprendre et gérer la dette technique .
Quelles sont vos pensées? Heureux de répondre à toutes vos questions et avide d'entendre vos commentaires :).
Propriété pour éviter les défauts et les dettes technologiques indésirables
La propriété est un indicateur avancé de la santé de l'ingénierie.
Les parties de la base de code qui reçoivent des contributions de nombreuses personnes s'accumulent au fil du temps, tandis que celles qui reçoivent 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 fournit un certain pouvoir prédictif: les parties faiblement possédées de la base de code sont susceptibles d'accumuler de la dette au fil du temps et deviennent de plus en plus difficiles à travailler. En particulier, il est probable que la dette soit contractée involontairement , simplement comme effet secondaire d'informations incomplètes et de propriété diluée de la qualité du code.
Ceci est quelque peu analogue à la tragédie des communs .
Cohésion pour améliorer l'architecture
La cohésion est un indicateur de fuite de composants bien définis.
La cohésion et son équivalent, le couplage, sont depuis longtemps reconnus comme des concepts importants sur lesquels se concentrer lors de la conception de logiciels.
On dit que le code a une cohésion élevée lorsque la plupart de ses éléments sont réunis. Une cohésion élevée est généralement préférable car elle est associée à la maintenabilité, la réutilisabilité et la robustesse. Une cohésion élevée et un couplage lâche ont tendance à aller de pair.
Au-delà d'être associée à un code plus réutilisable et maintenable, une cohésion élevée minimise également le nombre de personnes qui doivent être impliquées pour modifier une partie donnée de la base de code, ce qui augmente la productivité.
Désabonnement pour identifier les zones problématiques
Le taux de désabonnement (activité répétée) permet d'identifier et de classer les zones mûres pour une refactorisation dans un système en croissance.
À mesure que les systèmes se développent, il devient plus difficile pour les développeurs de comprendre leur architecture. Si les développeurs doivent modifier de nombreuses parties de la base de code pour proposer une nouvelle fonctionnalité, il leur sera difficile d'éviter d'introduire des effets secondaires menant à des bogues, et ils seront moins productifs car ils doivent se familiariser avec plus d'éléments et de concepts.
C'est pourquoi il est important de rechercher une responsabilité unique pour créer un système plus stable et éviter les conséquences inattendues. Bien que certains fichiers soient des pivots architecturaux et restent actifs à mesure que de nouvelles fonctionnalités sont ajoutées, c'est une bonne idée d'écrire du code de manière à clôturer les fichiers et à examiner, tester et tester le contrôle qualité de manière rigoureuse.
Churn fait surface de 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.
Je ne considérerais pas la dette technique comme un dollar où il faut un modèle sophistiqué pour le quantifier. Je pense que c'est une faveur. Si quelqu'un vous rend service et que vous risquez d'oublier, vous l'écrivez. Lorsque vous prenez un raccourci, notez-le. Cela vous aide à vous souvenir et plus impuissant vous oblige à le reconnaître. Aucun outil sophistiqué n'est nécessaire. Le bloc-notes ou Ecxel peut faire l'affaire.