Il y a deux semaines a eu lieu le JUG de Lausanne sur l’analyse de la qualité du code. J’en ai été l’organisateur et la publication de la vidéo de cet événement m’a donné l’occasion de le revivre et m’a donné envie de le commenter. Voilà donc mes impressions personnelles sur cet événement.

Quelques explications pour commencer sur mes motivations : travaillant chez OCTO Suisse, j’audite régulièrement des applications sur des technologies variées, principalement JEE et C/C++ (personne n’est parfait). Comme tout le monde, j’ai mes habitudes et les outils que je maîtrise, et depuis quelques audits la sensation de faire un peu la même chose et de voir très souvent les mêmes problèmes (les deux sont certainement liés). D’où cette pulsion : découvrir de nouvelles manières d’auditer, de nouveaux outils, de nouveaux problèmes…

Tout d’abord je dis bravo aux éditeurs qui se sont tous pliés aux règles du jeu et qui ont réalisé ce mini-audit dans un format de présentation assez original et pas si facile. En deux mots, ils devaient présenter le résultat de l’audit de la même application avec leur outil, en 20 minutes et avec un maximun de démo et un minimum de slides (voir ici pour plus de détails). Ils l’ont tous fait de manière différente et je vais essayer de passer au travers de ce que j’ai aimé / moins aimé.

Sur la forme

J’avoue que j’ai été particulièrement impressionné par Freddy de Sonar. Pour moi c’est le seul à avoir réussi à donner une vision globale de la qualité d’IceScrum2 et qui a donné son plan d’action pour remédier à ces problèmes de qualité. En fait cela marque une différence d’approche très nette entre les éditeurs. Alors que Sonar a eu une approche top-down, les autres éditeurs ont eu plutôt une approche bottom-up. Henri d’XDepend a également eu une approche top-down mais c’était moins formalisé (il n’y a pas de dashboard dans l’outil) et il manquait un vrai plan d’action.

Autre élément de forme, Freddy a fait sa présentation en duo, avec lui en speaker et une personne au clavier pour la démo. C’était un plus indéniable, lui permettant de se concentrer sur le discours.

Sur le fond

3 éditeurs sur 5 (Coverity, Parasoft, Sonar) étaient d’accord, le logiciel IceScrum2 est d’une qualité moyenne selon leurs benchmarks. Sur ce point, j’ai été fortement impressionné par l’avis et par le benchmark de Coverity : ‘IceScrum2, 4 bugs / 1000 LOC, un logiciel dans la moyenne’. Jusque là rien d’extraordinaire me direz-vous. Ce qui m’a marqué, c’est la pertinence de ces chiffres. La moyenne provient de lignes de codes analysées via le programme Coverity Scan, soit plus de 14,5 milliards de LOC ! Et pour ce qui est de la fiabilité de l’indicateur, le taux de vrai positif (bugs avérés) est au-delà de 70% (je ne me rappelle plus du chiffre exact). J’avoue que j’ai été scotché. J’ai tellement l’habitude de devoir trier les faux-positifs ou les violations mineures dans les outils de qualité que, pour moi, il s’agit d’un vrai différentiateur pour Coverity de ne se concentrer que sur des bugs avérés.

Pour les deux autres éditeurs, Headway et XDepend, la conclusion était moins élogieuse. Ces outils sont positionnés de manière un peu différente, ce sont plus des outils d’analyse de l’architecture que des chercheurs de bugs comme Coverity, Parasoft ou Sonar. Pour Headway, l’architecture était plutôt mauvaise de leur point de vue : le code est spaghetti, il n’y a aucune structure au dessus des classes (*). Du côté d’XDepend, on a plutôt eu le droit à un ensemble de constats mais pas de vraie conclusion sur la qualité globale. Dommage.

Un manque sur lequel pour moi tous les outils se rejoignent, c’est que la plupart des benchmarks nous ont été donné de manière orale par les éditeurs. Extraits choisis : ‘[ndlr pour les duplications] au-delà de 2%, c’est qu’on a des problèmes’, ’4 bugs / 1000 lines of code is average’ etc… Pourquoi ne pas plutôt intégrer ces benchmarks dans les outils et les faire apparaître de manière visuelle (via une couleur, par exemple sur les différentes zones du dashboard Sonar) ?

Sur la technologie

Côté technologie, 3 produits m’ont impressionné : Coverity, (Re)Structure101 et XDepend.

