Risque et dette de qualité: ce que vous ne savez pas peut vous nuire

Lorsqu'il s'agit d'évaluer le risque d'une base de code, ce n'est pas un chiffre magique à puce unique, et ce n'est pas un simple feu de signalisation «go / no-go». Le risque est multidimensionnel et multi-variantes, et il est mesuré différemment selon les organisations.

Vous savez probablement déjà où se trouvent les parties à haut risque ou «mauvaises» du code - ce sont les parties du code que vous modifiez constamment, de petits ajustements ici et là pour résoudre de petits problèmes qui semblent inoffensifs en eux-mêmes mais qui représentent généralement une superposition de caractéristiques en plus d'une conception médiocre. C'est pourquoi la modification du code existant est la principale cause d'introduction de défauts dans une application.

Mais nous savons aussi que le changement est constant. Vous ne mettez jamais tout en œuvre complètement ou ne corrigez jamais la première fois, mais en même temps, au fur et à mesure que vous superposez le code existant, la connaissance de chaque cas d'utilisation et scénario est perdue, la complexité augmente et le code devient de plus en plus risqué. Ce sont ces changements qui fournissent la clé pour appliquer le contexte au risque.

Tout aussi important que la visibilité du risque lui-même est de comprendre comment y faire face - comment hiérarchiser les actions de correction pour atteindre un «niveau de risque acceptable» tout en minimisant l'impact sur la vitesse de l'équipe. Cet article se penche simplement sur cela: comment évaluer le risque de modifications du code et comment hiérarchiser et atténuer efficacement le risque.

Déterminer le risque multi-variantes

Le risque n'est pas un numéro unique ou un `` feu de signalisation '' au niveau du projet (bien que nous utilisions les couleurs des feux de signalisation facilement associées dans notre interface utilisateur), c'est une catégorisation de la base de code et des conseils sur les problèmes réels et potentiels. exister. Voir ci-dessous:

Un exemple de graphique à secteurs du Process Intelligence Engine de Parasoft qui montre la proportion de code à haut, moyen et faible risque.

La catégorisation du risque est à la fois multidimensionnelle et multi-variante - vous devez rassembler des métriques de qualité issues de techniques telles que l'analyse statique, les métriques, la couverture de code et les tests pour vraiment la comprendre. Aucune de ces techniques ne vous donne la valeur d'une dimension spécifique, mais vous donne plutôt une valeur pour une formule. Par exemple, la couverture de code n'est pas un bon nombre à utiliser seule, car vous pourriez avoir une couverture de 100%, mais seulement un petit nombre de tests faisant quelque chose de significatif - vous devez penser à ce que vous utilisez la couverture de code pour vous dire (c.-à-d. «Dans quelle mesure mon code est-il testé?») Et ajoutez plus de données pour obtenir une analyse plus significative.

Un exemple de graphique à bulles de changement de code risqué illustrant les risques les plus élevés. (Les bulles peuvent être développées pour voir les métriques conduisant les catégorisations.)

Le graphique à bulles ci-dessus illustre la catégorisation du risque en fonction de deux dimensions (également illustrées dans le graphique ci-dessous):

• Fardeau de la maintenance, en utilisant une combinaison de volume Halstead, de complexité cyclomatique stricte, de nombre de lignes de code et de rapport entre le code et les commentaires pour quantifier à quel point le code est maintenable et compréhensible, et
• Déficit de test, en utilisant le nombre de tests, le nombre de méthodes et la couverture de code pour quantifier dans quelle mesure le code a été testé.

Le code qui a été mal testé (c.-à-d. Un déficit de test plus élevé) est classé dans la catégorie à haut risque (rouge), tandis que le code qui est à la fois bien testé et bien construit (c.-à-d. Une charge de maintenance plus faible) est classé dans la catégorie à faible risque (vert).

Bases de code volatiles, où chaque changement est un risque

