Dot.Blog

C#, XAML, Xamarin, UWP/Android/iOS

NDepend 2017 est là !

Avec un peu de retard sur la sortie du produit il est temps de parler de cette nouvelle version qui ajoute l’analyse de la dette technique (mais pas que) !

NDepend

imageNDepend est un outil d’analyse de code. Il se présente sous la forme d’un exécutable stand-alone et d’une intégration à Visual Studio ce qui en rend l’accès et l’utilisation plus pratique.

Analyser du code mais pour en dire quoi et plus, pour en faire quoi ?

Well… C’est un vaste sujet et comme c’est un outil que je suis depuis longtemps j’ai déjà présenté l’essentiel de ces nombreuses facettes. De fait je renverrai le lecteur à quelques uns de mes anciens papiers sur NDepend pour me concentrer ici sur les nouveautés.

De 2009 à 2017, 8 ans de travail pour Patrick Smacchia, 8 ans d’évolutions pour parfaire un outil véritablement original. Lisez les anciens papiers ci-dessus pour vous faire une idée de la richesse de l’outil et n’hésitez surtout pas à télécharger la version d’essai gratuite (14 jours) http://www.ndepend.com/download.

De l’utilité de NDepend

Les nombreuses analyses proposées par NDepend vous donnent accès à une mine d’informations insoupçonnée pourtant il s’agit de votre code, celui que vous avez écrit. Mais vous le connaissez si mal en réalité ! NDepend vous le dévoile sous des angles nouveaux. Il vous donne accès via un langage de requête à des analyses impossibles à faire “à la main”. Comme il mémorise ces mêmes requêtes il peut jouer et rejouer sans fatigue les mêmes questionnements sur le code et montrer l’évolution dans le temps de sa qualité. De ce point vue le principe ressemble à celui du Unit Testing, mais il ne s’agit pas de faire tourner le code et regarder s’il plante mais de l’analyser, de trouver les relations entre classes, namespaces, débusquer les erreurs de conception.

Quand on doit analyser le code des autres, ce qui est mon cas lorsque je pratique des audit, NDepend est ma “caméra à rayon X” qui me permet de pourfendre le coque externe d’un code que je connais pas pour en faire une radio intime et m’aider à cibler mes sondages manuels. Cela m’aide à frapper en snipper car on donne en général beaucoup moins de temps à un auditeur pour voir tout le code qu’on n’en donne à un nouvel ingénieur qu’on intégrerait dans l’équipe de dev juste pour qu’il sache en gros de quoi il s’agit… Le rapport est même troublant, en 1 à 2 jours il faut voir tout ce qui ne va pas dans un code de dizaines de milliers de ligne alors qu’on excusera le nouveau de ne pas avoir digéré juste l’esprit de ce code au bout d’un mois ! Hélas pour moi (et heureusement pour vous qui pouvez faire appel à mes services) mon TJM n’est pas 30 fois celui d’un membre de votre équipe. C’est quelque part injuste j’en conviens et je vous remercie de l’admettre, mais revenons-en à NDepend !

Tout le monde ne fait pas d’audit de code et je ne voudrai pas laisser l’impression que cet outil ne sert qu’à ce type de mission.

Même sur un code personnel NDepend s’avère être un allié indispensable. Malgré l’expérience, l’observance de normes, etc, un code qui grossit est un code qui dérive. Le maintenir dans les rails, gérer la complexité, cela aussi fait partie du travail mais ce n’est pas le plus facile à faire. Sur 1000 lignes de code c’est assez simple, sur 10.000 cela devient beaucoup plus difficile et au-delà c’est un poste à temps complet.

Donc même pour une personne seule NDepend est indispensable. Bien entendu, dès qu’on travaille en équipe cela est un must puisqu’il faut contrôler de façon homogène des styles d’écriture et des types d’erreurs qui ne le sont pas, ce qui devient difficile et coûteux à la main.

La Dette Technique

L’une des grandes nouveautés de la version 2017 c’est le calcul de la dette technique. Une estimation car ici un calcul exact n’est pas possible et vous allez le comprendre.

Qu’est-ce que la dette technique ?

Originellement ce terme de dette technique est une métaphore qui permet de mettre en évidence le “code mal écrit qu’on écrira mieux plus tard” (Cunningham, 1992).

Deux versions s’opposent en réalité, l’originale, du code qu’on a réellement bâclé en pensant le réécrire plus tard, et tout simplement du code qu’on a mal écrit sans même s’en apercevoir !

La dette technique couvre bien entendu les deux car elle ne sait rien de vos réelles intentions ! Donc l’astuce consiste à détecter le “mauvais code” et a quantifier l’impact qu’il aura sur la maintenance du logiciel peu importe pourquoi il est mal écrit.

Le concept même de dette technique a forcément évolué depuis 1992, et aujourd’hui il a tendance à englober l’ensemble des éléments d’un logiciel, c’est à dire aussi bien ses tests unitaires que sa documentation, son architecture en plus de son code source.

La Dette technique est un animal étrange mais dangereux ! On la caractérise par le fait qu’elle est invisible puisqu’elle n’a pas d’impact immédiat, et que son effet négatif n’est qu’une projection, une prédiction d’un coût qui apparaitra plus tard mais pas forcément de façon sûre��

D’où une définition plus moderne de la dette qui est “le résultat invisible et potentiellement négatif que les actions du passé peuvent avoir sur le futur” (Kruchten, Philippe, Robert L. Nord and Ipek Ozkaya, 2012).

