La génération de code augmente-t-elle la qualité du code?


12

Arguant de la génération de code, je cherche des exemples de façons dont il augmente la qualité du code. Pour clarifier ce que je veux dire par génération de code, je ne peux parler que d'un de mes projets:

Nous utilisons des fichiers XML pour décrire les relations d'entité dans notre schéma de base de données, ils nous aident donc à générer notre cadre ORM et nos formulaires HTML qui peuvent être utilisés pour ajouter, supprimer et modifier des entités.

À mon avis, cela augmente la qualité du code car l'erreur humaine est réduite. Si quelque chose n'est pas implémenté correctement, il est cassé dans le modèle, ce qui est bien car l'erreur peut apparaître plus tôt car le code généré est également cassé.

Comme on m'a demandé la définition de la qualité du code , permettez-moi de clarifier cela, ce que je voulais dire, c'est la qualité du logiciel .

Qualité du logiciel : Ce n'est pas un attribut mais plusieurs, par exemple l'efficacité, la modifiabilité, la lisibilité, l'exactitude, la robustesse, la compréhensibilité, l'utilisabilité, la portabilité, etc. qui ont un impact les uns sur les autres.


3
Quelle est votre définition de la qualité du code?
NoChance

@EmmadKareem J'en ai ajouté une courte définition sur la question d'origine.
platzhirsch

1
Je pense que la génération de code automatisée contribuera à accroître la cohérence et l'uniformité de votre code. Dans certains cas, cela augmente la qualité, mais je ne pense pas que ce soit un fourre-tout.
joshin4colours

Réponses:


38

Les générateurs de code ne peuvent pas générer un meilleur code que la personne qui a écrit le générateur.

Mon expérience avec les générateurs de code est qu'ils sont très bien tant que vous n'avez jamais à modifier le code généré . Si vous pouvez respecter cette règle, alors vous êtes prêt à partir. Cela signifie que vous pouvez régénérer de manière fiable cette partie du système avec confiance et rapidité, en ajoutant automatiquement plus de fonctionnalités si nécessaire. Je suppose que cela pourrait compter pour la qualité.

J'ai entendu une fois un argument en faveur des générateurs de code selon lequel un seul programmeur peut produire tant de lignes de code par jour et avec des générateurs de code, ils pourraient produire des milliers de lignes! Ce n'est évidemment pas la raison pour laquelle nous utilisons des générateurs.


6
+ la section en italique mille fois. Les générateurs de code devraient fonctionner comme votre compilateur ou le mécanisme de modèle C ++: vous ne devriez jamais avoir à modifier manuellement leur sortie. La seule fois où vous devriez lire le résultat est si vous suspectez un bogue.
Anon

1
C'est dommage que je ne puisse pas voter plus ...
Fabricio Araujo

@anon: Les Homans ne devraient généralement pas éditer la sortie des générateurs de code ou des compilateurs, mais il peut parfois être parfaitement raisonnable d'avoir un processus de construction qui implique d'exécuter un morceau de code généré par la machine via un programme qui lui applique des modifications. Il y a aussi des cas où il peut être nécessaire d'avoir une main humaine éditer la sortie d'un processus de construction s'il est nécessaire de patcher du code mis en place tout en changeant un nombre minimal d'octets, mais lorsque le code est modifié à la main de cette manière, on devrait archivez également tous les fichiers du processus de construction (pas seulement la source!) et ...
supercat

... également mettre à jour le code source pour qu'il corresponde à la sémantique du code objet édité à la main.
supercat

20

Je dirais le contraire - en supposant que vous écrivez des applications intéressantes, la génération de code diminue la qualité du code. La nature de la génération de code récompense des cadres très coupants de cookies, exagérés et sur-spécifiés qui deviennent très difficiles à gérer sans dépendre continuellement de l'outil de génération de code pour générer en continu des paquets de code plus gros, plus complexes et plus laids. Bien qu'il puisse être un bon outil, il ne devrait vraiment pas être l'outil principal de la boîte.


