Réponses:
Reformulons cela:
Le coût d'un bon générateur de code automatique en vaut-il la peine?
Oui.
Le coût d'un pauvre générateur de code automatique qui crée plus de travail pour tout le monde mais son auteur en vaut-il la peine?
Absolument pas. Il n'y a aucune excuse pour un mauvais code. Si quelqu'un veut être intelligent et utiliser la génération automatique de code, il doit prendre le temps de s'assurer que le code généré est un bon code. Sinon, à quoi ça sert? Cela ne fait que pousser la balle vers le bas et quand il s'agit de la production de code, la balle devrait s'arrêter au développeur qui l'a écrit.
Le code généré par un générateur ne doit jamais être conservé à la main. S'il doit être modifié, le générateur et / ou ses paramètres doivent être modifiés et exécutés à nouveau. Compte tenu de cela, peu importe si le code résultant est incompréhensible et non documenté tant que le mécanisme de génération lui-même est limpide. (Assurez-vous de documenter le fait que le code est généré, et où se trouve le générateur et comment il fonctionne.)
Analogie: alors que le processeur de mon ordinateur exécute toujours du code machine, je n'ai besoin de rien savoir à ce sujet tant que je sais comment créer ce code machine en utilisant un langage et un compilateur de haut niveau. J'ai entendu dire que GCC produit parfois du code machine de qualité inférieure, mais peu importe, tant qu'il fonctionne parfaitement. Les couches d'abstraction de base de données produisent du SQL pour fonctionner avec le moteur de base de données, mais peu importe à quoi ressemble ce SQL, tant que la couche d'abstraction est claire et fonctionne?
Lorsqu'ils sont correctement utilisés, les générateurs de code peuvent certainement économiser non seulement la création, mais également les coûts de maintenance.
Un générateur de code est un type de compilateur. Vous ne vous inquiétez pas de la beauté de la sortie du compilateur, vous travaillez simplement avec le code source. L'utiliser puis modifier manuellement la sortie est souvent plus difficile que de l'écrire à partir de zéro sous une forme compréhensible par les humains, et signifie que vous ne pouvez pas utiliser à nouveau le générateur de code sans beaucoup de travail, car vous devrez appliquer le mêmes changements au même code incompréhensible avec précision.
Par conséquent, ils peuvent être corrects s'ils font partie du processus de génération et sont documentés comme tels. L'entrée du générateur est alors le code source, et tout ce qu'il produit est des résultats intermédiaires, à ne pas gâcher.
Cependant, si quelqu'un en utilise un pour produire du code incompréhensible censé être utilisé comme source, alors cette personne produit du mauvais code. Peu importe que la personne produise du mauvais code mécaniquement ou à la main, c'est toujours du mauvais code, et vous avez toujours un problème de qualité avec.
Par conséquent, vous devez traiter cela comme tout autre développeur coupant les coins et écrivant du mauvais code. Je ne sais pas comment tu gères ça dans ton magasin.
D'après les commentaires sur d'autres réponses, il semble que vous posiez des questions sur les normes d'équipe plutôt que sur les générateurs de code eux-mêmes.
Un outil de génération de code devrait être inclus dans le projet et devrait (le cas échéant) faire partie du processus de construction. Un exemple serait dans notre équipe que nous utilisons Subsonic 2.2 que nous avons généré des classes à partir des objets de base de données lors de la construction.
L'exe qui fait cela est archivé dans SVN dans le cadre du projet afin qu'un nouveau membre de l'équipe puisse obtenir le nouveau projet à partir de svn et le construire immédiatement sans avoir à comprendre d'où viennent toutes ces classes de base de données (dans cet exemple, nous n'inclut même pas le code généré dans svn).