La formule de dette technique ne prend pas en compte la complexité

Question

Dans les versions de Sonarqube antérieures à la 5.5, il était possible de changer la façon dont la dette technique est calculée pour tenir compte de la complexité, mais après 5,5 je ne vois pas comment pour le changer. Avez-vous supprimé cette configuration?

À mon humble avis, le coût de l'assainissement est beaucoup plus difficile dans un code complexe que dans un code plus simple. Voici un post où vous pouvez voir et comparer deux projets similaires avec une dette technique similaire basée sur la taille, mais avec une dette technique assez différente basée sur la complexité. En outre, la couverture affecte cette mesure; et je pense qu'il est plus facile de modifier le code lorsque vous avez assez de tests et de couverture pour vous assurer que vous ne cassez rien.

Dans sonarqube la documentation, la formule utilisée pour calculer le ratio de la dette technique est:

Remediation cost/(Cost to develop 1 line of code * Number of lines of code) 

Mais le coût de remise en état est un montant fixe de temps configuré sur chaque règle, non ?. Donc, il est indépendant de la complexité que vous pouvez trouver dans le code.

Voici une image où vous pouvez voir comment cela pourrait se faire dans la version 5.1.2: Technical debt with complexity

Est-il possible de configurer, dans LTS ou version 6.x, la dette technique afin que la la complexité est-elle prise en compte comme dans les versions précédentes?

Si non, est-ce que c'est dans votre feuille de route? Avez-vous des références que la complexité ou la couverture n'affecte pas les coûts d'assainissement?

Merci d'avance.

Note: Le nouveau concept de complexité cognitive semble très intéressant, nous parlons encore de la complexité, ce serait un bon candidat. Mais je n'ai pas vu comment le voir dans Sonarqube 6.3.1, est-ce possible?

Answer 1

SonarQube 5.6 présente le modèle de qualité SonarQube, qui comprend les bogues, les vulnérabilités et les odeurs de code. Pour les odeurs de code, la dette technique est considérée comme la mesure importante. Pour les bogues et les vulnérabilités, c'est la gravité la plus élevée. En adoptant ce nouveau modèle de qualité, la capacité de calculer la dette technique en fonction de la complexité a en effet été abandonnée et il n'est pas prévu de la rétablir. Dans le même temps, "Dette technique" n'inclut plus le temps de corriger les bogues et les vulnérabilités; c'est seulement les odeurs de code.

Answer 2

Puisque la réponse G.Ann explique que ce n'est plus possible avec SonarQube, sur le code .NET, vous pouvez toujours utiliser l'outil NDepend.

• Il calcule les problèmes de code qui peuvent être integrated in the SonarQube system.
• Il le rend facile de fournir formulas that estimates technical-debt (coût de l'assainissement) pour chaque question

Avec NDepend a code rule is a C# LINQ query et il peut intégrer une formule pour estimer le coût de remise en état, et aussi une formule pour estimer l'intérêt annuel (le coût par année de ne pas régler le problème, son impact d'affaires en d'autres termes).La question la gravité est estimée à partir de l'estimation d'intérêt annuel par seuils

Par exemple, si vous voulez avoir une règle de code qui met en garde contre les méthodes complexes ne sont pas desservies par des tests, qui fournit des sur mesure et la dette réaliste et estimations d'intérêt annuel, la règle peut ressembler à:

// <Name>Complex method must be covered by tests</Name> 
warnif count > 0 
from m in Application.Methods 
where m.PercentageCoverage < 80 && 
     m.CyclomaticComplexity > 10select new { 
    m, 
    m.PercentageCoverage, 
    m.CyclomaticComplexity, 
    m.NbLinesOfCodeNotCovered, 
    Debt = (10 + 3*(m.CyclomaticComplexity -10) + 4*m.NbLinesOfCodeNotCovered) 
      .ToMinutes().ToDebt(), 
    AnnualInterest = (20 + 2*(m.CyclomaticComplexity) + 6*m.NbLinesOfCodeNotCovered) 
        .ToMinutes().ToAnnualInterest() 
} 

ici, nous choisissons simples formules linéaires mais il peut pratiquement être une formule, il est juste une requête C# qui a couru contre un modèle de code dédié à interroger pour la qualité du code.

La règle éditée dans Visual Studio avec le résultat ressemble à cela, et ces questions et estimations peuvent être importées dans le système sonarqube:

Disclaimer: Je travaille pour NDepend