Les générateurs de code sont-ils mauvais?

https://stackoverflow.com/questions/202871

03-07-2019
|

Question

J'utilise MyGeneration avec nHibernate pour créer les objets POCO de base et les fichiers de mappage XML. J'ai entendu des gens dire qu'ils pensaient que les générateurs de code n'étaient pas une bonne idée. Quelle est la meilleure pensée actuelle? Est-ce juste que la génération de code est mauvaise quand elle génère des milliers de lignes de code incompréhensible?

La solution

Le code généré par un générateur de code ne doit pas (en règle générale) être utilisé dans une situation où il est ensuite édité par une intervention humaine. Certains systèmes, tels que les assistants de diverses incarnations de code généré par Visual C ++, devaient ensuite être édités à la main par le programmeur. Ce n'était pas populaire car les développeurs devaient séparer le code généré, le comprendre et faire des modifications. Cela signifiait également que le processus de génération était un coup.

Le code généré doit résider dans des fichiers distincts des autres codes du système et doit uniquement être généré à partir du générateur. Le code généré doit être clairement identifié comme tel pour indiquer que les utilisateurs ne doivent pas le modifier. J'ai eu l'occasion de faire pas mal de systèmes de génération de code d'une sorte ou d'une autre et Tout du code ainsi généré a quelque chose comme ceci dans le préambule:

-- =============================================================
-- === Foobar Module ===========================================
-- =============================================================
--
--         === THIS IS GENERATED CODE.  DO NOT EDIT. ===
--
-- =============================================================

Génération de code en action est un très bon livre sur le sujet.

Autres conseils

Les générateurs de code sont excellents, un mauvais code est mauvais.

La plupart des autres réponses de cette page vont dans le sens de & "Non, car souvent le code généré n'est pas très bon. &";

C'est une mauvaise réponse car:

1) Les générateurs sont des outils comme n'importe quoi d'autre. Si vous les utilisez à mauvais escient, ne blâmez pas l'outil.

2) Les développeurs ont tendance à être fiers de leur capacité à écrire du bon code une fois, mais vous n’utilisez pas de générateurs de code pour des projets ponctuels.

Nous utilisons un système de génération de code pour la persistance dans tous nos projets Java et avons des milliers de classes générées en production.

En tant que responsable, je les adore car:

1) Fiabilité: Il ne reste aucun bogue important dans ce code. Au fil des années, il a été testé et perfectionné de manière si exhaustive que lors du débogage, je ne me préoccupe jamais de la couche de persistance.

2) Normalisation: chaque code de développeur est identique à cet égard, de sorte qu’il est beaucoup moins à apprendre pour un gars lorsqu’il choisit un nouveau projet chez un collègue.

3) Évolution: si nous trouvons un meilleur moyen de procéder, nous pouvons mettre à jour les modèles et mettre à jour des milliers de classes rapidement et de manière cohérente.

4) Révolution: si nous passons à un système de persistance différent à l'avenir, le fait que chaque classe persistante possède une API exactement identique facilite grandement mon travail.

5) Productivité: il suffit de quelques clics pour créer un système d’objets persistant à partir de métadonnées - vous éviterez ainsi des milliers d’heures de développement ennuyeuses.

La génération de code revient à utiliser un compilateur: vous pouvez éventuellement écrire un langage d'assemblage optimisé, mais sur un grand nombre de projets, vous préféreriez que le compilateur le fasse pour vous, non?

Nous utilisons une astuce simple pour nous assurer que les classes peuvent toujours être régénérées sans perdre les personnalisations: chaque classe générée est abstraite. Ensuite, le développeur l'étend avec une classe concrète, ajoute la logique métier personnalisée et remplace les méthodes de classe de base qu'il souhaite différer de la norme. S'il y a un changement de métadonnées, il peut régénérer la classe abstraite à tout moment et si le nouveau modèle casse sa classe concrète, le compilateur le lui fera savoir.

Le problème le plus important que j'ai rencontré avec les générateurs de code est lors de la maintenance. Si vous modifiez le code généré, modifiez ensuite votre schéma ou votre modèle et tentez de le régénérer, des problèmes risquent de se produire.

Un problème est que si l’outil ne vous permet pas de protéger les modifications que vous avez apportées au code modifié, vos modifications seront écrasées.

Un autre problème que j'ai rencontré, en particulier avec les générateurs de code dans RSA pour les services Web, si vous modifiez trop le code généré, le générateur se plaindra de l'absence de correspondance et refusera de régénérer le code. Cela peut se produire pour quelque chose d'aussi simple que de changer le type d'une variable. Ensuite, vous êtes bloqué pour générer le code dans un projet différent et fusionner les résultats dans votre code d'origine.

Les générateurs de code peuvent être un avantage pour la productivité, mais il y a quelques points à rechercher:

