Hum facile à dire. Quand on me parle de design simple, je pense automatiquement en terme de modèle du domaine et d'orienté objet. Effectivement, cette approche permet de concentrer la complexité du métier en un seul endroit, et de la représenter avec un outil puissant, l'objet, qui permet de traduire pratiquement directement le métier.
Cependant, nous avons été amenés dans l'équipe dans laquelle j'évolue à aller interroger une équipe voisine sur leur application pour la mise en place d'une interface.
Cette équipe, bien que "développant" en .NET, ne connait d'orienté objet que le nom, et suis donc une une approche très rad où l'application web se contente de faire des appels aux procédures stockées. Implicitement donc, la base tente tant bien que mal de garder le métier à travers son MCD et ses procédures.
Je pense que la première version de leur application devait posséder un mcd relativement propre, tentant de représenter correctement les données, et j'imagine que les packages de procédures devaient également suivre une certaine logique.
Je ne sais pas comment ils en sont arrivés là, mais actuellement l'application est apparemment un assemblage complexe de différentes notions imbriquées au petit bonheur la chance avec du métier éclaté un peu partout. Il semblerait également que les développeurs eux-mêmes ne connaissent plus leur application et ne soient plus sur du tout du contenu de leurs différentes tables.

La grande question est donc, comment en sont-ils arrivés là? Difficile de trouver une réponse toute faite, mais je pense que la première réponse est la peur.

Devant une demande de modification plus ou moins importante, et devant la relative lourdeur que demande une modification de table ou de structure, j'imagine qu'à chaque fois ils ont choisi la solution du "hack". Pourquoi est-ce de la peur? Parce qu'ils savaient sans doute très bien que le "hack" rendrait l'application moins maintenable, mais que bon, "ça va c'est pas grand chose, et de toute manière ça prendrait trop de temps de modifier la base correctement". Ici c'est donc bien un manque de courage devant la seule action envisageable: le refactoring. Le courage étant l'action face à la peur, voilà pourquoi je pense qu'une partie du problème vient de la peur. La peur d'entamer une modification lourde aux impactes difficiles à mesurer. Finalement, on parle ici de la sempiternelle peur du changement.

Effectivement, je pense qu'une base de données accepte assez mal le refactoring, et accepte à priori encore moins bien les tests unitaires nécessaires à garantir un bon refactoring; cependant il n'en reste pas moins qu'accepter le changement dans son processus de développement est le premier pas vers l'agilité. Une fois qu'on s'est rendu compte que le changement est inéluctable, plutôt que de lutter contre lui et de mal l'intégrer, on met en place des pratiques qui font tout pour faciliter son intégration. Les tests unitaires, l'intégration continue, la conception incrémentale sont autant de pratique qui ont pour but de faciliter le changement.


En passant à côté du courage de refactoriser, ils sont sans doute passés à côté d'une autre notion importante: garder le design simple. Effectivement, si le design se complexifie de plus en plus, alors l'application est de moins en moins maintenable. Et c'est effectivement leur cas puisque le programme est devenu est ensemble de cas particuliers gérés à droite à gauche.
C'est un cercle vicieux qui se met en place, car moins l'application est maintenable, mois elle est propice à accepter un refactoring constant, et moins elle est refactorisable, moins on pourra garder sa simplicité.

Le 3eme problème que je vois est je pense, purement humain, puisque qu'il s'agit d'un problème de finesse d'analyse. Eric Evans en parle dans son livre, Domain Driven Design: a savoir que garder le design simple tout au long de la vie du projet demande de la part des développeurs une très bonne finesse d'analyse. Je ne pense pas seulement à l'objet ici, mais en terme de base de données. L'application dont je parle depuis le début de ce message est entièrement basée sur son MCD, mais comme lui même est très bancal, l'application l'est aussi.

Il y aurait sans doute d'autres raisons à évoquer, mais je vais m'arrêter là pour le moment. Je vous rassure au fait sur mon ego: je me pose la question tous les jours de savoir si ma finesse d'analyse est suffisante.