java - 它为代码生成器节省了多少时间？

Question

我的问题似乎很简单，但比看起来更具理论性。有一些代码生成软件或应用程序构建软件可以在不使用编程语言的情况下完成。Intelliun的 VE Server 和 VE Designer 等应用程序应该可以完成这项任务。我的问题是，实际上有人跟踪这种工具与拥有开发团队和源代码进化过程相比的实际节省量。

对于 VE 设计器的特定示例，应用程序从设计器完成，您看不到它的代码，您只需在 VE 服务器中运行应用程序。所有代码看起来都像 XML 内部命令。

Answer 1

这取决于我们如何衡量那个时间。

如果你比较两个控制组——一个手动输入所有代码，另一个使用代码生成器——我毫不怀疑使用代码生成器的组将需要更少的时间，放下手来。当然，这取决于你想用生成器走多远，但毫无疑问，随着生成代码的百分比上升，手动输入看起来越来越糟糕。

我唯一关心的是代码生成器来自哪里以及它的设计有多少想法。

如果您因为不理解而不想接触向导/代码生成器生成的代码，则应该将其计入代码生成器。

如果代码生成器迫使您进行糟糕的设计，则应该将其计入代码生成器。

如果代码生成器吐出的类太多以至于没有人可以跟踪正在发生的事情，那么它应该计入代码生成器。

如果代码生成器使您的维护生活成为人间地狱，那么它应该计入代码生成器。

如果可以的话，我喜欢理解和创建自己的工具的想法。其他人提供的向导可能会导致问题。支持或反对他们的会计应该反映问题。

Answer 2

您可能想看看“代码生成器坏吗？ ”这个问题的一些答案。'。虽然问题本身更多地与我应该/不应该使用代码生成器有关，但许多回复都有关于代码生成器使用的不利方面以及生成的代码如何经常必须由实际的人查看/编辑的注释存在。情况并非总是如此，并且很大程度上取决于生成代码的质量（毕竟它实际上只是由一个可能很糟糕的程序员编写的随地吐痰的模板，他真的想成为一名伐木工人，不应该被允许靠近键盘）。如果它生成高质量的代码，那么您可能会节省时间。否则，重构结果所花费的时间最终可能与最初实际编写代码所花费的时间相同或更大。

我个人对代码生成器的结果好坏参半。例如，由 Visual Studio 自动生成的代码（特别是表单设计器）我发现可能是一场噩梦，如果我需要突然实现一些特殊行为，表单看起来或行为不符合预期，这通常最终会让我付出代价更多时间。我喜欢eclipse中的那个（不是真正的全自动代码生成工具），因为它可以让我布局一个类，然后使用内置的可编辑模板构造所有方法签名等（我也知道，如果它吐出废话，那就是我自己的错）。我发现通用框架比获得一些认为它很好并且完全按照你想要的但没有做到的东西（例如，获得汽车底盘）更有用的时间节省完全' 构造的汽车，只有三个轮子，只能右转）。

Answer 3

我在两种情况下使用过代码生成（即自动生成 2/3 左右的代码并让程序员填写其余代码的程序），一次是在一家拥有巨大产品的大公司，另一次是使用我自己写的工具。在这两种情况下，我发现结果好坏参半。

1) 它节省了我们开发当时需要完成的工作的时间。

2）然而，它把我们锁在了我们的设计中，使代码变得不那么灵活。它给了我们很多无法轻易修改的重复逻辑。

据我所知，虽然我确信会有例外，但从长远来看，如果你使用一个代码生成工具来输出人类以后必须修改的代码，你会浪费时间。从本质上讲，如果它不像编译器并且不允许您轻松重构，那么它可能会进行上述权衡。

Answer 4

“代码生成器”和“编程语言”之间并没有明显的区别。如果你使用软件生成代码，你就是在编程，即使你不了解细节。C++、Java 和 C# 是“代码生成器”，因为它们被编译成低级语言，如果程序员选择这样做，这些低级语言本身可以手动编码。许多编程语言一开始是作为宏工具开始的，使用基于 XML 的工具编写脚本并不比用 Perl、Python 或 Ruby 编写相同的脚本更不像一个“程序”。

一般来说，通过使用软件生成高度重复的代码来节省时间是一个好主意。潜在的缺点是您可能会将自己锁定在一个平台中——也就是说，您仅限于代码生成器提供的功能。代码生成器（或编程语言）是否值得使用完全取决于它对给定问题的有效性。

不要误以为某些格式（如 XML 甚至 HTML）是死“数据”，而其他格式（如 C++ 和 Python）是“代码”。数据和代码是可以互换的。需要 HTML 中的“代码”示例吗？考虑以下：

HTML 是一种声明性语言。在其中，您以“这是一个段落，这是一个标题”等方式指定存在的事物。Python 和其他编程语言具有命令式部分，您可以在其中指定“现在添加 x 和 y，现在将 x 写入内存”等等。

但是，您可以颠倒这种关系。在 HTML 的情况下，当通过浏览器输入时，它变得势在必行。“这是一个具有这些属性的段落”被 Firefox 解释为“现在使用这些参数呈现一段文本”。作为一个文件，HTML 只是死数据，但在解释器的上下文中，它变成了活代码。反过来，Python 也会发生同样的情况。在执行期间，您的 Python 指令成为解释器的指令，但 Python 文件本身只是死文本。从某种意义上说，您的 Python 程序作为数据形式的潜在指令的集合坐在那里，直到您通过 Python 解释器运行它。以完全相同的方式，HTML 作为文件中的数据存在，直到浏览器需要对其进行操作为止。

XML 是一种数据格式，但指令是一种数据。您可以使用 XML 来包含命令式语句，例如数学运算或函数调用。您是否将该 XML 解释为数据或代码完全取决于上下文；从某种意义上说，所有计算机数据既是数据又是代码。数据和代码之间的区别是人类的惯例，而不是计算机固有的现实。

Edit: I guess I should concede here that on the processor architecture level, there is often a very concrete distinction between code and data. Code is what gets fed through the processor core and changes the state of the machine. A typical architecture keeps the bits that are waiting for execution in a separate area of memory from other data which does not represent executable code. But this distinction quickly becomes blurred when you start talking about interpreters.