Calcul de la dette technologique : Vs basé sur la vélocité. Vs basés sur les problèmes. Mesures basées sur la qualité expliquées

Les taux d'intérêt ont augmenté de 157 % !

Non, je ne parle pas de la dernière décision de la Fed mais du ralentissement auquel Fictional Inc. a été confronté après la sortie de la version 3.0 de sa plateforme.

Heureusement pour eux, la sortie du produit a été un succès incroyable, et ils commencent à voir la croissance des revenus augmenter rapidement, mais ils doivent maintenant réfléchir à la façon dont ils vont gérer leur dette technique qu'ils ont introduite dans le cadre de la sortie.

La nouvelle dette technologique introduite dans le cadre d'une nouvelle version peut être considérée comme une augmentation du taux d'intérêt et une augmentation du ralentissement auquel l'équipe sera confrontée à l'avenir.

(Je vais supposer que vous êtes assez familier avec le concept de dette technique ici, mais si vous avez besoin d'un rappel pour vous mettre au courant, voici un rapide apprêt )

Ok, vous n'allez probablement pas entendre un responsable de l'ingénierie parler ainsi de sa dette technique.

Mais pourquoi pas?

Pouvoir mesurer et quantifier l'impact continu de votre la dette technologique est critique si vous souhaitez élaborer un plan d'action pour y remédier.

Lorsque nous pensons à la dette technique, l' intérêt est le temps perdu sur le développement actuel et futur de vos niveaux actuels de dette technique.

Cela signifie que c'est l'élément critique de la dette à prendre en compte lors de la réflexion sur les décisions futures de rembourser le principal (le coût de la réécriture, de la refactorisation ou de la correction du code responsable de la dette) - puisque nous ne le considérerons jamais que si l'intérêt est suffisamment élevé.

Qu'est-ce qu'un niveau sain de dette technique ?

La dette technique ralentit clairement les nouveaux développements - mais cela ne signifie pas en soi que nous devrions réparer la dette technologique partout. Revenir à la réécriture ou à la refactorisation du code existant peut être très coûteux - nous ne voulons donc rembourser le principal de notre dette technique que si notre intérêt (le montant qui nous ralentit à l'avenir) dépasse notre principal.

Un problème évident surgit immédiatement - le principal est une unité de temps fixe (heures à réparer/réécrire) mais l'intérêt est un taux d'heures perdues par temps. Pour tenir compte de cela, nous devons introduire l'idée d'un intervalle d'impact - le temps pendant lequel nous nous soucions de savoir si les futurs ralentissements de la dette technique dépassent le coût de la réécriture. L'intervalle d'impact qui vous intéresse dépendra fortement de votre entreprise, de votre processus de planification typique et de son stade ou du cycle de vie de votre base de code - mais personnellement, je regarderai généralement un intervalle d'impact de 3 mois. À nos débuts en tant qu'entreprise, regarder quoi que ce soit sur des échelles de temps d'un an et plus est trop large, mais tout ce qui est inférieur à 2 à 3 mois sous-estimera fortement l'impact de la dette technique, comme nous le verrons plus tard.

Cela signifie que notre niveau de dette technologique ne vaut pas la peine d'être pris en compte si :

Par exemple : si nous avions un petit projet dont nous savions qu'il avait une dette technologique qui nous ralentissait de 2 heures/semaine, il nous faudrait 4 jours pour refactoriser cette dette et nous soucier d'un intervalle d'impact de 3 mois, alors nous ne le ferions pas. passer le temps de rembourser cette dette encore.

Maintenant, cela ne répond pas réellement au niveau de ce qui est un niveau sain de dette technique - parce que je pense que nous pouvons tous convenir que faire face à d'énormes ralentissements de l'équipe n'est pas sain. Au lieu de cela, nous avons maintenant un moyen rapide de déterminer quand nous devrions ou non nous concentrer sur la réécriture et la refactorisation. Nous verrons ce qu'est réellement un niveau d'endettement sain un peu plus loin dans l'article.

Comment mesure-t-on la dette technique ?

Pour déterminer le taux d'intérêt de notre dette technologique, nous devons déterminer à quel point nous sommes ralentis par les différentes décisions que nous avons prises. Malheureusement, il n'y a pas de moyen évident ou trivial de suivre à quel point votre développement est ralenti - mais il existe trois approches différentes que vous pouvez adopter pour obtenir de bonnes approximations.

Mesure basée sur la vitesse

Le moyen le plus direct de lier les ralentissements à différentes sections de notre base de code est de regarder comment la vélocité varie dans le temps, à travers différentes sections de votre projet. En regardant dans différentes zones de la base de code, vous pouvez commencer à identifier les variations (par exemple, tout développement touchant cette section d'analyse prend 3 fois plus de temps que toute autre chose) dans les différentes sections. L'examen de la variation d'une zone au fil du temps peut également vous donner une indication de l'impact du nouveau développement sur le taux de développement futur et donne une indication du niveau d'intérêt auquel votre équipe est confrontée.

Par exemple : si nous avons un projet relativement simple avec 4 domaines différents sur lesquels nous allons travailler, nous pouvons examiner l'évolution de la vélocité au fil du temps (ici, nous suivons la vélocité en points d'histoire/mois de développeur).

Mesure basée sur la vélocité de l'impact de la dette technique

À partir de là, nous pouvons voir que D a toujours mis environ 3 fois plus de temps à travailler que n'importe lequel des autres domaines pour des tâches tout aussi complexes. Cela implique qu'il a 3 fois plus d'intérêt que toutes les autres sections de la base de code. Auparavant, B était relativement à égalité avec A et C, mais à partir du mois 4, il a tout d'un coup pris 2 fois plus de temps. Cela suggère que nous avons introduit une dette ici qui a doublé notre taux d'intérêt par rapport à ce qu'il était auparavant pour B.

Une chose à souligner est que nous ne parlons pas du taux d'intérêt pour l'ensemble de la base de code, mais plutôt du taux d'intérêt pour les composants/zones individuels - c'est parce que les ralentissements introduits par l'accumulation de la dette technique ne sont généralement pas des problèmes qui affectent tout ce que nous faisons, au lieu de cela, ils sont localisés dans une partie de la base de code.

Il y a quelques mises en garde importantes à prendre en compte en ce qui concerne la mesure basée sur la vitesse.

• La vélocité peut être volatile et peut dépendre de facteurs indépendants de la dette technique, tels que des bogues nouveaux (ou existants), des estimations mal alignées, des obstacles techniques ou des retards de projets externes.

• Les estimations ont un niveau d'incertitude inhérent et peuvent être une mesure inexacte pour commencer.

• La collecte et l'analyse de ces données peuvent être délicates et prendre du temps.

  
  

Un proxy rapide pour la mesure basée sur la vitesse consiste à demander à votre équipe d'ingénieurs d'estimer le temps qu'il faut pour terminer un projet/une tâche dans chaque domaine majeur de votre base de code. Mettez-vous d'accord sur une base de référence établie pour une zone bien comprise/fréquemment utilisée, puis demandez à chacun d'estimer la zone en pourcentage ou en multiple de cette base de référence. Bien qu'elle ne soit pas aussi rigoureuse qu'une approche de mesure basée sur la vitesse complète, elle peut donner une idée rapide de l'intérêt relatif de votre dette technologique en fonction de la perspicacité et de l'intuition de votre équipe.

Mesure basée sur les problèmes

Une approche différente consiste à identifier des instances spécifiques de dette technique au sein de votre projet et à estimer à quel point elles peuvent chacune vous ralentir. Une partie de cela peut être effectuée en utilisant des outils automatisés, tels que des outils d'analyse statique, pour trouver des problèmes courants concernant la qualité du code qui peuvent avoir des impacts sur la lisibilité, l'extensibilité ou la maintenabilité d'un projet. Pour chaque type de problème, vous pouvez lui attribuer un coût d'intérêt (par exemple, 5 min/semaine ou 1 %) en fonction de l'expérience de votre équipe dans le traitement de ces types de problèmes.

Mais cela ne capturera qu'un sous-ensemble de problèmes techniques causant une dette - d'autres seront plus subtils ou plus adaptés à votre base de code et ne seront observés que pendant que votre équipe travaille activement sur cette zone du code. Dans ce cas, vous souhaiterez enregistrer le problème spécifique (lié à une zone de votre base de code) ainsi que l'impact estimé qu'il a sur le ralentissement du développement. Pour suivre ces problèmes, nous vous recommandons d'utiliser une sorte de suivi des problèmes - soit dans un backlog de problèmes dans GitHub, Jira, etc., soit en utilisant un outil de suivi des problèmes de dette technologique spécialement conçu comme Taille de pas .

Certains des inconvénients de cette approche sont :

• Les estimations de temps liées à des problèmes spécifiques peuvent être inexactes
• Certains problèmes peuvent facilement passer inaperçus pendant une longue période

Mesure basée sur la qualité

Il existe une variété de mesures de qualité du code que vous pouvez utiliser pour avoir une idée globale de l'état de votre base de code et, à son tour, obtenir une estimation de la dette technique que vous avez actuellement et qui a un impact sur le développement futur dans chaque domaine. Chez Sourcery, nous avons tendance à regarder Complexité , Mémoire de travail et la longueur de la méthode comme métriques critiques lorsque vous recherchez une fonction ou une classe - mais vous pouvez également examiner des éléments tels que l'indice de maintenabilité, la couverture des documents et des tests, le taux de duplication et bien d'autres.

Semblable à l'approche basée sur les problèmes, vous pouvez attribuer un impact relatif de différents scores (ou d'un score global de qualité ou de santé) au ralentissement en cours et futur du développement en raison de la dette technique. La recherche a montré une forte corrélation négative entre des éléments tels que la complexité et la vitesse, ainsi qu'avec la qualité du code et le risque de bogue, la charge de maintenance, etc.

En regardant un exemple - revoyons la base de code simple en 4 parties que nous avons examinée dans la section sur la mesure basée sur la vitesse.

Nous pouvons facilement voir les sections problématiques de ce projet dans le tableau (surlignées en rouge) et le calcul de l'estimation des intérêts est relativement simple - il suffit de résumer les impacts sur les intérêts des différentes composantes.

Certains des inconvénients de cette approche sont :

• Vous devez définir des estimations d'impact d'intérêt sur différentes mesures de qualité (je cherche à en rassembler quelques-unes comme référence, mais cela dépendra assez de la base de code). Pour ce faire, vous voudrez probablement examiner certaines mesures basées sur la vitesse et les lier à la qualité.
• Les indicateurs de qualité eux-mêmes sont imparfaits et peuvent varient considérablement d'une langue à l'autre .

Cette approche de mesure basée sur la qualité est la moins précise des trois approches que nous avons examinées, mais elle est très efficace pour donner un aperçu global des différents domaines de votre projet au fil du temps. Vous pouvez combiner cette approche avec l'approche basée sur les problèmes dont nous venons de parler pour équilibrer le suivi des problèmes spécifiques avec le suivi des problèmes généraux de qualité et de santé dans chaque section de votre projet.

Examen de la fréquence d'interaction de la base de code

Pour ces trois approches, nous devons avoir un moyen de cartographier l'impact dans différentes sections de notre base de code par rapport à la fréquence à laquelle nous touchons réellement cette section de la base de code. S'il y a une partie de notre projet qui est un cauchemar à gérer mais que personne ne touche plus, cela n'a pas vraiment d'impact sur notre dette technique en cours. À l'inverse, un ralentissement léger mais persistant sur une section de la base de code à laquelle on contribue chaque jour peut entraîner très rapidement d'énormes pertes de temps.

Pour tenir compte de cela, nous devrons examiner à quelle fréquence chaque domaine de notre projet est contribué. Il existe plusieurs approches différentes que nous pouvons adopter ici - en regardant l'historique de Git pour comprendre quelle zone est largement touchée le plus souvent, en utilisant des outils plus ciblés comme Codescène pour obtenir des données de contribution historiques plus digestes, ou en utilisant une approche tournée vers l'avenir en examinant nos plans et priorités à venir pour comprendre où notre équipe passera la plupart de son temps au cours des prochains mois.

Quelle que soit la manière dont nous obtenons les données, nous pouvons alors obtenir une ventilation du pourcentage de notre temps que nous passerons à interagir avec chaque section de notre base de code. En combinant cela avec la contribution des intérêts que nous avons déjà déterminée, nous pouvons maintenant voir exactement à quel point nous nous attendons à être ralentis lorsque nous traitons chaque section de notre base de code à l'avenir.

Poursuivant sur notre exemple précédent - si nous prenions une vue tournée vers l'avenir et que nous renouvelions tous les projets sur lesquels nous allions travailler au cours des 3 prochains mois et que nous pouvions estimer en toute confiance qu'il s'agissait du temps passé dans chaque zone de la base de code ( rappelez-vous que c'est un projet très simple):

