Quel avenir pour les outils de génération de code ?

Tout le monde a expérimenté le générateur basique ala Word 2000 tentant de rendre quelque chose de visuellement appréciable en HTML sans se soucier de la taille du fichier créé, un tout petit exemple se transformant en un code lourd et incompréhensible. Cependant, ce genre d'outil évolue.

- On parle maintenant régulièrement des outils de mapping objet/relationnel, certains citant autant que 300 000 lignes de codes faites grâce à ce genre d'outil.
- L'autre catégorie importante est bien sûr la gestion bidirectionnelle de code UML/Langage.

De manière générale, peut-on envisager dans un proche future que les outils de génération de code se suffisent à eux-même dans leur domaine, je veux dire par là produisent 99% du code ou des applicatifs de la même manière que 99% des applicatifs ne sont plus faits en assembleur ?
Et de manière encore plus générale, que l'on ne travaille plus qu'à partir de modèles ?
Et si non, dans quelle mesure ?

Plus particulièrement,
Quels expériences avez vous eu avec ce genre d'outil ?
Quelles sont les limites et les avantages actuels de ces outils ?
Ces limites sont elles surmontables ?
par exemple :
- il y a une conférence Borland dans un mois (le 10 et 11 décembre 2003) dont l'un des sujets est Performance des mappings objet-relationnel et qui traitera du problème de scalabilité de ce type de solution. Des expériences à ce sujet ?