3
D'accord, les ordures qui sortent de certains ORM (ordures du point de vue de quelqu'un qui sait écrire du code de base de données performant) est un bon exemple. Cela fonctionne souvent assez pour que quelqu'un qui ne sait pas ce qu'il fait pense que cela fonctionne. Et les nouveaux programmeurs n'ont pas les compétences pour faire les choses les plus difficiles à faire en dehors du générateur car ils ne comprennent pas les concepts de base.
HLGEM

1
Ooh, +1 ou -1 .... d'une part, la génération de code est très utile pour supprimer le code répétitif et ennuyeux où vous avez une définition qui est simplement développée en code, mais vous avez raison de dire qu'elle est surutilisée dans toutes sortes de complexité de «gain de temps» qui finit par un anti-modèle en soi.
gbjbaanb

13

Je pense que la génération de code automatisée et la qualité du code sont quelque peu orthogonales et ne sont pas nécessairement corrélées.

La génération de code n'est qu'un moyen de résoudre une tâche technique spécifique. Que cela entraîne une augmentation de la qualité du code dépend beaucoup de ce que vous faites.

Votre situation est un bon exemple de génération de code résultant en une qualité de code accrue grâce à un rattrapage précoce des erreurs potentielles.

Je peux vous donner un autre exemple lorsque la génération de code automatisée diminue la qualité du code. C'est tout puissant ASP.NET WebForms. Il génère automatiquement du code en traduisant une hiérarchie de contrôles d'interface utilisateur en balisage HTML, ce qui est tout sauf stable, prévisible et gérable.

Pour tirer la conclusion, la génération automatisée de code peut aider à augmenter la qualité du code lorsqu'elle est utilisée correctement.


11

La génération de code n'affecte pas la qualité du code en soi, autant que la cohérence du code .

Le code généré sera cohérent entre les instances de génération. Si le générateur est conçu pour émettre un code de bonne qualité, le code généré sera toujours de bonne qualité. Si, cependant, le générateur de code émet du code de mauvaise qualité, vous obtiendrez toujours un code incorrect.

La génération de code peut également être utilisée pour construire du code plus rapidement . Plus rapide, cependant, ne signifie pas mieux ... Cela pourrait simplement signifier que vous obtenez votre code de mauvaise qualité beaucoup plus rapidement.


6

La génération de code est bonne si:

  • le code généré n'est pas censé être édité
  • le générateur de code vous donne suffisamment de flexibilité pour faire ce que vous devez faire
  • le langage de saisie du générateur de code est meilleur (c'est-à-dire SEC) que ce que vous auriez autrement à écrire
  • le générateur de code crée un bon code fiable dont vous n'avez pas à vous soucier, même s'il est verbeux

Lorsque c'est le cas, le code dont vous devez tenir compte de la qualité est le code qui est entré dans le générateur.

Une mesure simple de la qualité est, pour les changements typiques d'exigences, la quantité d'édition manuelle que vous devez faire. Le moins, mieux c'est.


et que le code généré mappe de manière transparente à l'original, vous n'avez donc pas à déboguer sur le code généré.

@ Thorbjørn: Je suis d'accord. Sur une application que j'ai dû maintenir, Fortran est généré. Le besoin de pouvoir le déboguer a été perdu au fil des ans, et je suis le seul assez stupide pour être toujours là pour répondre aux appels de service :)
Mike Dunlavey

Je ne suis pas d'accord que le générateur de code devrait être flexible. Il doit être ciblé - faites bien une chose, pas beaucoup de choses. Cela devrait prendre une petite entrée bien définie et écrire un morceau de code pour vous. Quand il commence à être le programme, il se dirige vers l'échec.
gbjbaanb

@gbjbaanb: Je suis d'accord. C'est pourquoi j'ai dit assez de flexibilité . Pour moi, le problème n'est pas le générateur de code lui-même, mais le langage spécifique au domaine qui lui sert d'entrée. Si ce DSL est trop flexible, l'utilisateur doit se déplacer dans les options. S'il n'est pas suffisamment spécifique, l'utilisateur doit contourner ses limites. Je peux en donner des exemples.
Mike Dunlavey

4

Augmentation de la qualité du code en raison de DRY (ne vous répétez pas).

Les règles de génération de code sont écrites une seule fois; ils ne sont pas codés en dur pour chaque instance de code généré, et réduisent ainsi le potentiel d'erreur humaine lors de la copie / collage du contenu avec de légères modifications.