Nous pouvons maintenant relier cela aux estimations d'intérêt que nous avions de notre approche basée sur la vélocité et notre approche basée sur les mesures de qualité et avoir une bonne idée de l'endroit où nous sommes le plus ralentis.

Ici, nous utilisons les ralentissements de la vitesse que nous avons constatés pour les travaux sur les sections B et C à partir du moment où nous avons examiné les mesures basées sur la vitesse plus tôt et nous les utilisons pour calculer le temps perdu auquel nous nous attendons en raison de la dette technologique au cours des trois prochains mois. Dans l'ensemble, nous nous attendons à voir plus de 28 mois d'efforts supplémentaires pour les développeurs à consacrer uniquement à la dette. Une chose importante à considérer dans cette approche est que tout cela regarde la vitesse relative - de sorte que les projets de base sont traités comme n'ayant effectivement aucune dette, ce qui n'est normalement pas exact. L'autre problème de cette approche est qu'elle ne tient pas compte des variations des niveaux d'endettement futurs - qui sont susceptibles de se produire. Mais ils sont difficiles à prévoir, il est donc plus facile de les ignorer.

Ici, nous avons pris nos retards projetés typiques en fonction de la qualité du code de chaque section et les avons projetés sur les trois prochains mois. Dans l'ensemble, nous constatons des projections d'impact sur la dette nettement inférieures à celles que nous avions lorsque nous utilisions la méthode de la vélocité. En effet, les estimations de ralentissement basées sur la dette technologique sont inférieures à ce que nous voyions dans le cas de la vélocité - nous devrons peut-être faire un peu plus de calibrage dans ce cas ! Tout comme avec la métrique basée sur la vélocité, cela ne tient pas compte des changements futurs de la dette technologique - mais les deux estimations peuvent nous aider à déterminer comment nous devrions prioriser la réécriture et la refactorisation des différentes sections de notre projet.

