Mauvaises conception de la conception

Mon exposé sur les pratiques Agiles liées à la conception a été très bien accueilli à Reykjavik, dont je suis revenu hier très fatigué mais aussi très content.

Mon principal objectif était de faire le lien entre les connaissances accumulées depuis quelques décennies sur les biais cognitifs et l'activité de conception ou "design". J'y ai déjà fait allusion dans mes billets précédents évoquant la danseuse et les bugs du cerveau.

Le point sur la conception

Cet exposé était aussi l'occasion de faire le point sur ce qu'ont été les apports du mouvement Agile au discours sur la conception.

Le terme anglais "design" est très surchargé, que ce soit dans la vie courante (une brosse à dents ou un siège peuvent "être design", c'est une discipline artistique mais aussi industrielle) ou dans le champ professionnel du logiciel, où il peut suggérer aussi bien l'ergonomie (product design, interaction design), l'esthétique (graphic design), la représentation de l'information (information design), ou enfin la conception logicielle à proprement parler.

La terminologie francophone laisse peut-être légèrement moins de place à l'ambiguité, quand on parle de "conception" ce sont le plus souvent les programmeurs qui se sentent concernés.

Avis de décès?

En 2000 paraissait un article important de Martin Fowler, intitulé "Is Design Dead?". A l'époque on ne connaissait que peu Scrum, le "buzz" se concentrait autour d'Extreme Programming et ni l'un ni l'autre de ces discours n'était encore appelé "Agile" - ce n'est qu'à partir de 2001 que le terme issu de la rencontre de Snowbird sera adopté.

On sortait d'une période qui avait vu UML triompher après un long et intense débat sur les notations formelles graphiques, bien illustré dans ce dessin. Pour une grande partie de la profession, "UML" et "conception logicielle" étaient devenus des synonymes.

Fowler relevait l'une des principales critiques à l'égard d'Extreme Programming, auquel on reprochait d'être "centré sur le code". Et de constater le rejet par Extreme Programming non seulement d'UML mais de plusieurs dogmes tout aussi fortement associés à l'idée de conception: le principe d'une "phase de conception" venant en amont de la phase de programmation, celui d'organiser le développement autour de "frameworks" ou de "patrons de conception".

Pour certains, selon Fowler, Extreme Programming semblait vouloir en finir avec la conception. Martin Fowler était en bonne position pour arbitrer ce débat: il était non seulement le co-auteur d'un bréviaire sur UML qui avait connu des ventes record, mais également d'un livre sur le "refactoring" connu comme l'une des pratiques clés d'Extreme Programming, et considéré commel'une des figures tutélaires de cette mouvance.

Non, concluait Fowler, Extreme Programming n'appellait pas à la mort de la conception ni n'annonçait son décès; et Fowler d'attester, en analysant de près les recommandations effectivement émises par Extreme Programming, que la conception y restait une préoccupation majeure, et que ses critiques avaient eu une vision caricaturale de la conception.

Trois mises au point sur la conception

Extreme Programming, et à sa suite le mouvement Agile, ont ainsi permis de rectifier, ou de commencer à rectifier, un certain nombre d'idées fausses sur la conception, et trois exemples me paraissent particulièrement importants.

La conception n'implique pas nécessairement une notation formelle qui s'exprime visuellement. Cette idée a longtemps été le cheval de bataille des tenants d'UML, et le triomphe d'UML au tournant de l'an 2000 était partiellement le triomphe de cette idée. Par un raccourci de pensée jamais justifié "visuel" était présenté comme synonyme de "supérieur": parce que UML permettait de modéliser visuellement, il était un meilleur véhicule pour parler de conception. Corollairement, le code source lui-même, n'étant que textuel, ne pouvait pas être un support approprié pour exprimer des notions de conception.

Le succès des approches Agiles a contribué à remettre les pendules à l'heure. Toutes les modalités d'expression - visuelles, textuelles, ou autres - ont leur place pour parler de conception. La question est moins de savoir comment représenter le résultat des activités de conception, mais plutôt de savoir qui doit y participer, et par conséquent où elles doivent se dérouler. L'approche privilégiée par les équipes agiles est celle de la "modélisation agile" ou des "sessions rapides de conception": cela se passe au tableau blanc, on doit impliquer les développeurs chargés de la réalisation, et s'il faut conserver une trace permanente une photo du tableau suffit largement.

La conception n'est pas nécessairement une activité qui précède la programmation. Avec UML c'est aussi une approche en phases du projet de développement logiciel qui prévaut. L'accent a été mis sur des outils permettant aux architectes de réaliser un document de conception détaillé en amont du développement, et (comme on dit alors) de le "balancer par-dessus le mur" aux programmeurs qui doivent en suivre les recommandations. C'est une vision caricaturale et inefficace des activités de conception qui n'a que peu de rapport avec la réalité du terrain.

La démonstration en est faite par Fowler lui-même dans son ouvrage sur le Refactoring, dont le sous-titre est "améliorer la conception d'un code existant". C'est un travail rigoureux, argumenté, basé sur un travail de thèse doctorale, celle de Bill Opdyke; il amène Fowler à prédire, et l'avenir lui donnera raison, l'intégration du refactoring automatisé dans les éditions futures des outils de développement.

La conception est une activité collective, pas exclusivement individuelle. Le discours sur la conception est dominé par la description de principes, d'heuristiques, de règles. Grammaticalement, la forme la plus usitée est celle de l'impératif: "évitez les classes contenant un trop grand nombre de méthodes publiques". On n'y prend presque pas garde mais une hypothèse, implicite et jamais remise en question, sous-tend la quasi totalité de ce discours: il s'adresse à une seule personne (Le Concepteur), travaillant de manière isolée. Elle se confirme facilement en examinant des sites d'entraide du type StackOverflow: les questions sont systématiquement de la forme "Comment dois-je m'y prendre pour..."

L'approche Agile suggère une autre démarche, dans laquelle le "nous", le collectif, l'équipe prennent le pas sur l'individu. La question n'est plus "quelle est la bonne conception dans cette situation", mais "sur quelle conception pouvons-nous être d'accord". Non pas "quel principe de conception prévaut", mais "quels critères nous permettent de décider entre deux propositions individuelles (ou mieux encore en faire la synthèse)".

L'enjeu de la conception n'est pas, d'une façon un peu scolaire, de donner individuellement la réponse correcte; il est pragmatique et économique, et consiste à générer plusieurs propositions et décider, entre ces diverses alternatives, laquelle offre les conséquences les plus désirables pour le projet. Cette décision engage la responsabilité de chacune des personnes qui devront ensuite assurer la maintenance du code, elle est donc une négotiation collective... sans pour autant être nécessairement égalitaire: les compétences en matière de conception ne seront que rarement partagées dans l'équipe de façon homogène.

Changer de point de vue

Sur ces trois points au moins, le discours Agile a contribué à chasser les images d'Epinal de la conception et rétablir une perception plus juste de cette activité. Reste que ces trois erreurs avaient à mon sens une origine commune, l'erreur de projection que je dénonçais dans un précédent billet: et malheureusement, y compris au sein de la communauté Agile, nous continuons à commettre cette erreur en parlant exclusivement de propriétés du code telles la duplication, la complexité, les heuristiques SOLID, les métriques de conception, etc.

Tout comme la dette technique, la conception, bonne ou mauvaise, n'est pas exclusivement une propriété du code source (ou des documents et autres artefacts qui l'entourent), et se focaliser sur les produits de l'activité de développement, c'est faire l'impasse sur la moitié de la question: le fonctionnement cognitif humain et ses limites.