L'Agilitateur Création de logiciels : de l'agilité à l'artisanat

Dans mon dernier billet, j'ai volontairement omis la revue d'une des solutions proposées à l'Architectural Design Challenge de James Shore. Je n'ai pas traité celle de l'auteur lui-même.

La raison ? Elle n'en valait pas la peine. Où plutôt elle devrait être montrée comme exemple de ce qu'il ne faut surtout pas faire. Il n'y a pas besoin d'y consacrer trop de temps pour s'en rendre compte.
James Shore est parti d'un architecture pré-conçue à 3 niveaux où chaque niveau dépend du suivant : UI -> domaine -> persistance. Et ça donne ça :

Un vrai sac de noeuds où tout dépend de tout, où les interfaces n'introduisent aucun découplage (à part, à la marge, "PersistanceMechanism"). Le diagramme de séquence pour le scénario principal montre d'ailleurs très bien les incessants aller-retour entre les divers élements :

Il faut dire que ces diagrammes sont de moi. Je les ai postés en commentaire du billet de James Shore mais celui-ci n'a pas daigné les commenter. Un commentateur a toutefois tiré la conclusion qui s'impose : This looks almost as bad as I thought ;-) ... To me it seems the "dependency oriented design style" is hindering the solution of such a simple problem.

Tout ça n'est pas très réjouissant mais il y a pire. James Shore présente son approche comme étant "mock-driven" et elle ne l'est pas du tout. Un autre commentateur l'a bien compris : the approach in this post shows internal conflict in trying to stick to pre-conceived designs while trying to use unit tests with mocks to achieve that.
On ne peut pas partir d'une architecture dite "à 3 niveaux" et utiliser une approche dirigée par les mocks. Faire cela, c'est nier l'intérêt principal des mocks qui consiste à découvrir les interactions entre divers composants d'un système en commençant par concevoir l'un d'entre eux.

James Shore annonce en avertissement I'm Not a Mockist mais alors pourquoi s'entêter à présenter une approche qu'il ne maitrise pas ?
Pour apprendre ? Cela serait tout à son honneur mais encore faudrait-il répondre aux commentaires qui remettent les choses dans la bonne voie - ce qui n'a pas du tout été le cas.

Et comme une cerise sur le gateau, un des premiers commentaires à ce billet est de Ron Jeffries : This is good stuff I hope to see the inevitable responses live up to this standard.. Ron Jeffries admet toutefois qu'il ne maitrise pas le sujet des mocks et qu'il cherche à comprendre ce que ça lui apporterait de plus que ce qu'il a déjà. Mais alors pourquoi donne-t-il un avis peu éclairé sur cette solution ?

Je ne sais pas trop que penser de tout ça. Ce billet de James Shore traite de pratiques de développement que je commence, je pense, à bien maitriser et je peux donc voir toute l'incongruité de ce qu'il raconte. Mais qu'en est-il pour les autres sujets ? Comment accorder de la crédibilité à une explication, à un point de vue, venant de personnes qui peuvent, on s'en rend compte, ne connaitre que très imparfaitement ce dont ils parlent avec assurance ?
Je vois là une dérive de "l'agilité-business" où ceux qui sont censés savoir et apporter leurs connaissances peuvent rarement se permettre de montrer leur ignorance sur certains domaines, alors que le courage et l'honnêteté nécessaires à la pratique des méthodes agiles devrait leur dicter la démarche opposée.
Mais c'est un autre (vaste) sujet...