Il existe des ouvrages et des articles entiers consacrés à la Dette Technique et je vous conseille de vous y plonger pour en capter toute l’étendue et les subtilités (par exemple séparer le coût principal du coût risqué et du coût réel). Le plus intéressant étant de façon évidente les ouvrages qui traitent des stratégies à adopter pour limiter la Dette. La constater c’est bien, l’éviter c’est encore mieux !

Et cela tombe bien puisque c’est justement à cela que va servir la nouvelle fonction de NDepend 2017 : d’une part être au courant de la Dette Technique, en prendre conscience, mais aussi la quantifier, et surtout la localiser dans le code pour corriger la situation !

image

exemple de résultat d’une analyse de dette

 

NDepend fournit de nombreux tableaux et graphiques ainsi qu’un dashboard résumant les analyses. Ci-dessus on aperçoit le nouveau cadre réservé à l’analyse de la Dette Technique.

En pratique NDepend calcule la dette comme un temps de développement. Par exemple il vous dira (comme sur l’exemple plus haut) que vous avez 9 jour et 2h d’effort à fournir pour passer d’un code noté “C” (c’est pas bon !) à un code noté “B” (déjà plus acceptable). Il vous dira aussi que la dette elle-même est de 25 jours (toujours le même exemple). C’est un chiffrage intéressant puisque vous connaissez la dette et l’estimation de temps pour l’éviter.

NDepend calcule aussi les intérêts annuels de la dette (15,79% dans l’exemple). C’est le temps consommé par an (enfin son estimation) par le non règlement de la dette si on laisse le code en l’état.

Comme les problèmes détectés par NDepend peut avoir un indicateur de sévérité (bloquant, majeur, mineur, info) la mesure du taux d’intérêt de la dette annuelle représente en fait le même concept. Le taux d’intérêt est une mesure continue alors que les indicateurs de sévérité forment une mesure discrète.

De la même manière, c’est au niveau des règles qu’on peut indiquer le coût de la dette. Par exemple on peut créer une règle qui ajoute de la dette pour chaque méthode dont la complexité cyclomatique est supérieure à 10 et ce par un calcul faisant intervenir d’autres variables mesurées sur le code comme le pourcentage de couverture par les tests unitaires… Ah oui, ça se complique ! Mais il est difficile d’envisager de faire ça “à la louche” et à la main…

NDepend s’enrichit ainsi d’un nouvel outil de mesure qui complète à merveille tous les autres indicateurs déjà offerts. A vous d’en tirer le meilleur pour produire un code maintenable !

Les autres nouveautés

NDepend 2017 n’apporte pas que le calcul de la Dette Technique, Patrick a travaillé à de très nombreuses améliorations et même si la Dette est un “gros morceau” ce serait injuste de passer sous silence le reste.

Par exemple le support de .NET Core. C’est juste vital…

Des améliorations dans le dashboard avec des indications visuelles directes sur les progressions ou les régressions de chaque point mesuré. Forcément très utile pour juger d’un coup d’œil l’état du travail. Tout comme la génération automatique d’une requête qui depuis une mesure du dashboard va aller chercher les éléments correspondants dans le code, la dette, les seuils de qualité etc.

Et justement, parmi encore d’autres nouveautés que je vous laisse découvrir sur le site de NDepend (http://www.ndepend.com/ndepend-v2017) il y a les “Quality Gates”. Une quality gate, une porte de qualité ou un seuil de qualité, c’est une étape forcée pour pouvoir passer à la release d’un code et éventuellement même avant de faire un commit du code vers le repository.

On peut envisager de créer une porte bloquante si par exemple la dette technique a soudain augmenté de plus 10% par rapport à l’analyse précédente. Ou en fonction de bien d’autres critères puisque tout peut se calculer via des requêtes en CQLinq, le langage de NDepend (une sorte de SQL à la sauce LINQ adapté à cette source si particulière de données qu’est votre code, au lieu d’une base de données, Cf mes papiers précédents).

On notera aussi un nouveau menu pour la gestion des problèmes (issue manager) pour lister les points à régler en priorité.

Conclusion

Au fil des versions NDepend devient un outil d’analyse de plus en plus puissant et pointu. Il est impossible d’en brosser rapidement un aperçu tant chaque aspect, chaque analyse offerte mériterait d’y rester des pages et des pages pour en faire comprendre toutes les subtilités et avantages qu’on peut en tirer en situation réelle.

NDepend est forcément l’allié de l’auditeur, mais aussi du développeur isolé qui n’a personne pour vérifier son propre code tout autant que du chef de projet qui doit rapidement vérifier la qualité du code produit par son équipe. Chaque développeur est concerné par ce qu’il code. Dans une équipe rendre intelligible la dette introduite par certains ou réglée par d’autres est un instrument essentiel de gouvernance tout autant que d’évaluation ou d’auto évaluation de chacun. Il en va de même de la qualité du code, de son architecture, de sa documentation, ses tests unitaires…

En offrant une vision très large et très profonde à la fois sur le code NDepend est un outil hors norme. Ses évolutions qui étendent à chaque fois un peu plus la pertinence de ces analyses et l’étendue des aspects analysés participent à cette unicité.

Certes à force NDepend devient un outil plus complexe que le simple compteur de lignes de code intégré à VS… Certes… Mais en retour il vous en apprendra bien plus sur n’importe quel code que vous aurez à faire vous-même, à tester, à documenter, ou à maintenir !

Stay Tuned !

blog comments powered by Disqus