Quel est la vraie question d’architecture ?
Voulez-vous quelque chose de simple, évolutif, pas cher
ou
quelque chose d’abstrait, très cher et peu évolutif ?
C’est une question récurrente en informatique depuis de très nombreuses années.
La volonté de faire abstrait chez certain, frise la folie : des abstractions d’IHM qui accèdent a des abstractions de services via des protocoles abstraits ou tout est meta défini dans des classes qui sont instanciés a partir de ‘factories’ et qui vont trouver les noms des classes dans des fichiers de configuration … bref pour 100 lignes de codes, 3 sont des codes avec une utilité métier et ils est difficile de retrouver les lignes utiles. La maintenance devient difficile car des centaines de fichiers de code ou paramétrage sont impactés.
Toute ressemblance avec des projets java serait purement fortuite de ma part …
Les arguments évoqués sont que c’est plus évolutif car on peut changer un protocole sans toucher l’application, … mais a quel prix ?
Revenons sur des objectifs de départs pour des applications :
·
- Etre misent en œuvre rapidement
- Pouvoir évoluer rapidement
- Ne pas couter cher
Le nombre d’abstraction est un faux problème, les programmes qui peuvent évoluer le plus facilement sont les plus simples. S’ils sont vraiment simple, ils peuvent même être réécris.
Ce débat est visible dans les incompréhensions REST versus SOAP. Pendant que REST fait du simple et efficace, d’autres font des abstractions inutiles (qui utilise le fait que SOAP peut fonctionner au dessus de SMTP ou http ?).
L’histoire informatique montre que les abstractions finissent par disparaitre pour utiliser les technologies gagnantes. Par exemple Windows avait faire des API permettant de faire du TCP/IP, Ipx, … Qui s’en souvient ? qui a encore idée d’utiliser ces API ?
La limite de l’approche par l’abstraction est que l’on peut faire a un instant T une abstraction de SNA. Pas de chance quand TCP/Ip arrive les concepts sont différents. L’abstraction pour être utile nécessite si on ne veut pas changer l’application de faire rentrer tcp/ip dans les concepts de SNA (déclaration des liens a priori …). Bref on ne bénéficie pas des avancées technologiques.
Ne dites pas que c’est évident, combien on fait des API d’abstraction de Mqseries, réseau, base de données en tous genres au dessus d’API abstraite (pour changer d’abstraction plus facilement…) …
Je suis sur que dans 99% des cas l’application a été changée sans que toutes cas abstractions aient été modifiées.
Cela revient bien a dire que l’essentiel du temps de développement des applications n’est pas du temps consacré a du code utile ou métier aujourd’hui ni demain.
C’est d’ailleurs bien ce que l’on observe sur Internet. Certains sites sont refait entièrement plusieurs fois pendant que d’autres n’ont pas mis en production leur application.
Amazon refaisait son SI tous les 2 ou 3 ans de mémoire ….
Une autre forme du débat vient du nombre de couches imposées 2, 3, 4 parfois 5. Est-ce bien utile de traverser 5 couches pour consulter un code TVA mis simplement dans une table ? Est-ce bien raisonnable ? Pourquoi ne pas rester au n tiers, n variant en fonction des besoins ?
Le vrai progrès en architecture sera quand on cherchera a faire simple, quand on se demandera ‘peut-on faire plus simple ?’ et non pas plus abstrait.
