Dernièrement j’ai testé NDepend. Ce n’est pas un produit récent, mais il est bon de rappeler à quoi il sert. Cet outil est utile pour auditer du code. Grâce à lui, vous êtes capable d’analyser beaucoup de règles d’architectures logicielles.
Il y a beaucoup d’outils dans NDepend. Dans cet article, nous allons nous concentrer sur les deux outils que j’apprécie le plus et que j’utilise le plus souvent.

La matrice de dépendances

L’idée de la matrice est de faire une représentation la plus simple possible des dépendances de votre projet.

Matrice NDepend
Cette matrice permet de regarder deux choses :
– Les composants qui ne sont plus utilisés
– Les dépendances incorrectes

Les composants qui ne sont plus utilisés

Si vous cherchez dans cette matrice une ligne sans carré bleu, cela signifie que l’élément n’est pas utilisé. Vous pouvez donc vérifier si cela est logique ou non. Un élément comme la classe Program d’une application console doit contenir une ligne vide. Si ce n’est pas le cas, alors vous avez une utilisation incorrecte de la classe “Program”.

Les dépendances incorrectes

Dans un second temps je regarde quelle assembly utilise quelle assembly. Cela est utile par exemple pour vérifier que vos classes d’accès aux données ne sont pas utilisées par la vue directement. Ainsi, vous pourrez contrôler le respect des conventions d’architectures par vos développeurs. Si une assembly de type “DataAccess” est utilisée par une assembly contenant le “ViewModel”, avec cette matrice on peut donc détecter les abus créés par les développeurs.

Un autre exemple, vous avez une application découpée en deux partie importantes, backoffice et frontoffice. Vous pouvez vérifier avec cette matrice que les développeurs n’ont pas référencé un composant du backoffice dans le projet frontoffice. L’idée peut paraître exagérée, mais je l’ai déjà vu.
Si c’est le cas, deux choix sont possibles :
– Soit il s’agit d’un abus et le code est incorrecte.
– Soit on vient de remarquer que le code est commun. Il faudra probablement créer une assembly pour partager cette brique et éviter de référencer l’assembly du backoffice entièrement pour un seul objet.

Astuces de la matrice

Dans cette matrice vous pouvez zoomer sur un namespace, type, propriété, méthode. Ainsi on peut par exemple avoir les dépendances d’un type en particulier.
Je trouve que l’interface n’est pas toujours très claire, mais l’avantage est que vous avez en permanence une “bulle d’aide” qui vous explique à quoi correspond le nombre. J’ai toujours besoin de regarder cette bulle pour me rappeler comment lire la matrice.
Je l’utilise aussi pour détecter des librairies du type Tools, helper, etc. Ainsi, si vous avez une assembly avec une classe “Utils” alors vous allez détecter que tout votre code référence cette assembly. En zoomant, vous vous rendez compte que la dépendance n’est liée qu’à une seule classe. Dans ce cas, il est peut-être préférable de sortir cette classe dans une autre assembly.

Grâce à cette astuce, j’ai pu remarquer q’une assembly utilisée pour de l’IHM était référencée aussi dans la couche data. Pourquoi ? Car l’assembly était une assembly de type “tools” et était référencée par l’ensemble des projets de la solution, même si les helpers créés pour la couche d’accès n’ont jamais été utilisés dans l’IHM.

Analyseur

Analyseur NDepend

Le deuxième outil que je préfère est l’analyseur de code. Je trouve que dans cet outil il existe beaucoup de règles prédéfinies pour analyser votre code, certaines sont intéressantes et d’autres inutiles.
Exemple de règles inutiles : les champs doivent commencer par “m_”.
Mais il y a aussi des règles intéréssantes telles que “Method too big” qui nous permettent d’identifier les méthodes qui ont plus de 30 lignes de code.
L’avantage c’est que l’on peut modifier ces règles ou créer nos propre règles.
La syntaxe est du LINQ et permet de requêter des objets différents. Ainsi, on peut facilement changer le critère qui détermine que la méthode est trop grosse.

On a aussi des requêtes basées sur des critères de complexités cyclomatiques.
Par exemple on peux écrire:

from m in Application.Methods
where m.CyclomaticComplexity > 10
select m

Dans certaines sociétés, ils utilisent cet outil avec leur usine de Build. Cela permet de contrôler en permanence que les conventions d’équipes sont toujours respectées.

Il y a d’autres concurrents à Ndepend, mais ça reste un outil complet pour tout les développeurs qui souhaitent suivre l’évolution du code de leurs applications.

Conclusion

NDepend est un excellent outil. J’aime beaucoup ces outils qui permettent d’analyser du code et d’en sortir des métriques. Par contre il faut être prudent et ne pas aller dans l’excès et bloquer les développements. En général c’est pour cela que l’on commence à faire des exceptions sur certaines parties du code. A partir du moment ou vous posez une exception sur une partie du code, afin de ne pas générer d’erreurs dans un outil comme NDepend, posez vous la question de l’intérêt de la règle.

Lorsque vous développez un gros projet, NDepend reste aujourd’hui un outil indispensable pour analyser et surveiller votre code.