问构建脚本的优点是什么？

EN

自动化。

当您正在开发时，只有在最简单的项目中，默认的" build“按钮才能完成您需要做的所有事情；您可能需要使用API创建WS、生成文档、链接外部资源、将更改部署到服务器等。有些IDE允许您通过添加额外的步骤或构建器来自定义构建过程，但这只意味着要通过IDE商品生成构建脚本。

但是开发一个系统不仅仅是编写代码。涉及多个步骤。可以自动执行独立于IDE的脚本，这意味着：

• 当您对版本控制进行更改时，服务器可以自动启动新版本。它将确保您没有忘记提交构建所需的任何内容。
• 类似地，构建完成后，可以自动运行测试，以查看是否弄坏了什么。
• 现在，组织的其他部分(QA、sysadmins)有了一个构建的产品，该产品仅从控制版本中就可以完全复制。( b)对所有这些人都是共同的。

即使在我作为一个团队工作时，我也曾为此目的使用过脚本；当我开发了修复程序时，我将提交给SVN，将SVN导出回另一个目录，并使用构建脚本来生成解决方案，该解决方案将转到生产前系统，然后再用于生产。如果几周后(我的本地代码库已经更改)有人抱怨有错误，我就会确切地知道我需要签出哪个SVN版本才能正确地调试系统。

与代码一样，生成脚本由计算机执行。计算机非常善于遵循一套指令。事实上，(在自修改代码之外)，如果输入相同，计算机将以完全相同的方式执行相同的指令序列。这提供了一种只有计算机才能匹配的一致性。

相比之下，当涉及到以下步骤时，美国充满水的肉袋简直太卑劣了。这个讨厌的分析性大脑有一种倾向，怀疑它所遇到的一切。“哦.我不需要那样做”，或者“我真的要用这个旗子吗?嗯……我就不理它了。”此外，我们也有自满的倾向。一旦我们做了几次，我们就开始相信我们知道指令，而不必看说明书。

来自“务实的程序员”：

此外，我们希望确保项目的一致性和可重复性。手工过程将一致性留给更改；可重复性得不到保证，特别是如果过程的各个方面可以由不同的人解释的话。

此外，我们在执行指令方面非常迟缓(与计算机相比)。在一个具有数百个文件和配置的大型项目上，手动执行构建过程中的所有步骤需要数年时间。

我会给你一个真实世界的例子。我正在开发一些嵌入式软件，大部分代码都是在几个不同的硬件平台上共享的。每个平台都有不同的硬件，但大多数软件是相同的。但每种硬件都有一些特定的小部件。理想情况下，常见的部分将放在一个库中并链接到每个版本中。但是，无法将常见的部分编译到共享库中。它必须用每种不同的配置进行编译。

首先，我手动编译了每个配置。只需几秒钟就可以在配置之间切换，而且没有那么大的痛苦。在项目接近尾声的时候，在代码的共享部分发现了一个关键缺陷，其中设备将基本上接管通信总线。这太糟糕了！真的很糟糕。我在代码中找到了错误，修复了它，并重新编译了每个版本。除了一个。在构建过程中，我心不在焉，忘了一个。二进制文件被释放，机器被建造，一天后，我接到一个电话，说机器停止了响应。我检查了一下，发现有一个装置锁住了公共汽车。“但是我修好了那个虫子！”

我可能把它修好了，但它从来没有在那块木板上找到出路。为什么？因为我没有一个自动构建过程，只需点击1次就可以构建每个版本。

如果您只想做<compiler> **/*.<extension>，那么构建脚本就没有什么用处了(尽管人们可能会说，如果您在项目中看到一个Makefile，您就知道可以使用make构建它)。问题是--不平凡的项目通常需要更多--至少，您通常需要添加库，并且(随着项目的成熟)配置构建参数。

IDE通常至少是可配置的，但现在构建过程依赖于特定于IDE的选项。如果您正在使用月食，Alice更喜欢NetBeans，而Bob希望使用IntelliJ理念，您不能共享配置，当您中的一个将更改推送到源代码管理时，他们需要手动编辑其他开发人员创建的IDE配置文件，或者通知其他开发人员以便他们自己来完成(这意味着将提交一些IDE配置对于某些IDE.)。

您还需要弄清楚如何在团队使用的每一个IDE中进行更改，如果其中一个不支持特定设置.

现在，这个问题与文化有关--您的开发人员可能会发现没有IDE的选择是可以接受的。但是，使用IDE的开发人员在使用IDE时通常会更快乐，效率更高，而文本编辑器用户往往会对他们最喜欢的工具产生狂热，因此这是您希望给开发人员自由的地方之一--构建系统允许您这样做。有些人可能有构建系统偏好，但它并不像IDE/编辑器偏好那样狂热.

即使你让所有的开发人员使用相同的IDE

现在，这是用于简单的构建过程自定义，IDE倾向于为其提供良好的GUI。如果您想要更复杂的东西--比如编译前的预处理/自动生成源文件--通常需要在IDE配置中的一些基本文本区域中编写预构建脚本。哪些构建系统您仍然需要编写这部分代码，但您可以在实际的编辑器中编写代码，更重要的是:构建系统的框架本身通常为组织这些脚本提供了一些支持。

最后，构建系统不仅适合于构建项目，还可以让它们执行团队中的每个人都可能需要执行的其他任务。例如，在Ruby on Rails中，有用于运行数据库迁移、清理临时文件等的构建系统任务。将这些任务放在构建系统中可以确保团队中的每个人都能一致地完成这些任务。