Parce que XPDays est un rendez-vous phare de l’agilité en France, on se devait d’être présent pour cette quatrième édition. Le temps d’arriver tranquillement dans le Chalet de la Porte Jaune sous un joli soleil matinal, on se demande par quoi commencer dans le copieux programme de cette première journée.

Notre premier choix se porte sur l’atelier « Blanche Neige et les Sept Nains : Le miroir magique vous aide à mieux travailler en équipe » présenté par Portia Tung et Pascal Van Cauwenberghe. « Miroir miroir, dis moi pourquoi ? », c’est avec cette question que démarre l’atelier, avant que toute l’assistance ne se lance dans un « TurboNetworking » (une sorte de speed-dating orienté réseau professionnel) où chaque participant dispose de 3 minutes pour découvrir 3 choses intéressantes chez 3 personnes. Exercice, où j’ai eu l’occasion de croiser un SCRUMMaster, un praticien de Crystal et un jeune développeur agile qui a travaillé sur divers Plugin Eclipse.

Après cette introduction, Portia et Pascal nous racontent l’histoire de « Blanche Neige et les sept nains », version Tarantino, toute ressemblance avec des projets informatiques étant volontaire … En effet on apprend que Blanche Neige est une bonne équipière, travaille dur et est un petit peu naïve ; le chasseur est discipliné, pragmatique, mais mercenaire ; Prof est savant, axé sur les solutions, mais arrogant ; ou encore Timide est attentif aux besoins des autres, calme, mais n’aime pas les conflits. Chaque personnage étant donc un type de personne que vous avez sûrement déjà croisé sur un projet.

La suite du jeu consiste à se regarder dans le miroir : on tire au hasard un des personnages (pour ma part j’ai eu Timide, le Chasseur et Blanche Neige), on choisit quelqu’un qui ressemble à ces personnages (non je ne vous dirais pas qui j’ai choisi) et on donne les raisons de ces ressemblances. Ensuite on recherche ce que ces raisons nous apprennent sur nous-mêmes et quelles actions nous pouvons  tirer de ces leçons apprises.

On continue en groupe, le but est de maintenant trouver un projet et de constituer une équipe avec ses personnages. Quels vont être leur rôle, leur place dans ce projet ? Comment va-t-on pouvoir tirer parti des richesses de ses gens malgré certains traits de caractères qui les opposent ? Blanche Neige, Grincheux et Timide vont-ils constituer une équipe qui déchire grave ? On termine la session en partageant avec le reste du groupe nos projets, et nos actions individuelles, le temps de récupérer les deux dernières leçons données par Portia et Pascal :

• Dans le monde des adultes il y a MBTI (Myer-Briggs Type Indicator) et Belbin. Mais n’oublions pas que cela reste des modèles, la réalité et les dynamiques d’équipes étant plus complexes.
• On ne change pas les autres, on ne peut changer que soi-même

Après ce superbe workshop, je pars coder pendant 30 minutes dans l’atelier de développement Xtrem Miles. Objectif ambitieux puisque nous nous retrouvons avec du code que nous n’avons pas écrit, et qui n’est pas entièrement testé. Cette contrainte nous oblige a effectuer une opération d’archéologie par le biais de tests dont le but est de nous permettre de comprendre comment le code existant fonctionne.

Ensuite, je me rends à la session « XP 2.0 : Améliorer l’amélioration continue avec Lean », présentée par Régis Médina et Antoine Contal. Sujet très à la mode, le Lean Management est ici présenté avec les raisons et motivations des orateurs, à savoir pour aller plus loin que XP en terme d’amélioration continue. Cette session est l’occasion d’avoir une présentation rigoureuse du système de management de Toyota, basé sur la satisfaction des clients, la réduction des coûts en éliminant les gaspillages et le développement des collaborateurs.

On y apprend comment le projet WebTV d’Orange, développé avec SCRUM, travaille sur son amélioration continue en y installant des pratiques issues du Lean Management, notamment le Kaizen (mesure de ses performances, rendre les problèmes visibles, résoudre les problèmes et en tirer les bonnes leçons). Pour mesurer ces performances, il faut identifier son client et identifier ce qu’il veut, quand et où, et sans problème. Une fois son client identifié, Antoine nous explique comment il a corrigé certains problèmes en installant des contre-mesures, en se basant sur le cycle d’amélioration de Deming, le PDCA. Parmi les leçons tirées on note l’émergence de standards de travail, projetés sur les murs en format A3. Ayant travaillé sur le projet d’Antoine, je m’aperçois alors que mon nom apparaît sur son A3 décrivant le processus du Stand Up Meeting de l’équipe WebTV. Me voilà dans le processus … Cette session nous apporte de nombreuses pistes pour appliquer cette démarche auprès des équipes de développement, mais on aimerait voir aussi d’autres chemins pour installer le Lean sur toutes la chaine de valeur du SI, incluant aussi la production par exemple. C’est d’ailleurs l’occasion de faire un peu d’autopromotion sauvage, où le Lean à la dimension du SI (chaîne de valeur partant de l’idée d’un MOA jusqu’à la production) sera aussi abordée à l’Université du SI 2009, avec, on l’espère, autant de talent.

Après la pause déjeuner, on part voir « La Théorie des Centres, une nouvelle façon de voir la conception incrémentale des logiciels » présentée par Régis Medina. On ne vous présentera pas la Théorie des Centres de Christopher Alexander (il nous faudrait plus d’un article de blog). Le célèbre architecte et auteur de « Notes on the Synthesis of Form » nous apprend que concevoir consiste à retirer des erreurs sans en créer d’autres ; et de « A Pattern Language » et « The Oregon Experience » où de nombreuses pratiques ont été reprises par Kent Beck pour XP. Après avoir pas mal plané avec une certaine euphorie lysergique, Régis Medina nous fait redescendre en nous montrant une démonstration de refactoring de code (comment faire émerger un FormBuilder dans un formulaire SWING) en utilisant la Théorie des Centres. Exercice particulièrement intéressant, prônant pour une certaine beauté du code, dont on regrette juste qu’il ne soit pas appliqué aussi sur la conception d’IHM.

La journée se termine avec quelques conversations autour d’un verre, avant de repartir content de cette journée, et on espère que les prochaines éditions de XPDays seront toutes aussi réussies.

Suggestion d'articles :

1. Compte rendu CITCON Paris 2009
2. 1er Compte rendu du séminaire « Lean dans les services »
3. 2ème compte rendu du séminaire « Lean dans les Services »

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