Je ne m’étendrais pas sur XDepend, connaissant bien le produit puisqu’il est édité par OCTO. En deux mots, ce qui m’impressionne toujours avec cet outil c’est sa capacité à vous aider à rentrer dans le code et à l’explorer de manière visuelle. C’est également le seul outil du panel qui vous permet grâce à un langage SQL-like (le CQL) de requêter votre code au-delà des simples recherches sur des classes que vous pouvez faire dans votre IDE (usages, références, définition).

Structure 101 et Restructure 101 m’ont impressionné sur la façon dont ils restituaient et structuraient les dépendances. L’outil arrive à hiérarchiser les dépendances pour les rendre naturellement sous forme de couches. J’ai bien aimé également les notions de fat versus tangled que met en avant l’outil et aussi le discours qui va avec l’outil, notamment le fait que la structuration progressive des langages s’est arrêtée à la classe (label, fonction puis classe). Il y a une réelle valeur à structurer son logiciel à des niveaux d’abstractions supérieurs, ce qui devrait être fait au travers des packages et des binaires par exemple.

Mon troisième waouh va à Coverity. J’ai tout d’abord été impressionné par leur analyseurs. Par exemple leur analyseur ‘Flow Analysis’ est capable de détecter de manière statique des cas habituellement détectés au runtime, car il propage les valeurs de retours et d’appels entre fonctions, ce que ne fait pas l’analyseur ‘Flow Analysis’ de JTest par exemple. Il y avait notamment un cas de mauvaise synchronisation remonté par JTest au runtime alors que Coverity le remontait à l’analyse statique. Ensuite, un autre type d’analyse très impressionnante est leur ‘intention checks’, en français les vérifications de l’intention du développeur. Ces analyseurs détectent de manière statistique des comportements suspicieux. Par exemple un développeur qui ne vérifie pas la valeur de retour d’une fonction alors qu’elle est vérifiée dans 9 cas sur 10 dans le reste du code. Ou un développeur qui utilise l’opérateur == sur un objet alors que dans 5 cas sur 6 c’est equals() qui a été utilisé. Le dernier point, c’est que l’outil a l’air vraiment puissant pour analyser non pas une version d’un logiciel mais toute la vie d’un logiciel. L’analyse présentée par Coverity contenait tout l’historique et les différentes branches d’IceScrum2 et la démo mettait en avant quels défauts étaient présents dans quelle branche, les branches où le défaut avait été corrigé etc… Les autres éditeurs étaient loin de cela et le simple fait d’avoir été capable d’importer l’historique pour une simple démo montre que l’outillage de Coverity doit être à la hauteur. Enfin, c’est peut-être un détail mais les commentaires des erreurs paraissaient vraiment clairs.

Dernier point sur la technologie, je n’avais jamais vu d’analyseurs dynamiques en action et je dois avouer que cela m’a pas mal impressionné. Parasoft et Coverity ont démontré cette fonctionnalité dans leur sessions respectives et quand on voit les bugs qui en ressortent (à première vue surtout des bugs de concurrence) alors qu’ils n’ont stimulé l’application qu’avec quelques clicks, je n’ose pas imaginer la valeur des résultats de ces analyseurs en les faisant tourner sur des tests fonctionnels ou sur des tests de charge.

Sur l’utilisabilité

JTest est clairement le vainqueur ici car il s’intègre directement dans l’outil principal du développeur, son IDE. Pour les autres outils, Sonar et Coverity sont simples et ergonomiques. La difficulté pour maîtriser ces 3 outils ne vient clairement pas de l’outil mais de la compréhension des erreurs remontées par ces outils. Que veut dire cette erreur ? Est-elle importante ? Devrais-je la désactiver sur mon projet ?

Reste XDepend et Structure 101, qui sont deux clients lourds avec des interfaces assez évoluées et riches. Ces outils demandent néanmoins un vrai apprentissage avant d’être maitrisés, c’est très impressionnant en démo mais une fois seul face à la bête, mieux vaut se diriger vers les webcasts pour la prendre en main. Pour donner un ordre d’idée, j’ai encore découvert de nouvelles fonctionnalités sur XDepend au cours de la présentation d’Henri et il m’a bien fallu 2-3 audits avant d’avoir vraiment pris en main la bête.

Sur le prix

Je ne sais pas si on peut corréler le prix et la valeur mais les prix de ces 5 produits sont très différents, allant de gratuit à quelques milliers d’euros voire dizaine de milliers d’euros pour une licence serveur. Coverity est clairement l’outil le plus cher des cinq et ma perception est que ses analyseurs sont les plus évolués (parmi ses concurrents : Sonar et JTest). Reste la question sous-jacente : est-ce que ça en vaut le prix ?