Au cours de la chaleur du développement, votre base de code est dans un état constant de flux et chaque ligne de code modifiée présente un risque inconnu. Cela cassera-t-il une caractéristique fondamentale? Introduit-il une faille de sécurité? Moins il y a d'informations, plus le risque est grand. Dans les articles précédents, nous discutons de la impact du changement sur les tests et comment la couverture de code doit être utilisée intelligemment pour prédire où les ressources de test doivent se concentrer. Cependant, même avec une couverture et des tests accrus, il existe toujours un risque supplémentaire qui s'accumule au fil du temps.

Le changement dans la base de code nous donne la troisième dimension de risque, et la plus importante: fiable. Pas le temps au sens traditionnel du terme, mais le temps en ce qui concerne les builds et les changements entre eux. En nous concentrant sur les parties de la base de code qui ont changé entre les versions, nous pouvons nous concentrer sur le traitement du code à la fois le plus risqué et le plus pertinent, car l'équipe travaille actuellement dans cette partie de la base de code.

Le fardeau de la dette de qualité vous ralentit-il?

Le code réutilisé et hérité a déjà son propre fardeau, en particulier pour la sécurité. Chaque ligne de code soumise ou modifiée ajoute à cette dette s'il n'y a pas de contrôles adéquats pour maintenir ou améliorer la base de qualité. Pour sortir de cette dette, comme toute dette, il faut de la concentration et un engagement de réduction. Aussi, comme toute dette, comment sait-on épargner si on ne sait pas où l'argent est dépensé?

Une fois que vous avez identifié le code présentant le risque le plus élevé et la priorité la plus élevée, vous devez également prendre en compte la quantité de travail nécessaire pour atténuer le risque. C'est la quatrième et dernière dimension: Dette de qualité. Dans le graphique à bulles ci-dessus, la dette de qualité est représentée par la taille de la bulle - plus la bulle est grande, plus les problèmes connus doivent être résolus. Dans notre exemple, la dette de qualité est une combinaison de violations d'analyse statique de haute gravité (y compris les violations de seuils définis pour les mesures de code) et d'échecs de test, normalisés par le nombre de lignes logiques de code (voir Figure 3).

Cette agrégation de tâches de qualité exceptionnelle donne des indications sur la quantité relative de travail requise pour réduire le risque du code.

Mais ce n'est pas ainsi que je mesure les risques!

Toutes les organisations ne suivront pas les mêmes pratiques de qualité ou ne s'entendront pas sur les facteurs à prendre en compte lors du calcul des dimensions. Vous devez être en mesure de configurer et de créer votre propre définition du risque.

L'exemple de ce blog est disponible pour les utilisateurs sur Parasoft Marketplace, vous permettant de l'utiliser prêt à l'emploi, en l'étendant et en le modifiant pour répondre à vos besoins spécifiques. En commençant par l'exemple, vous pouvez personnaliser l'analyse statique, les seuils de mesures et les catégorisations de risques en fonction de votre organisation.

Conclusion

Équilibrer les budgets, les calendriers et les objectifs de qualité avec des mesures de sécurité adéquates tout en satisfaisant les clients est un défi de taille avec des risques à chaque tournant. Cependant, l'automatisation des pratiques de qualité et l'intelligence des processus vous aident à déterminer où les ressources sont le mieux dépensées. Comprendre où se situe le risque et comment chaque changement de code affecte la qualité et la sécurité de votre ligne de base réduit de nombreuses inconnues dans l'équation de développement. La dette de qualité et de sécurité peut être vaincue avec la bonne concentration.

Par Marc Lambert

Vice-président des produits chez Parasoft, Mark est chargé de s'assurer que les solutions Parasoft apportent une valeur réelle aux organisations qui les adoptent. Mark travaille chez Parasoft depuis 2004, travaillant avec un large éventail de clients de Global 2000, des implémentations technologiques spécifiques aux initiatives plus larges d'amélioration des processus SDLC.