Laissez-vous travailler comme vous le souhaitez.

Si vous devez plier votre code non généré pour l'adapter au code généré, vous devriez probablement choisir une approche différente.

Exécuter dans le cadre de votre construction habituelle.

La sortie doit être générée dans un répertoire intermédiaires et ne pas être archivée dans le contrôle de source. L’entrée doit cependant être archivée dans le contrôle de source.

Aucune installation

Idéalement, vous archivez également l'outil dans le contrôle de source. Faire en sorte que les gens installent des choses lors de la préparation d'une nouvelle machine de compilation est une mauvaise nouvelle. Par exemple, si vous branchez, vous voulez pouvoir modifier les outils avec le code.

Si vous devez, créez un seul script qui utilisera une machine vierge avec une copie de l’arborescence source, puis configurez la machine selon vos besoins. Entièrement automatisé, s'il vous plaît.

Aucune sortie d'édition

Vous ne devriez pas avoir à éditer la sortie. Si la sortie ne vous suffit pas telle quelle, l'outil ne fonctionne pas pour vous.

De plus, la sortie doit clairement indiquer qu'il s'agit d'un fichier généré & amp; ne devrait pas être édité.

Sortie lisible

La sortie doit être écrite & amp; bien formaté. Vous voulez pouvoir ouvrir la sortie & Amp; lisez-le sans trop de peine.

#line

De nombreuses langues supportent quelque chose comme une directive <=>, qui vous permet de mapper le contenu de la sortie sur l'entrée, par exemple lors de la production de messages d'erreur du compilateur ou lors de l'activation du débogueur. Cela peut être utile, mais cela peut aussi être agaçant si vous ne le faites pas vraiment bien. Ce n'est donc pas une exigence.

Ma position est que les générateurs de code ne sont pas mauvais, mais BEAUCOUP d’utilisations le sont.

Si vous utilisez un générateur de code permettant de gagner du temps et qui écrit un bon code, c'est génial, mais souvent, il n'est pas optimisé, ou ajoute beaucoup de temps système, dans les cas où je pense que c'est mauvais.

La génération de code peut vous causer des problèmes si vous souhaitez mélanger le comportement dans vos classes. Une alternative tout aussi productive pourrait être les attributs / annotations et la réflexion à l'exécution.

Les compilateurs sont des générateurs de code, ils ne sont donc pas intrinsèquement mauvais, à moins que vous ne souhaitiez programmer en code machine brut.

Je pense cependant que les générateurs de code devraient toujours encapsuler complètement le code généré. C'est à dire. vous ne devriez jamais modifier le code généré à la main. Toute modification doit être effectuée en modifiant l'entrée du générateur et en régénérant le code.

Si c’est un générateur de code cobol pour mainframe que Fran Tarkenton essaie de vous vendre, alors absolument oui!

J'ai déjà écrit quelques générateurs de code - et pour être honnête, ils ont sauvé mes fesses plus d'une fois!

Une fois que vous avez clairement défini la conception objet, collection, utilisateur, vous pouvez utiliser un générateur de code pour en construire les bases, ce qui vous permettra de mieux utiliser votre temps de développeur pour créer des éléments complexes. qui veut vraiment écrire plus de 300 déclarations de propriétés publiques et instatiations variables? Je préfère rester coincé dans la logique métier que toutes les tâches répétitives insensées.

L’erreur que commettent beaucoup de gens lors de l’utilisation de la génération de code est de modifier le code généré. Si vous gardez à l'esprit que si vous sentez que vous devez modifier le code, vous devez réellement modifier l'outil de génération de code, ce qui est un avantage pour la productivité. Si vous vous battez constamment contre le code généré, votre productivité en sera réduite.

Les meilleurs générateurs de code que j'ai trouvés sont ceux qui vous permettent d'éditer les modèles qui génèrent le code. J'aime beaucoup Codemith pour cette raison, car il est basé sur des modèles et les modèles sont facilement modifiables. Lorsque vous constatez une déficience dans le code généré, modifiez simplement le modèle et régénérez votre code. Vous serez toujours bon après cela.

L’autre chose que j’ai trouvée est que beaucoup de générateurs de code ne sont pas très faciles à utiliser avec un système de contrôle de code source. Pour ce faire, nous archivons les modèles plutôt que le code. La seule chose que nous vérifions dans le contrôle de code source généré est une version compilée du code généré (fichiers DLL, principalement). ). Cela vous évite bien des soucis car il vous suffit d’archiver quelques DLL plutôt que des centaines de fichiers générés.