À moins que vous n'ayez à éditer le code généré - qui n'est pas du tout SEC ... J'ai dû le faire récemment - ce n'est pas agréable du tout . Si je devais modifier manuellement une base de code générée automatiquement, je facturerais trois fois !!!
Fabricio Araujo

1
Vous ne devriez jamais avoir à modifier ce code; éditez le code qui a fait la génération elle-même et complétez-le avec des règles supplémentaires si nécessaire. La modification du code généré doit être le dernier recours.
earlNameless

1
J'aimerais avoir ce choix .. Je ne l'ai pas fait.
Fabricio Araujo

2

Je suppose que vous voulez dire des générateurs de code propriétaires contrôlés manuellement pour une utilisation interne spécifique, car sinon, tout ce qui est à court de code machine est un générateur de code. Mais c'est parti:

entrez la description de l'image ici

Je pense qu'il est très discutable que le graphique de nœud dans Blueprints est plus facile à entretenir et beaucoup moins sujet aux erreurs que le code GLSL / HLSL qu'il génère (et aurait sinon dû être écrit à la main).

Il est également beaucoup plus productif de proposer de nouveaux shaders, car vous obtenez un retour visuel en temps réel de l'apparence du résultat final lorsque vous modifiez le graphique. Je préférerais certainement conserver des milliers de shaders représentés avec des graphiques nodaux de cette façon au lieu du code GLSL / HLSL, et je suis en fait plus familier avec l'écriture GLSL / HLSL qu'avec les Blueprints. Je pense qu'il est pratiquement impossible de provoquer comme un bug majeur, à part peut-être un petit problème visuel que vous attraperiez probablement tout de suite parce que le "langage visuel" impose des contraintes sensibles avec souvent un style fonctionnel pur qui ne vous permet pas, par exemple, planter un shader, au moins AFAIK (je ne suis certes pas un expert en Blueprints).

Il n'y a même plus de "code" à maintenir. Vous placez simplement des nœuds dans un graphique et tracez des liens entre eux et, le tour est joué, il génère du code shader pour vous. Qui maintient ce genre de choses et dit: " Vous savez, ma vie serait tellement plus facile et j'aurais tellement plus de temps libre si cela était simplement écrit en code GLSL au lieu d'utiliser des Blueprints. " Probablement jamais.

Cela dit, j'ai rencontré ma part de générateurs de code propriétaires qui ont rendu la vie plus difficile, ce qui m'a fait apprendre ce stupide méta-langage qui a des avantages très limités, le cas échéant, par rapport à l'écriture de code dans la langue du code qu'il a généré. Pour moi, un signe révélateur de la génération de code qui est merdique est celui qui ne fait guère plus que de réduire une petite quantité de passe-partout et ne réduit pas, par exemple, la possibilité de bogues. Vous savez, c'est particulièrement merdique s'il introduit de nouvelles façons de provoquer des bogues que la langue d'origine n'avait pas. Mais il y a des cas pour la génération de code, comme ci-dessus, où l'augmentation de la productivité est si massive, ce qui rend des choses méticuleuses qui coûtent énormément de temps coûtent des sous, que personne ne l'utiliserait jamais et regarderait en arrière.

Pour moi, il y a un argument plus légitime pour le développement propriétaire de Blueprints parmi l'équipe Epic que de nombreux langages de programmation superflus pour le grand public qui apportent à peine quelque chose de nouveau à la table.


1

Je dirais que dans votre cas, cela peut augmenter un peu la qualité, mais réduit considérablement le temps de développement. Parfois, le code généré est floconneux, maladroit ou tout simplement mauvais. Dans ces cas, le code généré peut diminuer la qualité et ajouter plus de temps de test / correction / test de régression au projet. Et certaines tâches sont tout simplement trop complexes pour être facilement générées - le générateur devient un système complètement séparé (peut-être plus grand et plus complexe que le projet principal) en lui-même.

Les générateurs de code sont très bien, mais faites attention avec eux!


1

J'avais l'habitude de travailler dans un magasin qui comptait beaucoup sur la génération de code. Dans mon esprit, cela rendait le code du projet très uniforme. Et à cet égard, la qualité était correcte.

