Dans un article paru après la publication par Microsoft de la spécifications de ses formats binaires, Joel Spolsky vitupère et explique pourquoi ces formats sont si compliqués et nécessitent autant de travail pour être réutiliser en dehors des applications MS Office Il donne aussi quelques pistes de réflexions pour s'accomoder sans trop de douleur de ces formats pour des tâches simples.

En lisant l'article, je me suis dis qu'il n'y a rien de nouveau sous le soleil. Les mêmes causes produisent les mêmes effets dans notre domaine. Généralement, les logiciels ayant un tant soit peu de succès sont construit année après année, et même dans le monde open-source, en essayant de minimiser les efforts nécessaires: cela implique que le temps passé à prévoir l'avenir et donc à concevoir une architecture ou un logiciel très modulaire, et très facile à modifier et à comprendre, reste minimal. J'ai entendu pas mal de personnes s'écrier "Haaa ! Quel horreur !" ou "Mais pourquoi ont-ils fait comme ça ?!!" en lisant le code (ou le schéma d'architecture, ou le schéma de bases de données) d'une application qu'ils devaient modifier. Je peux même dire que j'en ai sans doute fait partie pendant un temps.

Seulement, l'histoire démontre qu'il y a toujours une bonne raison pour une complexité qui s'est amassée au fil du temps. Souvent, c'est le manque de temps pour refaire les choses (parce qu'il y a la pression du business qui préfère avoir un produit ayant du succès demain plutôt qu'un produit facilement modifiable ayant du succès dans 6 mois). Il arrive que le problème est de rester compatible avec d'anciennes versions du logiciel. Le problème des "legacy applications" qui permettent de continuer à gagner de l'argent, pendant que l'équipe produit essaie de réinventer le monde.

Et une des solutions explicitée par Joel Spolsky dans son article peut s'adapter (conceptuellement) à nos problèmes d'architecture. Il s'agit simplement d'isoler le composant qui nous pose problème derrière un web service, comme l'on peut travailler sur un fichier Excel ou Word en scriptant une machine tournant sous Windows, ce qui permet de travailler sur ce qui est vraiment important (les nouvelles fonctionnalités, bien sûr). Cette technique peut-être utilisée avec des bibliothèques que vous ne pouvez pas mettre à jour (parce que vous ne vulez pas payer ou parce que le fournisseur a disparu) ou avec une base de données et de la business logique implémentés dans une techno dont vou voulez vous séparer. L'isolation a souvent comme intéressante conséquence de vous permettre d'améliorer la scalabilité de cette partie de l'application.

Rien de bien nouveau sous le soleil, mais simplement quelques réflexes qui permettent de gagner du temps et de se concentrer sur ce qui est prioritaire.