Comment puis-je quantifier le montant de la dette technique existant dans un projet?

67

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.

Erik Dietrich
la source
12
La dette technique provient des décisions, pas du code. Cela est dû aux mauvais choix de gestion. Il n'est pas clair que "méthode, une classe, un espace de noms, un assemblage" contiennent une dette technique en soi. Ils représentent un handicap lorsqu'il existe un meilleur choix disponible.
S.Lott
7
Je dirais (dans le contexte de la métaphore de la dette) que les gestionnaires peuvent être les détenteurs de la dette, mais que les artefacts de code représentent l'évaluation de la dette et pourraient être quantifiés. Autrement dit, je conviens que les responsables peuvent prendre une décision du type "oubliez les tests unitaires car nous n’avons pas le temps" et contractez ainsi une dette technique. Mais, je pense certainement que vous pouvez attribuer un nombre à des éléments de code individuels sous la forme d’une heuristique. Pensez-y de cette façon: si la direction prend une série de décisions horribles pour l’avenir mais qu’aucun code n’a été écrit, existe-t-il une dette à ce moment-là?
Erik Dietrich
3
"Y a-t-il une dette à ce moment-là?" La dette doit s'accumuler, vous avez raison. Mais ce n'est pas le code; c'est le volume de "travail" effectué qui doit être annulé. Spécifications, dessins, code, travail DBA, tout doit être retravaillé. Mesurer la dette à partir d'artefacts logiciels (comme les lignes de code source) est similaire à la prévision des coûts de développement.
S.Lott
7
Mesurer la dette technique est difficile, et cela brouille les gestionnaires. Cependant, je peux vous dire un bon moyen de lutter contre la dette technique: des prototypes bon marché, agréables et fonctionnels, en particulier si la base de code tourne autour de l'interface graphique. Comme Joel l'a suggéré ici: joelonsoftware.com/articles/fog0000000332.html , passez un peu de temps chaque jour à nettoyer les choses. Le changement doit être une amélioration positive, pas "OMG, notre dette technique = pentablobs et elle augmente de façon exponentielle à un rythme de ... le ciel se couche." Passez juste un peu de temps chaque jour à kaizen d’une manière qui ne casse pas les choses qui fonctionnent. Se faire des amis.
Job
6
@ZoranPavlovic Votre troisième dilemme étrange et non sollicité manque: je voulais savoir s'il existait des outils permettant de quantifier la dette technique.
Erik Dietrich

Réponses:

38

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

Thomas Owens
la source
1
J'utilise actuellement les métriques de code NDepend ( ndepend.com ), CodeRush et VS pour garder un œil sur les métriques que vous mentionnez (à l'exception des mesures de Halstead, sur lesquelles je reviendrai plus loin). Je pensais que je pourrais utiliser une fusion de ces mesures pour tenter de chiffrer un élément de code donné, ce qui indiquerait approximativement à quel point le développement en cours était coûteux.
Erik Dietrich
@ErikDietrich Vous pourrez peut-être, mais je ne voudrais probablement pas quantifier cette valeur. Peut-être qu'un rapport de type "résumé" sur ce que vos outils de mesure vous disent, en ce qui concerne les changements au fil du temps, serait plus approprié.
Thomas Owens
2
Une autre métrique simple que je voudrais ajouter à la liste est le nombre de TODO / HACK / WTF? commentaires dans une base de code ...
MaR
@Mar Cela suppose que vous les utilisez correctement et que vous ne les jouez pas à votre avantage. Vous voulez avoir plus de temps pour nettoyer la base de code, ajoutez simplement ces commentaires là où ils ne sont pas appropriés. Ne vous souciez pas de la base de code, retirez-les simplement de l'endroit où ils devraient être. Les commentaires peuvent mentir, le code ne peut pas.
Thomas Owens
1
@Thomas Owens: d'accord, mais presque toute métrique seule peut être trompée. Si utilisé correctement et honnêtement, "métrique TODO" fournit un aperçu peu coûteux du code manquant ou devant être changé (= dette invisible pour les métriques basées sur du code uniquement).
MaR
23

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 ...
Robert Greiner
la source
1
Cool merci! J'ai et utilise NDepend pour mon travail en C #, mais je fais aussi un peu de travail en Java et je suis intéressé par les métriques. À tout le moins, cela me donne des fonctionnalités pour Java et pourrait s'avérer un complément agréable à NDepend.
Erik Dietrich
Génial, nous utilisons Sonar où je travaille et il fait de très belles choses qui vous donnent un aperçu de l'état de votre base de code.
Robert Greiner
2
@ErikDietrich, FYI Sonar a également un plugin C # .
Péter Török
@ErikDietrich FYI il y a maintenant un plugin NDepend pour Sonar ndepend.com/docs/sonarqube-integration-ndepend
Patrick Smacchia - NDepend dev
Existe-t-il des alternatives open-source?
Hellboy
5

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

PatternMatching
la source
Oui, le concept de rendements marginaux décroissants est certainement quelque chose que je voudrais aborder en proposant et en affinant la métrique. Donc, non seulement "voici mon argument objectif pour la refactorisation de cette classe du point de vue des entreprises", mais aussi "voici ma raison de ne pas déranger à ce stade".
Erik Dietrich
5

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.