Cependant, lorsque vous n'êtes plus autorisé à écrire du code personnalisé parce que tout doit passer par le générateur, je pense que vous perdez une partie de l'avantage d'être un programmeur.

Je pense donc que c'est un sujet épée à double tranchant à coup sûr. Oui, les générateurs sont excellents car ils réduisent les erreurs et augmentent les normes de code, mais ils rendent également "certains" des programmeurs stupides, car ils dépendent des générateurs au lieu d'avoir à se salir les mains.

Juste mes 2 cents.


3
Les programmeurs de langage d'assemblage disaient cela à propos des compilateurs. Je ne suis donc pas sûr que ce soit un excellent argument. Être forcé de se salir les mains peut être une bonne expérience d'apprentissage, mais une fois que vous avez appris, vous devez utiliser l'outil le plus productif disponible.
MarkJ

@MarkJ: Parfois, l'assemblage peut en fait être meilleur qu'un langage compilé pour l'uniformité. Par exemple, dans certains systèmes embarqués, il est utile de pouvoir coder l'équivalent de x=someValue ^ 0xFF ^ 0xFF ^ 0xFF ^ 0xFF;et de le faire coder avec quatre instructions XOR. Si le support de stockage de code ne peut écrire que des octets vides (0xFF), la construction ci-dessus autorisera quatre modifications arbitraires de la valeur. Même si on a réécrit l'expression comme x=someValue; x = x ^ 0xFF ^ 0xFF ^ 0xFF ^ 0xFF;et que le compilateur a évalué tous les xors au moment de l'exécution, il pourrait toujours utiliser un "complément tous les bits" ...
supercat

... une instruction plutôt qu'un xor-immédiat.
supercat

1

En plus de la réponse de Martin, j'ajouterais que la génération de code SQL est très bonne lorsque vous travaillez enregistrement par enregistrement (sélectionnez * dans tab1 où tab1.pkcolumn =: paramètre, mettez à jour tab1 set [n'importe quel nombre de colonnes] où tab1.pkcolumn =: paramètre, etc.). Et votre ORM brillera dans ce scénario, car le SQL qui doit être généré est en effet répétitif.

Mes principales préoccupations sont les méta-requêtes - les requêtes sur les propriétés des objets que l'ORM traduit en SQL en utilisant n'importe quel algorithme. Des méta-requêtes très similaires peuvent générer du SQL complètement différent - et n'ont aucune garantie que ce SQL généré est performatique.

Langage de méta-requête qui se traduit par un autre langage (SQL) qui se traduit par un plan de requête pour exécuter efficacement la collecte de données. Et le résultat généré doit être des objets, donc l'ORM doit instancier les objets affectés - afin qu'il puisse déclencher une autre pluie de requêtes pour remplir les attributs des objets non apportés par la méta-requête elle-même ...


0

Je suis totalement d'accord avec ceux qui disent que la génération de code est correcte tant que vous n'avez jamais à modifier (de préférence, jamais à regarder) le code généré.

Si nous pouvons accepter que le code généré est approximativement le même nombre de lignes que celui écrit à la main, et si nous pouvons dire qu'il est exempt de bogues, alors le nombre de lignes qui pourraient potentiellement contenir des bogues a diminué. Ergo, la qualité du code aurait dû augmenter.


Addendum: bien sûr, d'autres facteurs, tels que le temps d'exécution, peuvent jouer un rôle.

Personnellement, j'ai écrit pas mal de générateurs de code, mais jamais comme approche initiale.

Cela a toujours été le cas lorsque j'ai remarqué un motif répétitif dans le code existant, donc mon générateur prend du code existant lors de l'ajout de nouveau code, mais similaire, et a paramétré certaines parties variables de celui-ci.

Dans cette mesure, mon code généré est presque identique au code manuscrit existant (sauf qu'il tend à être mieux présenté visuellement et plus uniforme, ce qui, selon moi, facilite la lisibilité, s'il doit jamais être examiné).

Btw, je préconise l'insertion de commentaires d'ouverture / fermeture qui indiquent que le code a été généré, y compris les détails de l'outil et de son responsable.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.