Des regrets ?

Je dois dire que j’ai eu quelques regrets sur cette soirée. Premièrement l’absence d’un des leaders, à savoir CAST Software, qui n’a pas souhaité se joindre au comparatif. Ensuite, le fait qu’on ait principalement vu des problèmes remontés dans du code Java. Je m’attendais à au moins voir des problèmes sur la couche Web (HTML, JavaScript, CSS) et au mieux sur la base de données (schéma, requêtes etc…). Cette déception rejoint d’ailleurs le point précédent car c’est clairement une force de CAST ou de Metrixware d’être capable de faire des analyses multi-technos et aux frontières des technologies.

En parlant des absents, un autre regret est d’avoir dû se limiter dans le nombre d’éditeurs présents. Le concept de la soirée a en fait particulièrement séduit les éditeurs et deux éditeurs se sont montrés inventifs afin de pouvoir participer à l’événement : Kalistick et SQuoRING ont en effet publié dans la foulée leur analyse d’IceScrum2 et je vous encourage à les consulter ici et là.

Un point qui relève plus du détail est que j’espérais voir l’offre de JTest sur la partie génération de tests unitaires. C’est vrai que ça sortait du cadre de l’audit et je comprends donc qu’ils n’aient eu ni le temps ni l’occasion de l’aborder. Une prochaine fois, peut-être…

Enfin un dernier regret, qui est plus un souhait en fait, est de ne pas avoir (encore) essayé les outils. Je connais déjà assez bien Sonar et XDepend mais parmi les 3 restants, j’espère bien essayer sur un prochain audit, dans cet ordre, Coverity, Structure 101 et JTest. Histoire de pouvoir confirmer ou infirmer ce qui est aujourd’hui une première impression.

J’espère vous avoir donné envie d’en savoir plus sur ce thème et sur cette session, vous pouvez retrouvez les slides et la vidéo sur SlideShare et Parleys, bon visionnage !

-
(*) ce constat est à prendre avec des pincettes car Headway a concentré sa présentation sur IceFaces, qui est la librairie JSF qu’utilise IceScrum2 et pas du code IceScrum2 à proprement parler

Suggestion d'articles :

1. ANNONCE : Java User Group exceptionnel le 10 février à Lausanne, Suisse
2. Analyser la qualité de votre code Groovy / Grails
3. Retour sur le BarCamp Java du Mardi 30 Septembre

Le JUG Lausanne organise une session dédiée à l’analyse de qualité logicielle sur la plateforme Java, avec la participation des éditeurs phares du domaine. La liste finale des éditeurs est la suivante :

• Coverity
• Headway Software (Structure 101)
• Parasoft (JTest)
• Sonar
• XDepend

Au cours de cette session, chaque éditeur démontrera en 20 minutes les capacités de son outil à travers l’analyse de la même application : IceScrum2.

Ces démonstrations seront suivies de 20 minutes de « questions aux experts » où les participants pourront poser des questions ouvertes aux éditeurs, qui y répondront tour à tour.

Cet événement est un événement gratuit. Les présentations seront en anglais (Coverity, Headway, Parasoft) ou en français (Sonar, XDepend), selon les éditeurs.

Il est important de vous inscrire afin de prévoir la capacité de la salle. L’événemenent sera suivi d’un apéritif qui sera l’occasion d’échanger librement avec les éditeurs sur des sujets précis.

Attention, le lieu de l’événement n’est pas le lieu habituel ! L’événement aura lieu à l’hôtel Moevenpick de Lausanne, à deux pas de la station du métro M2 Ouchy et directement accessible depuis la gare CFF (comptez 10 minutes).

L’equipe du JUG Lausanne,

Suggestion d'articles :

1. Retour sur le JUG de Lausanne sur l’analyse de la qualité du code Java
2. Paris Java User Group – Maven à la demande
3. Compte-rendu de la soirée d’inauguration du French Scrum User Group

Marc Cherfi, membre de l’équipe XDepend animera le stand dédié au logiciel à l’Université du SI les 1er et 2 juillet prochains. Aujourd’hui il nous parle des standards de qualité du logiciel, du positionnement de XDepend sur le marché et de son intervention à l’USI.

Comment peut-on faire émerger des standards de qualité sur un projet au travers de l’analyse de code ?

Deux approches en général s’opposent dans ce genre de démarche :

