可能有不同类型的代码生成。例如，在RoR中，Rails可以为模型，控制器等创建骨架。但是开发人员必须完成这些骨架。
现在有些项目根据一组定义或模型生成了许多核心工件。
我主要想知道后一种代码生成的优点和缺点。
答案 0 :(得分：6)
主要优点是它可以为您完成工作，可重复，并且代码最有可能工作（当然，这取决于编写生成器的人是否知道他们在做什么）。它可以消除执行编码任务所需的大量时间。例如，是否真的值得花时间编写只是数据库中数据容器的对象，或者让某些程序自动为您创建这些对象更好？
最大的缺点是它会强制您编写与生成的代码兼容的代码。大多数时候这不是问题，但当有人来找你说“嘿，我们可以做X吗？”时，这可能是一个真正的麻烦。并且与生成的代码冲突。如果生成器是好的，它将允许您更改功能，但这几乎总是增加了生成的代码的复杂性等。这种复杂性有代价。它更难以理解，而且您自己编写的代码效率会降低。这当然因情况而异。
答案 1 :(得分：1)
这种编程风格的主要问题是它会污染您的项目视图。它不再允许你练习DRY。在自动生成的内容与人类编写的内容之间进行清晰的分离是很有用的。大多数系统，尤其是基于文件的系统，都不支持这样的分离。在具有良好内省能力的系统（例如，小型图像）中，通过步行定义/模型来构建动态对象结构是优选的。
在基于幻觉的编程中（如大型公司和政府机构所实践的），它非常有用，因为它允许生成非常令人印象深刻的文档堆栈，并显示出令人印象深刻的实现性能，以每个月的代码行来衡量。你最重要的技能当然是为你的失踪行为计时。
答案 2 :(得分：1)
我认为最重要的是要记住为什么要生成源代码。例如，是因为你比任何编程语言更流利的UML，因此想要从该图形模型生成面向对象的类？
是不是因为您使用任何语言表达了架构定义（ SQL DDL ，例如：jOOQ， XSD ，例如JAXB code generation）和想要从中生成模型吗？
代码生成的优势始终是您只表达一次（如DRY中的内容，如Stephan所述）。这是一个非常好的做法，使其深入extreme programming（在其他过程中）。当您保持干燥状态时，您将不会冒模型与胶水代码不同的风险。另一方面，您可能会破坏胶水代码，因为它与其基础模型完全匹配。通常，每个RDMBS表或每个XML元素都有一个类/类型/对象。
但是，如果您使用代码生成，因为您对建模语言更加轻松（如MDA, or model-driven architecture中所述），您可能会面临生成的代码不够好（缺乏细节）的风险或者太复杂（缺乏简单性）因为 - 例如 - UML不适合详细解决问题。
在任何情况下：如果生成的代码可以使用 AS-IS 并且不需要任何自定义，则代码生成可能非常有用。一旦开始自定义生成的代码，它就可能成为维护的噩梦。