Gestion des intérêts et de la dette

Nous avons examiné différentes façons de tenir compte de l'impact permanent de notre dette technique sur nous, mais nous n'avons pas entièrement répondu à la question de savoir ce qu'est un niveau sain de dette technique.

Malheureusement, il n'y a pas vraiment de chiffre précis. À court terme, accepter une dette pourrait être pragmatique. Mais, à long terme, nous voudrons viser à maintenir notre dette proche de zéro. Parce que les intérêts persistants vont s'avérer très coûteux et que la dette technologique continue de s'accumuler. Mais nous ne voulons pas passer tout notre temps à refactoriser et à réécrire des problèmes qui ne nous procurent que des gains marginaux.

Comme nous en avons discuté précédemment, nous ne voulons généralement pas passer du temps à traiter des zones de la base de code où :

Mais, à l'extrême, nous pourrions nous retrouver avec un cas où nous sommes massivement ralentis par un niveau élevé d'endettement qui est extrêmement coûteux à réparer - ce qui n'est pas non plus une bonne situation.

La meilleure approche est de tomber quelque part au milieu. Réservez du temps dans votre planification continue pour résoudre les problèmes de dette technique et refactoriser le code existant - en priorisant ce qui vous coûte actuellement le plus cher. Et continuez à pousser cela jusqu'à ce que vous voyiez des rendements décroissants significatifs de la réduction de votre dette.