NDepend – Outil d’examen de code .NET

Qu’est-ce que l’analyse de code ?

Toute personne impliquée dans le développement logiciel comprend probablement l’importance de la qualité du code. Elle influe sur la facilité de maintenance du code, sa compréhension, l’ajout de nouvelles fonctionnalités et, bien sûr, la qualité du code a un impact significatif sur la qualité du logiciel. Étant donné que presque tous les développeurs ont leur propre opinion sur ce que signifie la qualité du code, la question « Qu’est-ce que la qualité logicielle ? » peut provoquer des débats animés. Malgré cela, il existe des normes généralement acceptées auxquelles la plupart des développeurs essaient de s’en tenir, comme la clarté, la simplicité et l’élégance de votre code (afin que quelqu’un qui n’est pas l’auteur puisse le maintenir et le comprendre), la facilité d’extension du code, ses performances, etc. L’une des façons d’atteindre une bonne qualité est d’utiliser des analyseurs de code. Alors, de quoi s’agit-il ?

En fait, le nom parle de lui-même ; de tels outils sont utilisés pour inspecter le code et rapporter des informations sur sa qualité, par exemple, si des violations des règles de programmation et de conception ont été trouvées, des données sur la complexité du code, etc. L’analyse du code source peut être à la fois statique et dynamique. L’analyse statique est effectuée sans exécuter le code. Ce type de logiciel analyse tout le code d’un projet pour trouver des vulnérabilités, le valide par rapport aux meilleures pratiques de l’industrie et offre également la possibilité de le valider par rapport aux règles de codage de l’entreprise, etc. Une telle analyse peut également être effectuée dans le cadre d’une revue de code. Après l’analyse statique, l’analyse dynamique peut être utilisée pour découvrir des défauts plus subtils. Elle utilise l’approche opposée et signifie analyser en se basant sur l’exécution. L’approche la plus courante consiste à exécuter des tests unitaires.

La combinaison de ces types d’analyse devrait aider à trouver près de 95 % des défauts, à condition que l’analyse soit effectuée par une personne qui comprend le code source. Cependant, tous deux ont leurs propres points faibles. Par exemple, les analyseurs de code n’ont aucune compréhension de l’intention de l’auteur du code et peuvent signaler de faux positifs (une vulnérabilité possible qui n’existe pas en réalité), ou de faux négatifs (inversement, lorsqu’une vulnérabilité existe mais que l’outil ne la signale pas). Il ne peut pas non plus garantir une couverture de test complète du code source et ne peut pas vérifier l’exactitude d’une opération de code (c’est-à-dire qu’il ne peut pas vérifier que votre code fonctionne comme votre client s’y attend).

En tant qu’entreprise de développement .NET, nous avons une grande expérience avec différents outils qui améliorent le code. Dans cet article, nous nous concentrerons sur les analyseurs de code statique, et nous examinerons également NDepend, un outil d’analyse statique pour le code managé .NET.

Choisir un analyseur statique

Imaginons donc que vous décidiez d’utiliser un outil d’analyse statique. Le choix de l’outil approprié est toujours un processus individuel. Certains développeurs utilisent des analyseurs statiques intégrés à leur IDE, d’autres préfèrent des solutions tierces. Voici quelques points communs à considérer lors du choix de l’outil qui vous convient :

1. Tout d’abord, ne recherchez que les outils qui prennent en charge le langage de programmation et l’IDE que vous avez choisis.
2. N’hésitez pas à consulter les avis sur ces outils et à les essayer un peu – vous pourrez ainsi vous assurer que la solution choisie est aussi bonne que vous le souhaitez.
3. Vérifiez la capacité de l’outil à définir facilement des règles supplémentaires afin que l’outil puisse appliquer les politiques de codage internes.
4. Examinez le modèle de tarification de chaque outil.
5. Réfléchissez à ce que vous attendez de l’outil et écartez ceux qui ne fournissent pas les fonctionnalités requises. Par exemple, certains outils se concentrent uniquement sur la qualité du code, donc, si votre objectif est également de vérifier la sécurité, alors ils ne sont évidemment pas votre choix.
6. À quelle fréquence l’outil est-il mis à jour. De nouveaux problèmes surviennent constamment et vous devez vous assurer que les auteurs de l’outil sélectionné le mettent à jour régulièrement.