• Une approche traditionnelle, dite Top Down qui consiste à prétendre l’universalité des règles de qualité et du bon design du code qui s’appliqueraient à tous les projets dans tous les contextes. Cette approche nécessite un investissement initial, pour mettre en place les outils, qui au fil du temps fournissent des informations qui s’avèrent inexploitables ou inadaptées. Vérifiez dans votre projet : Combien d’erreurs ou de warnings dans vos rapports Checkstyle ou PMD sur votre projet ? Pourquoi personne ne s’alarme plus ?
• Une approche plus inspirée des pratiques agiles et de l’amélioration continue des processus, dite Bottom Up. Dans cette approche les standards sont construits de manière itérative et incrémentale par l’équipe de développement tout au long du projet. Ce sont donc les standards que l’équipe se choisit et qui répondent à des problématiques concrètes rencontrées sur le projet. N’oubliez pas, on ne peut améliorer que ce que l’on mesure.

Je considère que cette seconde approche est la plus efficace pour rendre pérennes les actions d’amélioration pour la qualité logicielle.

Dans une telle démarche, nous identifions quatre grandes activités :

1. Extraire : Faire émerger l’information à partir du code source ou binaire
2. Visualiser : Naviguer dans l’information
3. Investiguer : Rechercher des informations précises, recouper et lier des domaines différents (code, test, historique) en fonction des besoins du projet
4. Contrôler : Cristalliser le résultat des investigations au travers de règles, de standards à contrôler selon une certaine fréquence

Un outil qui se veut le support d’une telle démarche doit adresser de manière simple et efficace chacune de ces activités.

Comment XDepend se positionne-t-il sur le marché ?

Dans l’écosystème Java, il existe beaucoup d’outils de qualimétrie. Le sujet a connu son heure de gloire il y a de cela quelques années et semble aujourd’hui éculé. Après la vague des extracteurs spécialisés (activité Extraire) comme PMD, Checkstyle, FindBug, l’activité se concentre aujourd’hui sur l’agrégation des indicateurs avec des outils comme Maven ou Sonar, ceci à des fins de contrôle (activité Contrôler).

Cependant, peu d’outils permettent aujourd’hui d’adresser les activités Visualiser et Investiguer. Pourtant elles sont au cœur de la production de standards adaptés et pérennes dans le temps. Au travers notamment du CQL (Code Query Language) et de son IHM innovante (Treemap, matrice de dépendances, …), XDepend couvre parfaitement ces deux étapes clés.

XDepend est encore un produit nouveau dans l’écosystème Java. C’est un produit qui progresse, avec une nouvelle version tous les mois. Il est actuellement disponible en RC2, et vous verrez que la version 1.0 prévue pour Septembre vous apportera encore plus de bonnes surprises.

Pourquoi animer un stand à l’USI ?

Tout simplement parce que XDepend est à sa manière au cœur des sujets phares de l’USI 2009, aussi bien sur l’aspect « informatique conviviale » que amélioration continue des processus IT. Dans la philosophie de l’USI le stand XDepend s’adresse autant aux Geeks qu’aux Boss.

Vous les Geeks qui pensez avoir un code qui déchire, apportez-le (*) et venez l’observer aux rayons X, vous découvrirez peut-être des choses surprenantes …

Vous les Boss pour qui le code est un lointain souvenir, apportez-le (*) et venez découvrir de manière conviviale les entrailles de vos applications.

Et pour tous ceux qui veulent découvrir XDepend : la puissance de son interface graphique, la précision de son langage d’interrogation CQL, ses facilités d’intégration au sein de vos projets, … venez maltraiter les principaux frameworks du marché (Spring, Hibernate, JDK).

Ce sera aussi l’occasion de nous rencontrer et d’imaginer ensemble le futur d’XDepend . Et enfin pour les incollables de la qualité logicielle et de la plate-forme Java participez à notre jeu concours pour gagner une licence XDepend Pro.

Pour en savoir plus :
Site web XDepend : http://www.xdepend.com
Blog : http://blog.xdepend.com

(*) Munissez-vous d’une clé USB contenant vos binaires (JAR, WAR ou EAR décompressés)

Suggestion d'articles :

1. Domain-Specific Languages: 3 questions à Guillaume Laforge
2. Architectures Web : 3 questions à Jean-François Caenen
3. Mozilla Firefox : 3 questions à Tristan Nitot

