J'ai récemment eu une discussion assez serrée avec un responsable de développement d'un grand compte de la finance qui soutient qu'il est préférable de se passer des design patterns, facteurs de complication, et qu'il vaut mieux miser sur la simplicité des développements.
On peut effectivement reprocher aux design patterns de conduire parfois à des logiciels surchargés en héritage, interfaces et autres factories. Les design patterns, quand ils ne sont pas nécessaires, ressemblent un peu à des fioritures inutiles ou à des figures de style pompeuses. La lisibilité du système, sa maintenance et son évolution sont alourdies par leur usage intensif et superflu, un peu comme les documents conçus par ceux qui découvrent la diversité des fontes et couleurs disponibles dans Word. Certains en ont d’ailleurs fait un anti-pattern baptisé "pattern oriented architecture".
Mais en y regardant de plus près, ce n’est pas directement les design patterns que ce responsable met en cause, mais leur raison d’être. Il sait que quand les fonctions d'un système s'accumulent et que le nombre de sous-systèmes augmente, l'ensemble, si on n'y prend garde, tend vers une complexité qui nuit au système lui-même. Mais pour lui, le remède consiste à choisir la solution la plus simple à chaque étape de conception et de développement. Implémenter simplement chaque fonctionnalité est une garantie suffisante pour que l’ensemble reste simple. Sans design pattern.
Dans le fond nous sommes d'accord : la simplicité est un objectif pertinent. Mais nous divergeons sur les moyens à mettre en oeuvre pour l'atteindre. Lui pense que mettre simplement un pied devant l'autre est suffisant, alors que je pense que cette image de la marche tranquille vers un système opérationnel est trompeuse. Il est plus réaliste de penser en termes de marais à contourner, de rivières à franchir, de gouffres à survoler… La simplicité n'est pas additive. Le chemin vers un système simple n'est généralement pas linéaire, il demande souvent des sauts qualitatifs (le refactoring) qui modifient profondément la structure du système.
Essayons quand même. Prenons une "simple" interface graphique (GUI) et connectons la à une "simple" base de donnée. Allons-y pas à pas, en ajoutant du code simplement quand on en a besoin, c'est à dire dans les handlers des évènements de la GUI : on obtient un code complexe parce que chaque handler devient un petit logiciel à lui tout seul, qui contient l'accès au SGBD, la logique de traitement et la gestion des éléments graphiques. Maintenir le tout requiert de découvrir et de comprendre ces mini programmes. Le coût de correction de bug et d'ajout de fonction est alourdi. Pour ne rien arranger le nombre ou la taille des mini programmes augmente plus vite que les fonctionnalités. Les interactions entre fonctions garantissent, sauf en cas de simple juxtaposition de fonctions, une combinatoire défavorable à l'approche "un pied devant l'autre". A un moment ou un autre, il nous faudra investir dans un moyen de nous sortir de là… et le plus tôt sera le moins cher.
Donc, autant investir dans le refactoring dès que nécessaire, par exemple en regroupant toutes les fonctions d'accès à la base de données au sien d'un objet dédié qui fait "façade" – on est déjà dans les design patterns…
Autrement dit les design patterns, loin d'apporter la complexité, sont des outils au service de la simplicité. Et, comme tous les outils, on les choisit en fonction du besoin, pas l'inverse ("Tiens, une scie à onglet électrique, c'est pas mal ça, voyons ce que je vais faire avec…").
Il faut effectivement simplifier dès que l'occasion se présente et les design patterns sont souvent un bon moyen.
Damon Carr a proposé une mesure de la complexité du design dans cet article : http://www.ironspeed.com/articles/Past%20the%20Point%20of%20Simplicity/Article.aspx
Il y décrit comment certains développements qui se disent "agiles" font en fait tout en n'importe quoi sous couvert d'une règle unique très mal interprétée "the simplest thing that could possibly work" et il y montre en quoi les design patterns sont un bon moyen pour réduire la complexité.
Rédigé par : Olivier | 09 mars 2006 à 00:15
"une discussion assez serrée avec un responsable de développement"
A quand le podcast ? :-)
Rédigé par : Olivier | 09 mars 2006 à 00:16
Entièrement d'accord. Le problème n'est pas tant l'utilisation des design patterns que leur mauvaise utilisation. Combien de fois ai-je vu des développeurs venant de découvrir un nouveau pattern chercher absolument à l'utiliser dans leur développement ? Alors même évidemment que le pattern en question n'était pas forcément le plus adapté. On tombe exactement dans l'exemple de la nouvelle scie à onglet électrique !
Euh et sinon, Denis, tu t'es mis au bricolage ou quoi ? :-)
Rédigé par : Jean-François | 09 mars 2006 à 17:02