Notre projet actuel utilise beaucoup un générateur de code. Cela signifie que j'ai vu à la fois le & «Évident &»; avantages de générer du code pour la première fois - pas d’erreur de codeur, pas de fautes de frappe, meilleur respect du style de codage standard - et, après quelques mois en mode maintenance, les inconvénients inattendus. En effet, notre générateur de code a initialement amélioré la qualité de notre base de code. Nous nous sommes assurés qu'il était entièrement automatisé et intégré à nos versions automatisées. Cependant, je dirais que:

(1) Un générateur de code peut être une béquille. Nous avons maintenant dans notre système plusieurs blobs massifs et vilains de code difficile à maintenir, car il était autrefois plus facile d'ajouter 20 nouvelles classes à notre fichier XML de génération de code que d'effectuer une analyse et une classe appropriées. refactoring.

(2) Les exceptions à la règle vous tuent. Nous utilisons le générateur de code pour créer plusieurs centaines de classes Screen et Business Object. Au départ, nous avons imposé une norme sur les méthodes pouvant apparaître dans une classe, mais comme toutes les normes, nous avons commencé à faire des exceptions. Maintenant, notre fichier XML de génération de code est un monstre gigantesque, rempli d'extraits de code Java dans des cas spéciaux insérés dans des classes select. Il est presque impossible d'analyser ou de comprendre.

(3) Étant donné qu'une grande partie de notre code est générée à l'aide des valeurs d'une base de données, il est difficile aux développeurs de maintenir une base de code cohérente sur leurs postes de travail individuels (car il peut y avoir plusieurs versions de la base de données). Le débogage et le suivi via le logiciel sont beaucoup plus difficiles et les débutants de l'équipe prennent beaucoup plus de temps pour comprendre le & "Flux &"; du code, en raison de l'abstraction supplémentaire et des relations implicites entre les classes. Les IDE ne peuvent pas identifier les relations entre deux classes qui communiquent via une classe générée par du code.

C'est probablement suffisant pour le moment. Je pense que les générateurs de code sont excellents dans le cadre de la boîte à outils individuelle du développeur. un ensemble de scripts qui écrivent votre code standard facilitent beaucoup le démarrage d'un projet. Mais les générateurs de code ne pas résolvent les problèmes de maintenance.

Dans certains cas (peu nombreux), ils sont utiles. Par exemple, si vous souhaitez générer des classes basées sur des données de type référence dans les tables de la base de données.

La génération de code est mauvaise quand elle rend la programmation plus difficile (IE, code mal généré ou un cauchemar de maintenance), mais elle est bonne quand elle rend la programmation plus efficace.

Ils ne génèrent probablement pas toujours un code optimal, mais en fonction de vos besoins, vous pouvez décider que les heures de travail des développeurs sauvegardées compensent quelques problèmes mineurs.

Cela dit, mon plus grand reproche aux générateurs de code ORM est que la maintenance du code généré peut être un PITA si le schéma change.