moucheron
la source
2
J'aime beaucoup cette réponse. Avec un service d’assurance qualité dédié, le ratio défauts de régression / nouveaux défauts est très simple à calculer et peut certainement vous en dire beaucoup sur la dette technique.
Erik Dietrich le
4

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.

Matthew Flynn
la source
Ainsi, dans le contexte des points de scénario, est-il juste de dire que vous pouvez ajouter quelques points à chaque récit s’il existe un niveau élevé de dette technique représenté par les domaines concernés du code? C'est-à-dire que si l'histoire X implique l'ajout à l'élément de code Y, ce qui est vraiment horrible, vous devez ajouter quelques points à l'histoire spécifiquement à cause de la nature de Y? Et ce nombre de points est identique ou lié au nombre de points pour effectuer le correctif que vous avez mentionné estimer?
Erik Dietrich
1
@Erik Dietrich - Eh bien, le responsable technique ajoute définitivement de la complexité à la solution. La difficulté peut être que la réparation à la pièce de TD peut être plus coûteuse qu’une solution de gros. Ainsi, il se peut que vous ayez 3 histoires qui seraient notées 5 si le DT était éliminé, mais 8 avec chacune de la dette en place, ce qui donne 9 points de TD. La tâche de réparer le DT dans son ensemble (quels que soient les récits) peut en réalité être un 8. Vous pouvez donc affirmer que la solution de gros coûte moins (8) que la solution au cas par cas (9). Cela ferait partie de la négociation
Matthew Flynn le
Ça a du sens. Et, bien sûr, ce que je cherche à faire, c’est faire un cas (assez) objectif de dire quelque chose comme "en un an, nous pouvons développer X nouvelles fonctionnalités si nous continuons à avancer, mais les nouvelles fonctionnalités X + Y si nous rembourser une partie de cette dette technique ".
Erik Dietrich
2

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

Leonhard
la source
J'ai partagé cette question sur Twitter et quelqu'un a répondu en parlant de CAST. Je ne sais pas vraiment ce que tout cela fait après avoir consulté leur site Web. Y a-t-il une version gratuite ou une version démo de ce disque à essayer, par hasard?
Erik Dietrich
2

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.

utilisateur94203
la source
1

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

Michael Brown
la source
Supposons donc que quelque chose ne se trouvant pas dans la suite de tests ou dans le paquet de données atteigne un score inférieur à 90. Avez-vous un seuil numérique où vous dites, "d'accord, cela ne suffit pas et nous allons procéder à une refactorisation"? Ou utilisez-vous ces informations pour convaincre la direction ou une partie prenante qu'une refactorisation est nécessaire? En d’autres termes, les responsables / parties prenantes se soucient-ils de l’indice de maintenabilité de Microsoft ou présentez-vous ces informations d’une autre manière? Ou bien ne le présentez-vous pas et résolvez-vous le problème vous-même?
Erik Dietrich
J'aime cette question. Ma réponse sera toujours que l’écriture du meilleur code possible n’est pas quelque chose que vous demandez la permission de faire. J'utilise ce que l'Oncle Bob appelle la "règle de boycott" (laissez toujours le code en meilleur état que lorsque vous êtes arrivé) et j'appelle le refactoring opportuniste. L'idée est que, lorsque vous devez modifier le code existant, prenez le temps de a) le couvrir dans les tests unitaires. B) le refactoriser pour qu'il soit plus propre. Michael Feathers Travailler efficacement avec Legacy Code fournit des indications à ce sujet.
Michael Brown
@ Mike-Cela vous entraînera dans de nombreux environnements de développement où un contrôle strict de tous les changements de code est suivi et surveillé. Surtout si votre amélioration apparemment innocente que personne ne vous a dit de corriger a fini par casser quelque chose qui a déjà fonctionné.
Dunk
Notez que je n'ai pas dit de plonger et bon gré mal gré de nettoyer le code. J'ai dit de nettoyer le code sur lequel vous travailliez déjà. J'ai également travaillé avec un code hautement réglementé (se voir assigner un élément de travail, fournir une liste des modifications apportées pour traiter l'élément de travail pour approbation, effectuer les modifications approuvées ). 9/10 fois expliquer le refactoring dans la demande de changement donnerait lieu à une approbation.
Michael Brown
0

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.

MathAttack
la source
2
Du point de vue de la realpolitik, je dirais que les personnes les plus disposées à subir des dommages à long terme pour obtenir des résultats à court terme sont probablement aussi les personnes les moins susceptibles de documenter leurs décisions. Donc, je suis d'accord avec votre idée en théorie, mais je pense que les "demandeurs de faveur" en série seraient les moins susceptibles de garder une trace de la balance des faveurs.
Erik Dietrich
@ErikDietrich - Je suis d'accord. Et les pires délinquants ne savent même pas qu’ils alourdissent leur dette. (Semblable aux pires contrevenants de cartes de crédit écrasant leurs cotes de crédit.) Mais le point de départ suppose le désir de quantifier, et il est difficile pour le non-auteur de le quantifier. Vous ne savez pas où se trouve le caca, à moins que ce ne soit votre chien ou qu'il vous soit arrivé de le prendre.
MathAttack
0

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.

Stefanie
la source
-1

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.

Erik Reppen
la source