En ingénierie logicielle, tant qu’un projet se développe, la dette technique s’accumule inexorablement. Les sessions de refactoring sont là pour contrebalancer cette tendance et leur mise en place régulière garantit la maintenabilité du projet. Mais ce qui est délicat avec la dette technique, c’est qu’elle n’est pas vraiment mesurable, et comme l’iceberg, on n’en voit que la partie émergée. Résultat, le refactoring est souvent sous-estimé et mal maitrisé. Si on ajoute à cela une mauvaise couverture de test, refondre le code applicatif fait peur, fait mal. Plus personne n’a l’audace de le tenter, et à long terme, c’est la banqueroute assurée du projet.

L’objectif de cet article est de proposer une approche efficace pour savoir comment attaquer efficacement un grosse refonte d’un code mal couvert par les tests. Cette tâche technique est divisée en plusieurs problématiques : comment déterminer les zones de risque du projet, trouver où poser les tests pour sécuriser l’étape de refactoring et trouver les zones à refactorer.

Pour rendre l’article concret, nous allons utiliser à titre d’exemple XDepend qui est un outil d’analyse de code statique java. En effet, on parle d’amélioration de la qualité, donc pour juger de l’efficacité de nos actions, il faut pouvoir les mesurer.

Déterminer et sécuriser les zones de risques du projet

Les méthodes les plus risquées sont premièrement les méthodes les plus utilisées: en effet, un bug introduit dans le refactoring d’une méthode utilisée dans la plupart des fonctionnalités de votre application et les impacts sont tout de suite démesurés.

Pour mettre en évidence ces méthodes , nous disposons de quelques métriques simples comme le couplage afférent (Ca) et le couplage efférent (Ce).
Le couplage afférent pour un élément de code est le nombre d’éléments qui l’utilisent. Cette métrique témoigne de la « responsabilité » de cet élément dans l’ensemble du code.
A l’opposé, le couplage efférent est le nombre d’éléments différents qu’utilise un élément, témoignant de son « indépendance » vis à vis du reste du code.

L’outil d’analyse de code statique que nous utilisons, XDepend, permet de sortir la liste des méthodes les plus utilisées en une simple requête :

SELECT TOP 10 METHODS ORDER BY MethodCa DESC

Les méthodes qui ressortent de ces métriques sont donc logiquement les premières sur lesquelles il faudra porter son attention.

XDepend permet d’aller encore plus loin dans cette recherche, en donnant un score à chaque méthode (MethodRank) et chaque type (TypeRank) selon son importance. Ce score est calculé à la manière du Pagerank de Google : tout comme la pertinence d’une page web, l’importance d’un élément de code est déterminée par le nombre d’éléments de code qui l’utilisent et de leur importance.

SELECT TOP 10 METHODS ORDER BY TypeRank DESC

Sécuriser l’existant

On peut ensuite filtrer la liste de méthodes ordonnée par importance avec les informations relatives à la couverture de tests existante (si celle-ci existe). Ainsi, on met en exergue les méthodes les plus importantes qui ne sont pas suffisamment testées :

SELECT TOP 10 METHODS WHERE PercentageCoverage < 98 ORDER BY MethodRank DESC

Poser des tests sur ces méthodes nous assurera que le refactoring des zones associées ne provoquera aucune régression.

Repérer les zones à refactorer

Une fois le coeur du projet renforcé par un harnais de tests, on peut sereinement envisager de casser morceau par morceau pour mieux reconstruire. Mais comment déterminer la pertinence des méthodes à refactorer? Comment mesurer le gain qu’apportera ce refactoring pour la suite du projet ? Voici quelques pistes classiques à envisager en premier lieu :

Les méthodes mal codées

La littérature logicielle regorge de préconisation permettant de s’assurer qu’une méthode reste maintenable en traçant des limites pertinentes : complexité cyclomatique, nombre de lignes de code, de paramètres, de variables…

Toutes ces limites peuvent être visualisées en une requête :

WARN IF Count > 0 IN SELECT TOP 10 METHODS WHERE (
NbLinesOfCode > 30           OR
NbBCInstructions > 200       OR
CyclomaticComplexity > 20    OR
BCCyclomaticComplexity > 50  OR
BCNestingDepth > 4           OR
NbParameters > 5             OR
NbVariables > 8              OR
NbOverloads > 6
) ORDER BY MethodRank DESC

Le manque de cohésion des méthodes (Lack of Cohesion in Methods, LCOM)

