XXP

novembre 2012

lun. mar. mer. jeu. ven. sam. dim.
      1 2 3 4
5 6 7 8 9 10 11
12 13 14 15 16 17 18
19 20 21 22 23 24 25
26 27 28 29 30    

« NDepend : palpez le code | Accueil | NDepend : palpez le code »

26 mai 2009

NDepend : palpez le code

Dans le bâtiment, livrer un immeuble avec des murs de guingois, des fondations en sable et des termites à tous les étages, c'est impossible ou presque. Pourtant l'équivalent dans le monde de l'informatique est courant : du moment que ça marche conformément au cahier des charges, le client est heureux.

C'est cool l'informatique

Evidement un peu plus tard, les couts des corrections et évolutions lui feront peut-être comprendre que son système est loin de l'optimal. Ou pas, puisque tous ses systèmes sont sans doute du même acabit… L'informatique, le paradis des escrocs ?

[Raaaa mais laissez moi caricaturer en paix, enfin quoi. Précisons aussi que je ne parle pas dans ce billet des livrables à courte durée de vie tels que les sites Web évènementiels, dont les qualités attendues sont bien différentes de celles des systèmes amenés à durer]

Pas sûr. Si on donne aux clients les moyens de rendre tangible la qualité du code, ils doivent pouvoir toucher du doigt les faiblesses du code aussi rapidement qu'ils perçoivent les murs fissurés.

Autant que j'ai pu en voir pendant un test rapide, NDepend fait parti des logiciels qui rendent le code et ses défauts "palpables" en quelques clics.

Du global au détail

Lancé sur un de mes projets personnels à partir des dlls et exe qui composent l'application développée en c#, j'ai immédiatement à ma portée plusieurs angles d'analyse :

Ndepend_queries

En sélectionnant l'angle "code quality", les méthodes qui "sentent mauvais" sautent au nez :

Ndepend_code_quality  

Un clic sur la ligne "Method too big" me permet de voir instantanément les coupables, en l'occurrence surtout des initialiseurs de WinForms générés par l'IDE (mais j'avoue, pas seulement) :

 

Ndepend_big_methods

La navigation est intuitive, on peut cliquer chacune de ces méthodes pour les éditer.

Documenter l'architecture

Une autre visualisation intéressante de NDepend est le graphe des dépendances. En quelques instants, NDepend produit un graphique capable de faire office de documentation pour les nouveaux développeurs de l'équipe comme pour le consultant en train de mener un audit. L'éventuelle complexité des dépendances et faiblesse du design devient évidente :

 

Ndepend_dependency_graph

Le graphe est interactif et permet d'identifier en quelques clics des dépendances pathologiques,  par exemple la curieuse relation entre Altercept.Repository.Database et Altercept.WatcherLib.Editor.

De la métrique avant toute chose

NDepend contient d'autres procédés de visualisation de données, notamment les matrices croisées et les treemaps, et d'autres façons simples de naviguer d'une visualisation à une autre. Le plus souvent, le graphique intègre les mesures réalisées sur les modules analysés. Il s'agit de métriques telles que le nombre de lignes, le nombre d'instructions IL, le nombre de connexions afférentes et efférentes (méthodes appelées, appelantes), la complexité des méthodes (nombre de if, while, for, etc.), et beaucoup d'autres. Chacune de ces métriques peut être exécutée au niveau méthode, classe, namespace, champ ou assemblée.

Ainsi les treemaps associent la mesure sélectionnée par l'utilisateur à la surface des rectangles. Idem pour le graphe de dépendance, dans lequel chaque module représente la métrique sélectionnée par la surface qu'ils occupent ou par la taille de leur police.

Personnalisation via Code Query Language

La définition de ce qu'est un code de qualité peut évidemment se discuter. Du reste elle dépend du contexte. A une extrémité du discutable on trouve le respect des conventions de codage, variable d'une entreprise à une autre, voire d'un projet à un autre. Les seuils de déclenchement des alertes (longueurs d'une méthode, nombre de méthode sur une classe, etc.) sont aussi sujet à discussion.

Pour faire face à cette variabilité, NDepend expose sa mécanique de vérification des contraintes de qualité à travers des requêtes qui s'exécutent sur le code analysé. Le formalisme des requêtes, écrites en CQL, est très proche de SQL.

Par exemple, une contrainte sur le nombre maximum de paramètre s'écrit en CQL :

WARN IF Count > 0 IN SELECT METHODS WHERE NbParameters > 5 ORDER BY NbParameters DESC

Pour détecter les interfaces qui ne respectent pas une convention de nommage (commencent par 'I') :

WARN IF Count > 0 IN SELECT TYPES WHERE IsInterface AND !NameLike "^I"

Plus d'exemples sur cette spécification de CQL : http://www.ndepend.com/CQL.htm


C'est pour qui ?

A mon avis NDepend est un must-have pour tous ceux qui doivent auditer la qualité d'un système à la livraison ou en production, qu'ils soient consultants auditeurs, responsables MOE interne ou architectes. Les prestataires escrocs, qui livrent des systèmes déstructurés bourrés de méthodes obèses, ceux qui produisent du jetable quand on leur avait demandé de l'évolutif, ceux-là sont vite démasqués.