Les générateurs de code ne sont pas mauvais, mais ils sont parfois utilisés dans les situations où une autre solution existe (par exemple, instancier un million d'objets lorsqu'un tableau d'objets aurait été plus approprié et réalisé en quelques lignes de code).

L'autre situation est quand ils sont mal utilisés, ou mal codés. Trop de gens détruisent les générateurs de code parce qu’ils ont eu de mauvaises expériences à cause de bugs ou parce qu’ils ne comprennent pas comment le configurer correctement.

Mais en soi, les générateurs de code ne sont pas mauvais.

-Adam

Ils sont comme n'importe quel autre outil. Certains donnent de meilleurs résultats que d'autres, mais il appartient à l'utilisateur de savoir quand les utiliser ou non. Un marteau est un outil terrible si vous essayez de visser une vis.

C’est l’une de ces questions très controversées. Personnellement, je pense que les générateurs de code sont vraiment mauvais à cause du code de merde non optimisé que la plupart d'entre eux ont sorti.

Cependant, la question est vraiment une question à laquelle vous seul pouvez répondre. Dans de nombreuses organisations, le temps de développement est plus important que la vitesse d'exécution ou même la maintenabilité du projet.

Nous utilisons des générateurs de code pour générer des classes d'entité de données, des objets de base de données (tels que des déclencheurs, des procs stockés), des mandataires de service, etc. Partout où vous voyez beaucoup de code répétitif suivant un modèle et beaucoup de travail manuel, les générateurs de code peuvent vous aider. Cependant, vous ne devriez pas trop l’utiliser dans la mesure où la maintenabilité est pénible. Certains problèmes se posent également si vous souhaitez les régénérer.

Des outils tels que Visual Studio, Codesmith ont leurs propres modèles pour la plupart des tâches courantes et facilitent ce processus. Mais il est facile de le déployer par vous-même.

Cela peut vraiment devenir un problème de maintenabilité lorsque vous devez revenir et ne pas comprendre ce qui se passe dans le code. Par conséquent, il est souvent nécessaire de peser l’importance de la rapidité du projet par rapport à la facilité de maintenance.

maintenabilité < > processus de codage facile ou rapide

J'utilise Ma génération avec des espaces d'entité et je n'ai aucun problème avec cela. Si j'ai un changement de schéma, je régénère simplement les classes et tout se passe bien.

Ils servent de béquille qui peut vous empêcher de maintenir le programme à long terme.

Les premiers compilateurs C ++ étaient des générateurs de code qui crachaient du code C (CFront).

Je ne sais pas s'il s'agit d'un argument pour ou contre les générateurs de code.

Je pense que Mitchel l’a frappé à la tête. La génération de code a sa place. Dans certaines circonstances, il est plus efficace de laisser l’ordinateur faire le travail à votre place! Cela peut vous donner la liberté de changer d’avis sur l’implémentation d’un composant particulier lorsque le temps nécessaire à la modification du code est peu coûteux. Bien sûr, il est probablement toujours important de comprendre la sortie du générateur de code, mais pas toujours. Nous avons eu un exemple sur un projet que nous venons de terminer, dans lequel plusieurs applications C ++ devaient communiquer avec une application C # via des canaux nommés. Il était préférable pour nous d'utiliser des fichiers simples et petits qui définissent les messages et génèrent toutes les classes et le code générés pour chaque côté de la transaction. Quand un programmeur travaillait sur le problème X, la dernière chose dont ils avaient besoin était de s’inquiéter des détails de l’implémentation des messages et de la fatalité inévitable du cache que cela entraînerait.

Ceci est une question de workflow. ASP.NET est un générateur de code. Le moteur d'analyse XAML génère réellement C # avant d'être converti en MSIL. Lorsqu'un générateur de code devient un produit externe, tel que CodeSmith, qui est isolé de votre flux de travail de développement, un soin particulier doit être apporté à la synchronisation de votre projet. Par exemple, si le code généré est une sortie ORM et que vous apportez une modification au schéma de la base de données, vous devrez soit abandonner complètement le générateur de code, soit exploiter la capacité de C # de travailler avec des classes partielles (vous permettant d'ajouter des membres). et fonctionnalité à une classe existante sans l’hériter).

Personnellement, je n'aime pas la nature isolée / Alt-Tab des flux de travail du générateur; si le générateur de code ne fait pas partie de mon IDE, alors je sens que c'est un kludge. Certains générateurs de code, tels que Entity Spaces 2009 (non encore publié), sont plus intégrés que les générations précédentes de générateurs.

Je pense que la panacée à l'objectif des des générateurs de code peut être utilisée dans les routines de précompilation. C # et d’autres langages .NET n’en ont pas, bien que ASP.NET en profite et c’est pourquoi, disons, SubSonic fonctionne si bien pour ASP.NET, mais pas grand chose d’autre. SubSonic génère du code C # au moment de la construction, juste avant l’installation de la compilation ASP.NET normale.

Demandez à votre fournisseur d’outils (Microsoft) de prendre en charge de manière plus complète les routines de pré-génération, afin que les générateurs de code puissent être intégrés au flux de travail de vos solutions à l’aide de métadonnées, plutôt que gérés manuellement en tant que fichiers de code générés de manière externe et devant être conservés. en vase clos.

Jon

La meilleure application d'un générateur de code est lorsque l'ensemble du projet est un modèle et que tout le code source du projet est généré à partir de ce modèle. Je ne parle pas UML et merde liée. Dans ce cas, le modèle de projet contient également du code personnalisé.

Ensuite, les développeurs ne doivent se soucier que du modèle. Un simple changement d'architecture peut entraîner la modification instantanée de milliers de lignes de code source. Mais tout reste synchronisé.

C’est à mon humble avis la meilleure approche. Son utopique? Au moins, je sais que ce n’est pas le cas;) L’avenir proche le dira.

Dans un projet récent, nous avons construit notre propre générateur de code. Nous avons généré tous les éléments de base de données, ainsi que tout le code de base pour notre vue et nos classes de contrôleurs. Bien que le générateur ait pris plusieurs mois à se construire (principalement parce que c'était la première fois, et que nous avions quelques faux départs), il était rentabilisé la première fois que nous l'avions exécuté et avait généré le cadre de base de l'application entière. environ dix minutes. Tout se passait en Java, mais Ruby est un excellent langage d’écriture de code, en particulier pour les petits projets ponctuels. La meilleure chose était la cohérence du code et de l'organisation du projet. De plus, vous devez en quelque sorte penser le cadre de base à l'avance, ce qui est toujours bon.

Les générateurs de code sont excellents en supposant que c’est un bon générateur de code. Surtout travailler c ++ / java qui est très prolixe.

Licencié sous: CC-BY-SA avec attribution

Non affilié à StackOverflow