Gardez à l’esprit que l’utilisation d’analyseurs statiques seuls n’est pas une solution. Tout d’abord, des processus solides peuvent garantir la sécurité des applications et la qualité du code dès le départ. De plus, vous avez besoin de quelqu’un qui puisse examiner les résultats de l’analyse et décider quoi faire lorsque des problèmes sont trouvés.

Redwerk fournit un développement complet, du concept initial à la solution opérationnelle, et nous accordons une grande importance à la qualité du code. C’est pourquoi, lorsque nous avons reçu une demande de Patrick Smacchia, le développeur principal de NDepend, pour essayer leur outil, nous avons accepté cette proposition et, par conséquent, nous avons également décidé de fournir un aperçu de cet outil. Au moment de la rédaction de cet article, la version de NDepend était la 1.9.

Analyseur de code managé .NET – NDepend

L’outil NDepend prend en charge un grand nombre de métriques de code, y compris des graphiques de dépendance et une matrice de dépendance pour explorer la structure du code. Nous allons examiner le programme autonome NDepend Professional. En dehors de cela, NDepend offre plusieurs variantes d’intégration :

1. Extension Visual Studio.
2. Un exécutable en ligne de commande, qui est utilisé pour exécuter une analyse avec NDepend et générer un rapport. Il prend des arguments en ligne de commande et le seul paramètre obligatoire est le chemin d’accès absolu au fichier projet NDepend qui définit la base de code à analyser.
3. PowerTools est un ensemble de petits programmes basés sur NDepend.API. Ils sont open source et servent à démontrer la syntaxe et les capacités de NDepend API.
4. Extension Azure DevOps et TFS.
5. Plugin NDepend TeamCity.
6. Il n’y a pas d’intégration avec Jenkins, Atlassian Bamboo et AppVeyor comme, par exemple, avec Azure, mais il est possible de les intégrer via NDepend.Console.exe.
7. Intégration SonarQube.
8. Intégration CruiseControl.NET.
9. Intégration FinalBuilder.
10. AddIn pour Reflector.
11. Vous pouvez également importer les fichiers de résultats de couverture OpenCover, JetBrains DotCover ou NCover (3.X et supérieur) dans le projet NDepend.

Comme vous pouvez le constater, NDepend offre une large gamme de variantes d’utilisation. Ils proposent également un essai gratuit avec un lot de fonctionnalités de l’édition professionnelle. Dans cet article, nous allons essayer de fournir un guide étape par étape pour travailler avec NDepend et, nous l’espérons, cela aidera les lecteurs à décider s’il convient actuellement à leurs projets actuels ou non. Comme conseil, si vous pensez qu’un tel outil n’est pas nécessaire pour le moment, vous pouvez quand même examiner NDepend, car lorsque vous aurez besoin d’un analyseur statique, vous réduirez le temps de recherche d’un outil utile.

Processus d’installation et premier lancement

NDepend est distribué sous forme de fichier .zip. C’est une question controversée, lequel est le meilleur : fournir un installateur MSI ou un fichier .zip. Les deux variantes ont des avantages et des inconvénients et auront leurs partisans. Quoi qu’il en soit, en raison de la variante de distribution actuelle, le processus d’installation de NDepend est assez simple, il suffit de décompresser les fichiers dans un dossier d’application sur votre machine. La seule remarque est qu’il n’est pas recommandé de décompresser les fichiers dans le dossier « %ProgramFiles%NDepend ». Cela peut causer des problèmes en raison de la protection de Windows. Lors du premier lancement, vous devez saisir votre clé de licence, puis vous verrez l’écran principal où vous pourrez installer l’extension nécessaire (pour Visual Studio, Azure DevOps, etc.) et créer un projet pour l’analyse. La capture d’écran ci-dessous illustre l’écran principal de l’outil.

L’interface est assez simple et rappelle celle de Visual Studio. Et ce n’est pas une coïncidence, car les skins NDepend contiennent un certain nombre de skins Visual Studio, MS Office et DevExpress, y compris même l’option de changer le texte du menu de majuscules en minuscules.

Comme nous examinons le programme autonome, nous devons créer un nouveau projet NDepend. À des fins de cet article, nous utiliserons notre projet de test, utilisé pour montrer des exemples pour l’un des articles précédents. Le processus de création est assez standard et simple : il suffit de fournir un nom de projet, son emplacement et son nom de fichier. Après cela, vous verrez un panneau « Propriétés du projet », via lequel vous pouvez choisir les assemblies et définir les options d’analyse requises.

