Pourquoi la génération automatique de code

La génération automatique de code a souvent une mauvaise réputation. Open Lowcode l’utilise massivement. Cet article explique son intérêt, et comment les effets pervers sont contenus.

Open Lowcode propose à l’utilisateur de définir son modèle de données étendu, le modèle métier: les objets et les propriétés attachées. L’outillage génère ensuite les objets d’accès aux données, les actions et pages standards pour le modèle métier. Tout le contenu spécifique, les pages et les actions définies par les utilisateurs, doivent étendre une classe abstraite qui est aussi générée. Tout le comme est généré en java, le langage de Open Lowcode.

Après plusieurs années d’utilisation, cette technologie de génération de source automatique est clairement un bénéfice, même s’il y a quelques pièges.

Le code généré est probablement légèrement plus rapide qu’une solution utilisant des approches différentes, telles que la réflexion¹. Le code est en tout cas beaucoup plus rapide que l’interprétation d’un langage de script, et une application générée avec Open Lowcode est au moins aussi simple à développer : Elle supprime les portions ennuyeuses du développement dans les langages fortement typés ²tels que java. Une meilleure performance vous permet d’utiliser du matériel moins coûteux, ce qui est d’autant plus visible dans un environnement cloud, et cela réduit l’impact environnemental, pas du tout négligeable, de l’informatique.

L’approche de génération de code apporte une plus-value incontestable dans la maintenance des applications. Quand on réalise un nouveau développement, si le code généré ne compile pas, c’est tout de suite visible, et particulièrement si l’application est la plus typée possible. C’est encore plus vrai quand on change le modèle métier : le code « manuel » à modifier est immédiatement visible par des erreurs de compilation. Dans un nombre très important de situations, on se retrouve dans la situation idéale où « si cela compile, cela marche ».

Quand on rencontre des erreurs sur un serveur en production, le code généré produit un log très précis sur le contexte de l’erreur. Cela rend l’analyse plus facile par un facteur 10 ou 100 comparé à une technologie qui renvoie des informations plus vagues. Comme la complexité du modèle métier est limitée, le code généré est lisible, contrairement, par exemple, au html généré parfois par des outils automatiques.

La génération automatique de code permet aussi d’avoir des interfaces très agréables, pour rendre l’écriture de logique métier spécifique aussi intuitive que possible. Cela permet à des développeurs débutants, ou des experts métiers pratiquant la programmation comme un hobby, de développer sur la technologie.

Cela a un avantage particulier en java, où le code généré permet de contourner les limitations des génériques, une fonction avancée de java permettant de définir des types complexes. Cette fonction est très utile, mais supporte mal certains cas. Leur gestion est supportée par le code généré automatiquement. On pourrait rétorquer que c’est juste contourner les limites de java, et qu’il serait préférable de changer de langage. Open Lowcode utilise java car c’est une technologie robuste et mature sur laquelle il est adapté de construire des applications qui auront de 5 à 20 ans de durée de vie, et il n’y a pas vraiment d’alternative.

Il y a des inconvénients à la génération de source. Le développement est un processus en plusieurs phases où l’on définit le modèle, génère et compile les classes automatiques ,et, ensuite, on peut créer ou mettre à jour les développements spécifiques, compiler le tout, et, enfin, le déployer. Ce n’est pas aussi simple qu’un éditeur visuel de type « WISIWIG ». Mais les bénéfices de cette approche compensent largement cette lourdeur. La séparation en différentes phases peut aider aussi à mieux structurer le travail en différentes phases (architecture, développement, déploiement).

Un autre inconvénient est le nombre de classes générées, typiquement quelques centaines pour une application de taille moyenne. Ce n’est pas vraiment beau, mais pas un problème majeur.

Le défaut majeur rencontré est la tendance à devenir paresseux avec la qualité du code généré. Il est facile de générer du code long et sale qui fonctionne, alors qu’il aurait été possible de mieux modulariser le développement, et de développer des fonctions d’aide plus génériques. Ce défaut n’est pas mortel, puisqu’il est très facile de refactoriser le code généré, et de l’améliorer même après l’entrée en service.

1. La réflexion est une technologie en java où l’on peut scripter l’accès aux objets, en contournant complètement les contrôles à la compilation. Open Lowcode utilise au minimum cette technologie (Il y a un cas d’utilisation sur plusieurs dizaines de milliers de lignes de code).
2. Le typage fort est le fait de définir de façon aussi précise que possible le type d’un objet et d’éviter les structures génériques. Par exemple, si l’on veut traiter de « factures », on crée un objet facture plutôt que d’utiliser un « objet générique qui peut contenir des données variables.