Il y a fort à parier que vous vous soyez déjà frotté à la pierre philosophale du développement logiciel : la génération automatique de code. Ça c’est une vraie bonne idée de manager moderne ! Un développeur, ça coûte des sous, ça geint, c’est lent, mais alors, vraiment, ça fait du code tout sale, qui colle aux doigts, qui marche moyennement d’ailleurs, de façon tellement médiocre qu’il doit aussi écrire des tests qui vont avec, tests qu’il va également falloir valider… Vous le voyez le serpent qui se mord la queue et qui coûte des sous ? Du code généré automatiquement, c’est trop mieux : pas besoin de tests en face, juste un bouton à appuyer et des milliers, voire des millions de lignes de code viendront remplir les disques durs automagiquement ! Le code généré a forcément raison : s’il y a malgré tout un bogue, ce sont les entrées du générateur qui sont moisies (modèle UML, spécifications, conception, que sais-je ?) En plus, ça augmente la productivité de toutes ces sales faignasses au regard bovin qui constituent la masse salariale. Alors, elle est pas belle la vie ?
Disons, oui et non. Il y a généralement deux stratégies :
- génération préliminaire de code, puis maintenance manuelle des pièces (comprendre fichiers) générées ;
- génération systématique de code à partir des entrées.
La première est souvent très pratique et permet de mettre en place une grosse architecture en place rapidement, mais peut mal vieillir, surtout si la génération a lieu bien avant que les entrées ne soient mûres. La seconde est bien plus pernicieuse, donc amusante au quotidien : les développeurs n’ont plus à maintenir le code opérationnel, mais uniquement les entrées. Ça, c’est la théorie. En pratique, ni le générateur, ni les entrées ne sont mûres. Par entrées j’entends les entrées pures du générateur citées plus haut, mais aussi potentiellement l’architecture, la plateforme, etc. Pourtant les impératifs du projet restent ce qu’ils sont : on corrige, on ajoute et on avance, rapidement s’il-vous-plaît. Alors, autant sans générateur toute la capacité de modification d’un composant se concentre à un seul niveau (le code opérationnel), autant avec, on en obtient trois : les entrées, le générateur … et le code généré bien entendu ! Et c’est l’entropie de l’univers qui se félicite, la complexité de gestion vient de gagner deux facteurs d’échelle, comme ça.
Un générateur de code doit produire du code humainement maintenable et débogable.
Il sera toujours temps de discuter toutes les stratégies de génération dans d’autres articles, mais le fondamental ci-dessus ne doit jamais être oublié. Que faire de millions de lignes de code auxquelles on ne comprend rien ? Comment modifier manuellement et rapidement du code généré (si si, ça peut s’avérer intéressant à petites doses) si le générateur duplique, triple les références aux mêmes choses sous différentes formes ? Un générateur de code, même certifié, ne fait que ce qu’on lui demande : il transpose des idées depuis un formalisme vers un autre. C’est un outil, et comme tel, il doit aider et non contraindre. De la même manière que vous pouvez comprendre ce que vous lui donnez à manger (diagramme UML et consorts), vous devez comprendre facilement le code produit.
