“- il n’y a pas eu d’architecte ou très peu dans ces projets et il n’y a pas de ‘separation of concern’ entre les couches d’architecture (codage dans le click() ou …”

Probablement un des plus grands dangers du client serveur (un de ceux qui m’ont conduit à défendre la mise en place de la fonction architecte – il y a en a bien d’autres ;-)).

Je profite de cette réponse pour appuyer sur le fait que mon “interpellation” ne vise pas à remettre Java en cause, mais à poser la question des moyens complémentaires au langage, qui peuvent être souhaitables pour améliorer le respect des délais de livraison, que ce soit dans la phase de développement initiale ou plus tard dans la phase de maintenance.
Et en n’oubliant pas le “cauchemar ” des déploiements.

De mon point de vue l’argument, “le développement ne représente qu’une petite partie du TCO”, peu contestable, occulte trop systématiquement la problématique du “time to market”.

Pour ma part j’ai commencé ma carrière sur client serveur (Powerbuilder, Oracle Forms) puis j’ai migré vers Java et Java JEE.

Mainenant que mon rôle consiste à moderniser des patrimoines anciens je peux vous assurer qu’une application ayant vécu plus de 15 ans est toujours dans un etat de fraicheur limité quelque soit son language de programmation d’origine (cobol, java, client serveur).

La différence de productivité n’est pas le véritable coût de possession des applications, le véritable coût provient de la dégradation progressive du pzatrimoine logiciel.

Celui ci provient toujours des facteurs suivants:
– developper en ayant mal conçu: pas de phase de conception donc plus rapide, mal conçu mais rapidmeent fait, pas de documentation
– budget limité: a défaut d’avoir le budget pour bien construire j’ajuste sur le coût des matériaux (qualité des ressources humaines par exemple)
– 50% des projets échoue il ne sert à rien de faire de la qualité, faisons vite

Dans le cadre de Java un élément est venu se greffer en plus, il s’agit de la très/trop grande variété de framework concurents qui font les mêmes choses. La variation des standards est par nature l’opposé de l’industrialisation. Or être productif n’a de sens par pour soi même mais pour le développeur qui passe après.

Il faut donc maitriser une approche industrielle et se servir de ce standard pour approter de la productivité.

Le client serveur force cette démarche car elle défini le cadre de travail: l’IDE et les APIs propriétaires de l’outil. Donc cette partie la est stable et apporte productivite.

Cependant l’histoire nous prouve, et je le vis au quotidien quand nos clients nous demande de réécrire telle ou telle application client serveur, que ce bénéfice a été mal exploité malheureusement.

En effet l’architecture étant imposée et “facile” d’accès, il s’est passé les choses suivantes:
– puisque c’est facile je peux mettre des ressource de profil plus aisé à recruter et moins cher => le code n’est pas structuré et difficile à maintenir
– il n’y a pas eu d’architecte ou très peu dans ces projets et il n’y a pas de ‘separation of concern’ entre les couches d’architecture (codage dans le click() ou lien de la mise en plance d’event handler centraux et de gestion d’évènement)
– l’IDE fait tout, je n’ai pas besoin de documentation

Dans le développement, comme dans tout autre domaine industriel il faut raisonner sur la durée de vie du produit manufacturé:
– cout de mise en place des outils de fabrication et de formation des ingénieurs
– cout de fabrication
– cout de maintenance sur la durée de vie (20 ans minimum) incluent les changement technologiques tels que les montées de versiob Powerbuilder ou Java et le besoin de formation constante
– cout de démentellement

Les deux première étapes ne représentent même pas 10% du cout global (etude gartner), il s’agit donc de gagner sur la durée et pas au décollage.

Dans notre approche nous avons donc créé un outil qui compile la modélisation d’un logiciel pour le générer intègralement sans dépendre de la cible d’architecture, et faisons l’inverse pour réécrir des système anciens.

10 années d’expérience nous ammènent à constater une amélioration mias cela reste un outil. Il faut quand même maitnenir le niveau de compétence nécessaire et justifier les budgets qui vont avec.