Le logiciel d'un développeur est son château

Quatrième billet de la série sur la conception de logiciels[1]

Je n'ai pas encore abordé la question des éléments tiers dans la réalisation d'un logiciel.
Il y a une bonne raison à cela : je crois fermement que c'est un point de détail qui ne mérite pas une place trop importante.

Quand on discute sur les méthodes agiles et sur la capacité de pouvoir remettre en cause à tout moment le comportement de l'existant pour satisfaire au besoin le plus prioritaire d'un produit logiciel, il y a toujours quelqu'un pour dire "Oui on peut faire des changements mais il y a quand même des choix d'architecture que l'on ne peut pas facilement modifier". Et bien souvent il y a quelqu'un pour rajouter "c'est pourquoi il faut définir l'architecture dans la première itération". Il m'est arrivé plusieurs fois d'entendre cela et je ne partage pas du tout cet avis.

Cette divergence de points de vue est simple à comprendre : tout le monde ne met pas la même chose derrière le mot "architecture".

Choisir un SGBDR X ou Y ou choisir un stockage "NoSQL", ce n'est pas faire un choix d'architecture, c'est faire le choix des détails d'un mécanisme de persistance.
Choisir un framework web Y ou Z, ce n'est pas faire un choix d'architecture, c'est faire le choix des détails d'un mécanisme de diffusion de données.

Comme le dit l'académie française[2], l'architecture, c'est la disposition, l'ordonnance d'un édifice. Les choix d'architecture doivent représenter ce qui est fondamental -et rien d'autre- dans un logiciel, ce qui constitue sa nature, des choses telles que la modélisation du domaine métier ou la formalisation des principales opérations réalisées par le logiciel.
Cette approche permet de garantir un point essentiel de l'architecture : sa stabilité. Sous certaines conditions, cette stabilité ne remet pas en cause la capacité à modifier un comportement et elle offre la possibilité de changer de mécanisme de persistance ou de diffusion à tout moment dans la (longue) vie du logiciel.

Une des conditions est que les concepts d'architecture ne doivent pas dépendre de logiciels tiers. Bien evidemment la suppression de toutes les dépendances est impossible : si les concepts d'architecture sont exprimés dans un langage informatique, ils dépendent, au minimum, de la syntaxe de ce langage et d'un interpréteur/compilateur/runtime associé. Idéalement, il ne devrait y avoir aucune autre dépendance.

En résumé, un logiciel est à son développeur ce que sa maison est à un anglais : son château, c'est à dire un endroit où il n'a pas à subir les invasions de logiciels tiers et de leurs hordes de contraintes.

Si tout cela est acquis, seuls les concepts et les détails d'implémentation dépendent des logiciels tiers (représentés en vert dans le schema qui suit).
La dépendance à un tiers donné se limite alors à un élément précis et ne s'éparpille pas dans tous les détails du logiciel. Les concepts d'implémentation peuvent centraliser ces dépendances le cas échéant.

4x01.png

Voilà réglée de manière un peu radicale la question des tiers.
Il va sans dire que certaines pratiques désormais courantes, telles que prendre un framework tiers pour constituer l'ossature d'un logiciel, me font hurler...

Le prochain billet abordera un sujet connexe : le cas des GROS logiciels et de leur possible décomposition...

Notes

[1] Les trois premiers billets sont là : Conception logicielle ; Le logiciel, un organisme multicellulaire ? et Chacun cherche son TDD.

[2] cf premier billet de la série : Conception logicielle