Je vois bien aussi NDepend dans la main des chefs de projets techniques pour partager une vue globale du système en cours de développement et de son évolution. Le graphe de dépendances est déjà une documentation de l'architecture.

D'autre part NDepend peut aussi analyser le code modifié/ajouté/supprimé entre deux versions, Cf. l'analyse de la toute dernière livraison de .Net 4.0.

Des (petits) regrets

Juste deux petits regrets. D'abord je trouve dommage que la vue treemap ne puisse pas afficher deux mesures simultanément. Pour moi les treemaps c'est fait pour ça : la surface représente une mesure, la couleur en représente une autre. C'est par exemple le cas de cette représentation du marché qui associe la capitalisation des entreprises à la surface et l'évolution de leurs cours à la couleur.

Ensuite, je regrette que NDepend n'offre aucun moyen de détecter le code dupliqué, réputé génant vis-à-vis de la correction (code dupliqué -> bugs dupliqués) et de l'évolution (code dupliqué -> évolution dupliquée) du code. Il va falloir que je teste Clone Detective.

NDepend papa

Pour une fois que ça se passe dans se sens là, ça vaut le coup d'être souligné, ne serait-ce que pour l'Histoire : NDepend est le papa d'un petit Depend dans le monde Java, il est commercialisé sous le nom de XDepend par OCTO Technology (ce n'est pas tant que les J majuscules soit passés de mode, mais il semble que JDepend soit déjà pris).

Un très beau succès de Patrick Smacchia, créateur de NDepend.

TrackBack

URL TrackBack de cette note:
http://www.typepad.com/services/trackback/6a00d8341c871f53ef011570a3883a970b

Listed below are links to weblogs that reference NDepend : palpez le code:

Commentaires

Cela fait pas mal de temps que j'ai un œil sur NDepend, et vu la souplesse et les indicateurs qu'il offre, ça vaudrait la peine d'investir.

Personnellement, j'aime bien quantifié et qualifié, ne serait-ce pour expliquer aux profanes ce qu'implique du code.

Allez, on va acheter NHProf + NDepend, pour 450 €, reste encore à savoir utiliser ce type d'outils (ie : le temps, le temps !)

Merci Denis pour exposer les possibilités de l'outil. Quelques remarques

>en l'occurrence surtout des initialiseurs de WinForms générés par l'IDE

qui peuvent être éliminer avec une condition CQL du style:

AND !NameLike "InitializaComponent"


Dans les métriques importantes il y a aussi tout ce qui est relatif à la couverture de code importé de NCover ou Visual Studio.


>D'abord je trouve dommage que la vue treemap ne puisse pas afficher deux mesures simultanément.

A l'instant t On utilise déjà la couleur pour matcher les résultats des requêtes CQL mais la possibilité d'une seconde métrique viendra dans les prochaines releases.

>Ensuite, je regrette que NDepend n'offre aucun moyen de détecter le code dupliqué, réputé génant vis-à-vis de la correction


Je pense qu'il faut un outil à part entière pour ce besoin spécifique et complexe (Simian)


>NDepend papa

CppDepend est aussi dans le pipe, l'alpha est prometteuse et très bientôt une beta sera disponible publiquement :o)

Je confirme. Outil très pratique pour contrôler une base de code.

Une bonne gestion des dépendances est récompensée par un système modulaire. Or un système modulaire est dans sa globalité :
* plus simple à modifier / corriger. Les impactes sont minimisées - contrôlées.
* Les modules peuvent être adaptés et utilisés dans d'autres contextes / projet plus simplement.
* Les Hommes 'intègrent' aussi plus rapidement le projet.
* Le staffing technique en est d'autant assoupli.
...

L'inverse - pas de contrôle - sur le moyen / long terme ne peu qu'entraîner la paralysie du projet et souvent une démotivation des équipes techniques... C'est toujours plus motivant de travailler sur un projet que l'on trouve 'propre'.

Les dépendances, c'est le coeur de la bataille. Plus le logiciel avance / évolue plus un contrôle des dépendances est important et "payant". Le pire ce sont les dépendances cycliques. Pour imager ces propos, disons que l'on peut voir NDpend un peu comme le Monsieur Propre du code. C'est sur que l'on peut toujours s'en passer mais il se révèle d'une efficacité redoutable pour venir à bout des taches les plus coriaces :-)

A lire : http://codebetter.com/blogs/patricksmacchia/archive/2009/05/03/can-we-avoid-tooling-to-prevent-spaghetti-code.aspx

(Salut Denys!)

>Les dépendances, c'est le coeur de la bataille

100% d'accord!

Ravi que tu trouves l'outil utile Maxence, et dans la meme veine:

http://codebetter.com/blogs/patricksmacchia/archive/2008/09/23/getting-rid-of-spaghetti-code-in-the-real-world.aspx

pour identifier le code dupliqué, Stéphane M. de Valtech m'a indiqué qu'il existe Simian

L'utilisation des commentaires est désactivée pour cette note.