Deux remarques :
- prière de ne citer que des outils vraiment professionnels.
- prière de ne pas troller avec des remarques (j'ai essayé c'est de la merde, vaut mieux tout programmer en vi dans la console au moins on sait ce qu'on fait)

[private] Avec ce sujet je sens que je vais encore m'enfoncer[/private]

A propos de la génération de HTML, les outils automatisés sont l'avenir. Quand on voit comment les nouvelles versions de Word généralisent l'utilisation des feuilles de styles, c'est clair qu'il sera rapidemment (si ce n'est déjà fait ?) en mesure de générer un document avec une séparation parfaite du contenu et de la présentation.

Les outils de génération de code objet à partir de l'uml ne sont pas de l'avenir, mais bien du présent. Mais seule une trame est générée, le plus gros du boulot reste à faire à la mimine.

Pour moi l'avenir du développement est dans la séparation (technologique) de la présentation, du traitement et du stockage :

• Le stockage est géré par les SGBDR depuis un bout de temps. Plus personne ne s'occupe de le coder, le développement s'apparente plus à du paramètrage.
• Pour la présentation on va vers une automatisation aussi complète. Cf les ASP.Net par exemple, dont la partie présentation n'est plus qu'une description mi-HTML mi-XML Voir aussi Sashipa-Melba (hé :P ) dont la présentation est un document XML (limitation actuelle : il ne permet aucun traitement).
• Le traitement n'est pas complètement automatisable, mais on peut créer des langages qui suppriment les répétitions (cas du foreach .Net qui remplace en simplifiant la boucle for dans la plupart des cas, ou du PHP qui masque l'utilisation des tables de hashage). Et surtout on va vers une architecture à composants partagés. Ce qui revient à dire : ok il y a besoin de la programmation mais si on encapsule toutes les fonctionnalités dont on a besoin, assez vite la programmation va s'apparenter à un jeu de légo. On y va avec les Web Services (W3C), les EJB (Java), le Remoting (.Net).

Pour en revenir à la génération de code :

:arrow: Tout ce qui est de l'ordre de la description (XML, HTML, SQL LDD) peut être mieux fait par un programme qu'un être humain (cas de la présentation et du stockage).
:arrow: En revanche, en ce qui concerne la programmation (cas du traitement) la tendance est de fournir des outils automatiques qui abattent la partie répétitive du boulot (ou des langages qui la supprime) mais il y aura toujours besoin d'un humain.

Thomas

je rejoint tout à fait ce que dis laffreuxthomas.

Je vais beaucoup m'appuyer sur des exemples de produits microsoft car ce sont les produits que je maitrise le mieux.

A propos de la génération du HTML, les outils vont s'améliorer, notamment en s'appuyant sur le XML. Office 2003 s'appuyant fortement sur le XML, on pourra enfin séparer clairement le fond de la forme, le fond s'appuyant sur un standard qu'est XML, la forme pouvvant être trés flexible grace à des xsl. Le code html qui en sortira sera forcément plus "propre".

Les outils de génération de code sont et seront de plus en plus performant, mais aussi de plus en plus complexe à paramètrer et à maitriser.

Je prend un exemple simple : Dreamweaver

Cet outil semble trés puissant, et est trés utilisé pour la génération de pages html. Mais cet outil est aussi trés complexe. J'ai déjà éssayé plusieurs fois de faire quelques pages html avec, et j'ai eu l'impression de perdre du temps, à maitriser et à paramètrer l'outil pour quelques opérations simples que j'aurais surement réalisé plus rapidement au bloc note.

Tous ça pour dire que ces outils de génération de code ont beau être performant, la formation à ces outils fait "perdre" pas mal de temp avant que l'on commence à gagner en productivité.

Pour ce qui est de l'analyse, conception et programation, des outils de plus en plus performants existent.

On a des outils trés performant au niveau de la modélisation, avec pas mal de tache automatisés comme la conception du squelette des classes à parttir d'un modèle UML et la création automatique d'une base en fonction du MCP. Ces outils permettent aussi de documenter son analyse au fur et à mesure et représentent un gain de temps non négligeable.

Au niveau de la génération des traitements, on commence à voir des nouveautées. Je prend l'exemple de olymars. Ce produit permet de générer toutes les procédures stockées usuelles à partir d'une base SQL-server. Mais il crée aussi des classes d'accés aux données et même des controles d'affichage personnalisés en .NET. A partir d'une simple base vide !!!!
Par contre, toujours le même problème : le paramètrage de olymars est un vrai casse tête, le produit à l'air trés puissant mais quand on le maitrise :?

Donc pour conclure, oui les produit de génération de code ne vont césser d'évoluer et permettre d'éviter certainnes taches répétitives. Le soucis sera que quoi qu'il arrive il faudra paramètrer l'outil qui génère le code.
outil simple à paramètrer :arrow: manque de flexibilitée ?
outil complexe à paramètrer :arrow: gain en productivité à étudier car si on passe plus de temps à paramètrer l'outil qu'a coder "à la mano" :?

Pour ceux qui comme moi découvrent petit à petit ces outils, en voici deux pour Delphi qui sont concurrents de ASP.Net et qui existent depuis un moment.
- Intraweb http://www.atozedsoftware.com/intraweb/
- Express Web Frameworkhttp://www.devexpress.com/ewf_overview.asp

Pour vous donnez envie de creuser :
Chad Z. Hower, a.k.a. "Kudzu" is the original author and project coordinator for Internet Direct (Indy)

Citation:

---

Which are the main advantages of IntraWeb to script languages like ASP, ColdFusion and PHP?

Hower: It's like comparing Dephi to Assembly. With those scripting languages you are constantly in the HTML and you need to understand the HTTP protocol, HTML, and many low level details. IntraWeb is like VCL for the "web platform". You just build your applications in a manner very similar to a normal Delphi application and IntraWeb does the rest. What Delphi did for the WinAPI, IntraWeb does for Web programming.

---

Bien sûr que tout le monde s'en fout des tailles de programme ou de fichier. Les ordinateurs gagnent chaque mois en puissance et les connexions haut-débit à l'internet se généralisent.
Cependant les RAD ont des limites et font du code imbitable lorsque l'on veut le faire évoluer. De plus, cela enferme le développeur avec l'outil générateur.

Un développeur est un peu comme un écrivain. Il a un style rien que dans le nommage des variables qu'il utilise. Reprendre le code de quelqu'un d'autre est parfois difficile alors un code généré par RAD.

Citation:

---

Envoyé par BiDouille_

Cependant les RAD ont des limites et font du code imbitable lorsque l'on veut le faire évoluer. De plus, cela enferme le développeur avec l'outil générateur.

---

C'est vrai sur certains outils, ça me fait penser notamment à VC++ qui génère des trames d'application qui sont à mon avis difficile à reprendre sous un autre EDI. Ceci n'est pas génant en soit (c'est pas plus mal que tous les développeurs d'une équipe s'habituent à une trame similaire), c'est un choix.

Je pense que les générateurs de code sont particulièrement intéressants quand le code généré n'est pas lié au générateur. C'est le cas pour les générateurs HTML, pour les générateurs PDF. Et en programmation : les générateurs de classes à partir d'un schéma UML, les environnements de développement visuel de Java (JBuilder etc..) et .Net (VS.Net etc..).

Le tout est de s'assurer qu'il y ait réellement indépendance entre le format du code généré et le générateur.