Agilité, modélisation et méta-programmation

Je ne sais pas si c'est dû au cycle lunaire ou à quelque chose du même genre mais j'observe une floraison de billets "polémiques" sur les blogs traitant de méthodes agiles. Là, il s'agit de l'éternelle méfiance des agilistes envers les phases trop grosses de modélisation (le Big Design Up Front comme on dit) et, par extension, envers les approches de "développement piloté par les modèles".

Emmanuel Chenu écrit 2 billets pour réagir à un article de "Programmez!" et confronter l'agilité avec le pilotage par les modèles. Le touilleur express en rajoute une couche sur les promesses de maintenance facilitée par ces approches.

Il ne faut pas être trop sévère avec ces approches. Faire des boites et des flèches à la place d'écrire du texte ne serait pas mauvais en soi si l'on avait des moyens de le faire incrémentalement et en étant piloté par des tests (là je fais de la spéculation).

Ce qui bloque vraiment dans cette démarche, à mon avis, c'est quand on se met à considérer tout ça comme de l'outillage qui va générer du code sur lequel on va (éventuellement) intervenir manuellement. Il y a toujours cette ambiguïté entre conception et code qui déforme la vision de ce qu'est le développement logiciel. On ne le répètera jamais assez : "The source code is the design". Le code, c'est la conception, et on ne génère pas une conception : on la conçoit !!!
Le code généré doit être considéré comme du langage machine généré par un compilateur. Le modifier n'est pas une option acceptable car on ouvre alors une brèche sur un gros paquet de problèmes : la lisibilité de l'intention du développeur, la duplication des référentiels et la robustesse de la chaîne de conception.

Si toutes les conditions étaient acquises et si les outils étaient au rendez-vous, il faudrait peut être reconsidérer la chose. Mais la vraie question qui devrait être posée dans un tel contexte, c'est "est-ce que je ne peux pas faire la même chose avec des approches bien plus naturelles pour un développeur et permettant une expression plus riche ?"

Les modèles et les diagrammes, c'est sympa pour montrer des ébauches ou pour avoir une vision de haut-niveau forcément partielle. Quand il s'agit de concevoir réellement une application avec précision, quand il s'agit de raconter des histoires dans le détail, rien ne vaut l'alphabet et le texte.

Il y a environ 10 ans (le temps passe...), je travaillais sur un projet où l'on avait fait le choix de modéliser la majorité de l'application en UML avec Rational Rose et de générer le C++ qui pouvait l'être (je n'étais d'ailleurs pas étranger à cette direction). J'avais écrit un add-in afin d'avoir une génération suffisamment "intelligente". Elle était basée sur un ensemble de stéréotypes UML qu'il suffisait d'attacher à chaque classe pour lui adosser une certaine interface ou un certain comportement.

Mais c'était il y a fort longtemps. Plus tard, j'ai découvert le "modern C++" d'Andrei Alexandrescu et le Policy based design et je me suis dit qu'un grand nombre des bénéfices de la génération de code étaient en fait à la portée du langage lui-même.

Enfin, j'ai découvert toutes les techniques "récentes" de méta-programmation, la programmation orientée aspects, et tout ce que l'on peut faire avec les attributs de C# ou les annotations de Java.
Et là je suis définitivement convaincu : dessiner à la main des boites et des flèches, que ce soit avec un crayon ou avec une souris, c'est vraiment très rudimentaire quand on a sous la main tout ce qu'il faut pour exprimer la même chose de manière bien plus concise à l'intérieur du langage lui-même.

Je sais bien que je fais là un raccourci un peu facile. Des puristes pourront même, par exemple, objecter que des croisements existent entre les approches puisque l'on en vient à évoquer la modélisation orientée aspects. Mais tout ça reste encore très académique, au sens où cela n'est pas prêt de rejoindre le quotidien de la masse des développeurs.

Mon principal sentiment vis à vis des techniques actuelles qui vont au delà de l'écriture de code au kilomètre, c'est qu'il y a plusieurs approches pour exprimer des conceptions de manière plus synthétique, des conceptions de "plus haut niveau" pourrait-on dire.
Les approches purement textuelles et intimement liées au langage de développement, grace à leur référenciel unique (le code source), leur lisibilité (le code source est le langage "maternel" du développeur) et leur testabilité (c'est du code donc ça se teste comme le reste du code) me paraissent plus aptes à favoriser l'agilité.