InfOsaurus

Comme promis, voici la deuxième partie de la traduction de DDD Quickly : DDD Vite Fait, partie 2, notions avancées.

On y retrouve des techniques pour mettre en oeuvre DDD sur de gros projets impliquant plusieurs équipes, mais aussi pour refactorer un domaine et gérer sa croissance, notamment à travers la distillation et l'identification d'un Coeur de Domaine.

Bonne lecture ;)

(Mise à jour) : et voici le fichier complet avec les deux parties.

Jeudi 29 Octobre 2009, l'Agile Tour faisait étape à Bordeaux, au LaBRI. J'étais de la partie et ma foi, le bilan est plus que réjouissant. Au cours de la journée, les 150 participants ont pu apprécier :

• Des petites viennoiseries et du café pour bien entamer la journée.

• L'accueil des gentils organisateurs aux brassards roses très seyants ;-)

Mais surtout,

• Une foule de présentations et ateliers intéressants et instructifs... on aurait parfois aimé pouvoir se dédoubler pour être dans plusieurs salles à la fois.

Du côté des coups de coeur, j'ai été bluffé par le retour d'expérience Scrum de Philippe Launay de la société Agfa. Réussir à introduire l'agilité dans un projet avec des équipes multi-localisées sur plusieurs pays, des milliers d'utilisateurs, un périmètre tentaculaire et en partant avec de sévères handicaps techniques et organisationnels relève du tour de force. L'amélioration continue des équipes permise par la méthode est assez spectaculaire, et les leçons à en tirer très instructives.

J'ai cependant regretté :

• Ne pas avoir pu participer à la session TDD donnée par C. Couillard et J-B Dusseaut tellement c'était blindé de monde...

• Certains ateliers alléchants (dont le "bateau ivre" animé entre autres par Raphaël Pierquin) très limités en nombre de places. Dommage, mais je n'ai pas perdu au change avec le retour d'expérience de Philippe Launay.

• Un vidéoprojecteur rebelle a décidé de saboter la présentation "Contractualisation agile" qui du coup a pris du plomb dans l'aile malgré toute la bonne volonté de l'orateur...

Au final, cet Agile Tour fut pour moi très instructif et enrichissant. Bravo aux organisateurs qui ont su rassembler autant de talents et favoriser rencontres et échanges d'expériences tout au long de cette journée très réussie !

La béta 2 de Visual Studio 2010 étant sortie il y a peu, il était grand temps pour moi de voir ce que cette nouvelle mouture de l'IDE de Microsoft avait sous le capot.

Un tour sur la page de download de la béta, et après un processus d'installation classique mais efficace, la nouvelle interface s'offre à nos yeux.

Bon, à part une couleur bleu horizon du plus bel effet, on ne peut pas dire que la page de démarrage soit une révolution par rapport à Visual Studio 2008. Nouveau/Ouvrir Projet, Projets récents, quelques nouveaux liens comme la personnalisation de la page d'accueil, les habitués ne seront pas dépaysés.

Lorsqu'on ouvre un solution et qu'on commence à jouer avec la bête, petite déception : l'interface ne semble pas très réactive. Même si c'est pardonnable pour une béta, on constate à l'usage beaucoup de lenteurs et même quelques freezes momentanés (machine sous Windows Vista, Core 2 Duo 2 GHz, 4 Go de RAM). Peut-être la faute à l'IHM basée sur du WPF.

Mais voyons maintenant les principales nouveautés autour de ce qui nous intéresse le plus : la manipulation du code.

Navigation

Les développeurs de Visual 2010 avaient annoncé une navigabilité dans le code grandement améliorée, et c'est certainement un des domaines où le plus de progrès ont été faits. Voici les avancées les plus marquantes :

• Quick Search : activée par un Ctrl-virgule, cette boite de dialogue permet une recherche intuitive avec suggestion de résultat lorsqu'on tape les premières lettres d'une classe ou les majuscules qui composent son nom. En fait, un passage incontournable pour naviguer entre vos fichiers/classes, tellement il est pratique.

• Surlignage de références : lorsque le curseur se trouve sur une variable, méthode ou type, après quelques instants celle-ci est discrètement surlignée ainsi que toutes ses occurrences dans le fichier actif. Une aide visuelle non négligeable qui évite de chercher les références manuellement.