Examinons ces options d’analyse une par une pour avoir une idée générale des options que vous pouvez configurer :

1. L’onglet « Code à analyser » vous permet de choisir les assemblies à analyser, y compris vos propres assemblies et ceux de tiers utilisés par votre application (comme mscorlib.dll ou Log4Net.dll).
2. Dans l’onglet « Analyse », vous pouvez modifier le nom du projet et le dossier de sortie, si nécessaire, et il permet également de configurer certaines options d’analyse. Vous pouvez définir, par exemple, les options suivantes :
   • avec quels résultats d’analyse précédents l’analyse actuelle doit être comparée ;
   • définir l’emplacement où les résultats des analyses historiques sont stockés et la fréquence des sauvegardes ;
   • définir la fréquence du journal des métriques de tendance et l’emplacement où elles sont enregistrées. Ces valeurs sont enregistrées au moment de l’analyse ;
   • définir les fichiers de couverture (XML NCover, dotCover, OpenCover ou VisualStudio) à partir desquels les statistiques de couverture des tests seront collectées ;
   • définir l’option « Source File Rebasing », qui est utilisée lorsque la compilation du code et l’analyse NDepend sont exécutées sur une machine différente. Si elle est spécifiée, des informations seront collectées non seulement à partir des assemblies sélectionnés, mais aussi à partir des fichiers sources s’ils sont disponibles.
3. Dans l’onglet « Problèmes et Dette », vous pouvez configurer le calcul de la dette technique et ses résultats. La dette technique est le temps homme estimé qui pourrait être nécessaire pour résoudre le problème. Vous trouverez plus de détails sur cette option et les paramètres fournis dans la documentation NDepend correspondante.
4. L’onglet « Rapport » vous permet effectivement de personnaliser les rapports fournis (par exemple, activer ou désactiver des options telles que l’évitement des rapports trop volumineux pour une base de code importante, masquer les assemblies tiers, etc.).
5. L’onglet « Chemins référencés » affiche tous les chemins référencés par le projet NDepend et vous pouvez y gérer la redirection des chemins. Il contient également une explication sur les types de chemins qui peuvent être utilisés et permet de gérer les variables de chemin.

Après avoir examiné la panoplie de paramètres disponibles, passons à l’examen des fonctionnalités de NDepend. Cliquez sur « Ajouter une solution ou un projet VS », sélectionnez le projet que vous souhaitez analyser, puis cliquez sur le bouton « Lancer l’analyse sur le projet actuel » (ou appuyez sur F5). L’analyse est assez rapide (nous avons essayé sur plusieurs projets de différentes tailles) et après analyse, vous verrez un tableau de bord rempli de résultats comme indiqué ci-dessous :

En haut, vous trouverez des informations structurées sur les résultats de l’analyse, telles que le pourcentage de commentaires, le nombre de lignes de code, le nombre d’échecs, d’avertissements, etc. Les graphiques de tendance, qui sont affichés en bas de la capture d’écran, donnent un aperçu des changements de la qualité de votre code au fil du temps. Lors de la première exécution, cela peut sembler peu informatif, mais plus tard, après un travail d’amélioration du code, vous verrez les progrès.

Vous pouvez cliquer sur les valeurs dans « Règles », « Seuils de qualité » et toutes les autres zones pour voir des informations connexes plus détaillées. Par exemple, il y a 1 règle violée dans notre projet de test, et si vous cliquez sur la valeur, un bref résumé du problème s’affichera sur la droite. Si vous faites un clic droit et sélectionnez « Épingler la description dans la vue d’informations », vous verrez une explication détaillée, comme indiqué ci-dessous :

Ces explications sont assez informatives et contiennent à la fois la description des problèmes et des liens pour obtenir des informations plus détaillées. En double-cliquant sur la règle, vous verrez où le problème est réellement situé. Un compteur sur le côté droit des boîtes indique le nombre de problèmes résolus (vous pouvez les trouver sur la capture d’écran ci-dessus).

Requête de langage de code

