Deux tendances dans la conception et le développement logiciel

C’est bien parce qu’il s’agit d’écritures– qui laissent des traces – que l’on peut reproduire et copier le code ou la documentation d’un programme. Une grande part des pratiques de développement peut se faire avec un effort minimum de conception : il s’agit de réutiliser ce qui marche, de faire du copier/coller, de reproduire des best practices, de suivre les tendances sur GitHub, etc.

Design by Puzzle

Dans ce cas là je parle de conception “puzzle” plutôt orientée de manière analytique, où l’on découpe le problème général en plusieurs petits problèmes qui sont alors plus facilement commensurables et compatibles avec ce qui peut avoir été déjà résolu par d’autres et ailleurs : on va faire son marché dans le catalogue des librairies, dans les repositories de code et sur Stackoverflow.

Design by Constraints

A cette première tendance pragmatique il faut rajouter une deuxième tendance qui, elle, s’inscrit dans une vision plus synthétique et plus générale qui définit des principes, explicite les contraintes du système et s’inscrit dans une perspective architecturale, puisque l’architecture est l’art d’agencer différents composants ensemble.

Composition de ces deux tendances

Là ou la tendance pragmatique œuvre en maître, c’est dans le pragmatisme qu’impose des situations d’immédiateté et d’urgence où il faut trouver rapidement une solution à un problème en cherchant la pièce de puzzle qui manque.

La tendance synthétique, qui conçoit par contraintes, cherche un point de vue systémique dans l’explicitation des principes généraux – des styles d’architectures si vous voulez ; cette tendance arrive à la fois après coup et en même temps a toujours une certaine longueur d’avance.

J’en veux pour exemple la thèse de Fielding qui :

• d’un côté arrive après coup, puisque qu’elle conceptualise après coup le travail qui avait été fait dans les spécifications de HTTP dans les années 90 ;
• d’un autre côté, elle a une longueur d’avance puisqu’il faudra attendre plusieurs années pour qu’elle devienne la référence qu’elle est encore aujourd’hui, 14 ans plus tard.

Ces deux tendances sont en permanence présentes dans les jeux d’écritures numériques. Il ne s’agit pas de dire que l’une est mieux que l’autre : un développeur peut être le matin dans une approche design by puzzle pour « switcher » l’après midi dans une démarche design by constraints.

Enfin, ces deux tendances ne sont pas implémentées dans les mêmes proportions selon les environnements techniques, les langages de développement et les communautés qui les font vivre : d’un côté on peut dire que PHP est un langage qui s’est développé massivement sur la base d’un design by puzzle avec des pratiques de copier/coller de code (sans forcément tout comprendre), et de l’autre des langages plus conceptuels embrassant beaucoup plus le design by constraints comme Scala ou Haskell.

Cette distinction génère de nombreuses polémiques entre les différentes communautés … mais aussi beaucoup d’humour :