• Hiérarchie des appels : cette nouvelle fonctionnalité affiche un arbre contenant les appels à la méthode/property sélectionnée, les appels au code qui l'appellent, et ainsi de suite. Cela évite de faire des "find usages" successifs lorsqu'on veut remonter une pile d'appels dans le code.

Refactoring

Au système d'affichage d'erreurs à la volée déjà existant, les développeurs de Visual Studio 2010 ont ajouté, exactement à la manière d'un ReSharper, des petites boîtes de suggestion (les SmartTags) qui lorsqu'elles sont déroulées proposent un menu avec diverses actions de refactoring et de génération de code.

Si certaines sont utiles en toute occasion (implémentation/héritage automatique, suggestion d'ajout de références...), d'autres sont clairement orientées TDD comme la génération de stubs de classe ou de méthodes qui n'existent pas encore.
Le raccourci pour les SmartTags est Ctrl-point-virgule.

Un tueur de ReSharper ? Pas vraiment

Au vu de ces éléments, on pourrait penser que Microsoft a encore fait ce qu'il sait le mieux faire, c'est à dire copier les innovations de plus petits acteurs du marché pour les intégrer et les généraliser dans ses mastodontes. Le petit poucet innovant étant dans le cas présent JetBrains avec son ReSharper, plug-in tellement utile à la vie du développeur (il comportait déjà bon nombre des fonctionnalités de VS 2010 citées ci-dessus dès ses premières versions) qu'on avait du mal à s'en passer.
Le problème, c'est que Microsoft a copié cette recette à succès, mais en oubliant quelques ingrédients. Il manque à Visual 2010 tout un tas de petites fonctions de ReSharper qui me font dire que ce dernier sera toujours indispensable :

• Pas de fermeture automatique des accolades
• Pas d'autocomplétion des noms de variables avec un nom par défaut
• Pas de go to Inheritor / base
• Pas de surlignage des erreurs à la volée pour certains types d'erreurs (ex : non implémentation d'une interface)
• SmartTags mal placés : par exemple sur le nom de la classe mère après les deux points d'un héritage, mais pas sur le nom de la classe fille donc peu visible
• etc.

Au final, après quelques heures de manipulation de Visual Studio 2010, mon impression est qu'il n'est toujours pas aussi facile à piloter qu'un 2008 + ReSharper. Il manque cette réactivité, cette intuitivité qui font que l'IDE semble répondre au doigt et à l'oeil du développeur et lui apporte une productivité maximum.

Si l'on ajoute que JetBrains met la barre encore plus haut pour le futur ReSharper 5, je pense que le petit plug-in a encore de beaux jours devant lui...

En ce moment, je me replonge dans Domain Driven Design, l'approche du développement logiciel orientée domaine initiée par Eric Evans. Il m'est subitement apparu une chose que je ne m'étais jamais représentée auparavant, certainement parce que j'avais abordé le sujet avant tout par son aspect technique : le plus important à mon avis dans DDD, ce ne sont pas les patterns, c'est la philosophie de la modélisation collaborative du domaine.

Comprenez-moi bien, j'estime que les design patterns évoqués dans DDD sont brillants, ce sont des guides précieux pour développer un code du domaine clair, maintenable et faiblement couplé. Mais pour moi, l'essence de DDD ne réside pas là. Elle réside dans la collaboration étroite entre experts métiers, concepteurs et développeurs pour construire un modèle du domaine qui reflète la réalité et permet de résoudre de vraies problématiques métier. Elle réside dans la constitution d'un langage commun qui, en plus de faciliter la compréhension du métier par les personnes techniques, instaure dialogue et confiance au sein de l'équipe projet. Car je pense que c'est cela qui, au final, permet de faire du bon logiciel.