Sous le « Tableau de bord », il y a le « Explorateur de requêtes et de règles », qui est l’un des panneaux importants pour comprendre et personnaliser votre analyse. Il affiche toutes les règles appliquées et vous pouvez facilement en activer ou désactiver certaines, voire en écrire de nouvelles, selon ce qui vous convient. Toutes les règles sont écrites en Code Language Query (CQL), dont la syntaxe est similaire à LINQ, il ne devrait donc y avoir aucun problème pour ajouter ou modifier des règles, d’autant plus que l’éditeur dispose d’une coloration syntaxique, d’une complétion de code et d’une documentation par info-bulle.

C’est une fonctionnalité vraiment puissante et formidable de NDepend. Malgré cela, ils fournissent de nombreuses métriques de code par défaut, beaucoup de gens seraient enthousiasmés par la possibilité d’ajouter leurs propres règles métier ou personnelles, qu’ils considèrent comme « indispensables » pour vérifier la qualité. Toutes les modifications sont enregistrées dans le fichier .ndproj, donc si vous le partagez, par exemple, via un contrôle de code source, toute l’équipe aura les nouvelles modifications. Au tout début, cela peut prendre un certain temps pour configurer toutes les règles nécessaires, mais après cela, vous serez sûr que l’analyse est adaptée à 100 % à votre projet.

Toutes les règles prédéfinies ont des commentaires qui vous fournissent une description plus complète. Pour voir une telle explication, il vous suffit de cliquer sur la règle qui vous intéresse, et sur le côté gauche, vous verrez sa requête CQL et une description.

Graphique de dépendance

NDepend possède une autre fonctionnalité intéressante : le graphique de dépendance, qui peut être très utile pour les grands projets lorsque vous essayez de comprendre la structure et les dépendances. La taille de chaque nœud est directement proportionnelle au nombre de lignes de code qu’il contient, mais ce paramètre peut être facilement modifié dans le panneau. Le graphique est coloré, ce qui aide à séparer visuellement les assemblies dont il dépend (en bleu) et les assemblies qui en dépendent (en vert). Chaque nœud est navigable, vous pouvez donc ouvrir votre code source en cliquant simplement sur le nœud souhaité.

Matrice de dépendance

Comme vous pouvez le constater, pour un petit projet, le graphique est assez compréhensible et miniature. Pour les grands projets, la situation est assez différente – le graphique est énorme et plutôt confus, et il est indéniablement difficile de représenter la structure d’un grand projet complexe sous la forme d’un petit graphique clair. Pour parcourir de grandes structures, la matrice de dépendance convient mieux.

La matrice montre également les dépendances entre les assemblies et leurs membres, ainsi qu’avec d’autres assemblies du projet. Chaque cellule non vide contient un nombre, qui indique la force des liens (nombre de membres, méthodes, champs, types ou espaces de noms impliqués dans le couplage). La couleur de ces cellules a également une signification et peut vous aider à identifier le code qui nécessite une refonte.

Vue des métriques de code

La vue Métrique permet de visualiser les métriques de code de l’application pour améliorer la compréhension de la base de code. Cette vue affiche, en fonction des paramètres sélectionnés, toutes les méthodes, champs, types, espaces de noms ou assemblies représentés par un rectangle coloré. Par défaut, le niveau est défini sur « Méthode », de sorte que toutes les méthodes groupées par assembly sont affichées dans la vue. La taille de chaque rectangle dépend du nombre de lignes de code et la couleur dépend de la métrique de complexité cyclomatique. Vous pouvez facilement modifier l’un des paramètres de cette vue, y compris la coloration, la représentation, etc.

Résumé

Résumons tout ce qui a été discuté dans l’article. L’utilisation d’outils d’analyse de code ne signifie pas que la qualité de votre code deviendra magiquement parfaite. Vous devez vérifier systématiquement la qualité du code pour une détection précoce des problèmes, et les analyseurs sont là pour vous aider.

Quant à NDepend, nous avons essayé de faire une critique aussi complète que possible, sans parti pris. Nous avons reçu la licence gratuitement, sans aucune pression de la part de l’équipe NDepend pour écrire l’article ou fournir un retour positif. Malgré cela, après l’avoir utilisé pendant un certain temps, nous avons décidé que cet outil pouvait être vraiment utile et méritait au moins un bref aperçu de ses fonctionnalités. NDepend est un outil vraiment puissant, qui fournit une critique objective et impartiale de votre code. La capacité de personnaliser l’analyse pour chaque projet offre un potentiel énorme. En tout cas, la seule façon de décider s’il vous convient à 100 % est de l’essayer vous-même, surtout compte tenu de leur version d’essai.