La notion de cohésion d’une classe est aussi importante : les responsabilités de la classe forment un tout cohérent. Pour déterminer la cohésion, on se base sur l’utilisation des variables d’instance par les méthodes de la classe.
Plus le manque de cohésion (LCOM) est élevé, plus la classe est considérée complexe et donc moins facile à maintenir. Sur des classes comportant de nombreuses variables d’instance et de nombreuses méthodes, il est alors judicieux de surveiller ces classes et de les refactorer pour faire descendre le LCOM.

WARN IF Count > 0 IN SELECT TOP 10 TYPES WHERE
LCOM > 0.8 AND NbFields > 10 AND NbMethods >10
ORDER BY LCOM DESC

Les dépendances cycliques entre packages

Les dépendances cycliques entre packages amènent à l’antipattern du plat de spaghetti qui ne permet pas de déterminer le qui, le quoi et le comment d’une modification de données. Cette faible indépendance fonctionnelle porte préjudice au critère de réutilisation du composant.
Si A dépend de B qui dépend de C qui dépend de A, alors A ne peut plus être développé et testé indépendamment de B ou C. Ces packages forment une unité indivisibe, une sorte de super-composant qui a un coup bien supérieur en maintenabilité que la somme des 3 packages. Il faut donc repérer les dépendances cycliques et les casser.

WARN IF Count > 0 IN SELECT TOP 10 JARS WHERE ContainsPackageDependencyCycle

Le code mort

Le code mort peut devenir une plaie dans la maintenabilité d’un projet
Un Ca (couplage afférent) à 0 signifie que dans le contexte de l’application, la méthode ou le type concerné n’est pas directement utilisé.
On peut ainsi mettre en évidence rapidement des portions de codes qui ne semblent pas être utilisées en associant quelques règles CQL simples définissant une méthode non-utilisée :

WARN IF Count > 0 IN SELECT TOP 10 METHODS WHERE
MethodCa == 0 AND !IsPublic

Attention : Les méthodes publiques peuvent faire partie d’une API exposée et donc logiquement ne pas être utilisées dans le contexte de l’application, il faut donc les écarter de cette recherche.

Mesurer l’impact d’une session de refactoring

L’idéal après un refactoring est de prendre le temps d’analyser ce que le refactoring a apporté.
Première piste, regarder toutes les méthodes qui ont été modifiées suite au refactoring.

SELECT METHODS WHERE (CodeWasChanged OR WasAdded)

Le résultat de cette requête est parfois surprenant lorsqu’on compare ce qui était prévu et tout ce qui a été modifié au final.
On peut aussi tracer le nombre de méthodes et de lignes de code qui ont été modifiées et opposer ces informations à la durée du refactoring. Garder ces traces permet de s’améliorer en  estimant plus justement les refactoring suivants.

On doit aussi s’assurer que le code qui a été modifié est maintenant couvert au maximum. En effet, le but du refactoring est de « perdre du temps » pour remonter le niveau de qualité exigé pour maintenir le projet et être à l’avenir entièrement serein sur les points refactorés.
La requête suivante permet cette détection :

WARN IF Count > 0 IN SELECT METHODS WHERE
PercentageCoverage < 98 AND
(CodeWasChanged OR WasAdded)
ORDER BY PercentageCoverage DESC , NbLinesOfCodeCovered , NbLinesOfCodeNotCovered

(l’idéal est d’avoir un code couvert à 100%, mais en pratique il n’est pas toujours possible d’atteindre les 100% de couverture, 98% est notre valeur empirique).
J’espère que ces quelques préconisations vous aideront dans vos refactoring afin que cette tâche apporte encore plus de valeur à votre projet. Et vous, quels sont les indicateurs que vous surveillez durant vos refactoring et quelles autres approches avez-vous pour détecter au mieux les douleurs dans votre code ?

Aparté sur l’outil

Les requêtes utilisées dans cet article sont du CQL (Code Query Language) et peuvent être exploitées par les outils d’analyse de code NDepend (pour .Net) et XDepend pour Java que nous utilisons pour auditer les projets de nos clients. Il suffit d’avoir les binaires du projet (.dll ou .jar) pour lancer une analyse et effectuer ces requêtes sur vos projets. La plupart des requêtes sont prédéfinies pour vous aider dans vos analyses mais la puissance du langage vous permet d’affiner les requêtes facilement et d’ajouter des conditions supplémentaires sur plus de 80 métriques de design logiciel. La force de cet outil réside dans sa GUI aussi riche que dynamique.

Suggestion d'articles :

1. Le projet Da Vinci Machine, ou le support des langages dynamiques pour la JVM
2. Comment mesurer la productivité ?
3. Retour sur le JUG de Lausanne sur l’analyse de la qualité du code Java