Je me suis sans doute heurté à ce constat car ce n'est pas du tout le cas dans l'organisation dans laquelle je travaille actuellement. Ca serait même plutôt le contraire. La forme de communication privilégiée est le fichier Word de besoin, de recette ou le ticket d'outil de gestion de bugs. Les conversations téléphoniques sont rares et ont souvent lieu en famille, entre développeurs ou entre experts métier. Sans parler de vraies rencontres entre développement et métier, inexistantes. Une méfiance d'origine floue entre les deux camps a installé une guéguerre perpétuelle MOE/MOA, les uns accusant les autres d'en demander toujours trop et de changer sans cesse de besoin ; les seconds soupçonnant les premiers d'être des tire-au-flanc. Du coup, l'idée de base chez la MOE est de se conformer à la virgule près aux documents, tels des actes notariaux, et chez la MOA d'en fourrer le plus possible dans lesdits documents. Bien sûr, c'est la connaissance du domaine qui en pâtit, tant l'incompréhension est grande. Il est même surprenant de voir que des développeurs avec plusieurs années dans l'organisation n'ont qu'une vision parcellaire et approximative du métier. Au final, le résultat se ressent dans la qualité du logiciel.

D'ailleurs - et ça ne s'applique pas seulement à mon exemple - de tels problèmes refont souvent surface sous la forme de code smells qu'on pourrait appeler Domain smells. Je me suis amusé à en recenser quelques-uns :

• Domaine fantôme : ça peut paraître abérrent, mais il n'y a pas de couche domaine dans le projet dont je parle, en partie à cause de la technologie employée. Le métier est fondu dans la masse du reste du code. Il va sans dire qu'une couche domaine séparée est indispensable, pour toutes les raisons de découplage, de lisibilité... qu'on peut imaginer.

• Domaine râpé : On constate aussi parfois que des bouts de domaine sont saupoudrés dans des couches différentes, le plus dur étant de ne pas être tenté d'en mettre dans la couche présentation. Même si ça peut être justifié, il vaut mieux pour la maintenabilité de l'application conserver au même endroit tous les éléments liés au domaine.

• Domaine indéchiffrable : un des principes de DDD est que le code du domaine doit être clair et compréhensible, et donner tout de suite une vision d'ensemble à celui qui y jette un oeil. Malheureusement ce n'est pas toujours le cas, souvent à cause d'une représentation brouillonne du domaine dans le code dûe à un manque de dialogue avec les experts métier. De plus il est facile de se perdre en créant toujours plus de helpers, de services et autres gestionnaires qui embrouillent la compréhension du domaine.

• Abus de notion : qui n'a jamais été confronté au mot-valise du domaine, à la notion métier un peu floue qui se retrouve toutes les trois lignes de code dans chaque module de l'application ? Comme si un développeur avait trouvé que le mot sonnait bien et décidé de l'utiliser aussi fréquemment que possible. C'est souvent le signe d'une modélisation pas assez en profondeur, d'un concept du domaine qui recouvre trop d'aspects et devrait sans doute être subdivisé.

• Frères jumeaux : parfois c'est l'inverse, deux mots différents sont employés à travers l'application pour recouvrir la même notion métier. Cela peut mener à penser qu'il s'agit de deux choses différentes, ce qui est source de confusion. Convenir d'un seul terme précis et bien identifié permettra d'éviter les malentendus.

• Déphasage de concept : ce smell se fait sentir lorsqu'on interroge un expert métier sur une notion présente dans le code du domaine, et qu'on s'aperçoit qu'elle est en total décalage avec la réalité, même si l'application semble se comporter correctement pour l'utilisateur. Il peut s'agir d'une mauvaise interprétation ou d'une supposition hasardeuse de la part d'un développeur. En tout cas, le code est à reprendre et la communication est à revoir.

Je vois d'ici certains dire "C'est bien beau, mais les experts métier ne sont pas souvent disponibles et une communication écrite restreinte est mieux que pas de communication du tout." Bien sûr, mais après tout, n'est-ce pas dans l'intérêt de la personne métier d'avoir une collaboration aussi efficace que possible avec le développeur qui réalisera l'application pour lui ? N'est-ce pas primordial de s'assurer qu'il est au diapason de la réalité du domaine ?

Même si l'expert métier ne peut pas se rendre souvent disponible, il devrait l'être autant que faire se peut. Une solution au problème pourrait être de timeboxer les scéances de conception collaborative. Parfois, un dialogue d'une demi-heure bien cadré et sans perturbation peut être plus efficace qu'une réunion décousue de deux heures, qui aura pourtant demandé plus de disponibilité à l'expert du domaine...