本页讨论了什么是构建系统、它们的功能，以及为什么您应该使用 以及为什么编译器和构建脚本并不是 开始扩大规模它适用于没有太多经验的开发者 并且拥有丰富的构建系统经验
什么是构建系统？
从根本上说，所有构建系统都有一个简单的目的： 由工程师编写的可执行二进制文件的源代码 由机器生成。构建系统不仅仅适用于人工编写的代码；它们还允许 自动创建 build，无论是用于测试还是用于发布 生产环境。在有数千名工程师的组织中，这种情况很常见 大多数构建都是自动触发的，而不是由工程师直接触发的。
我不能只使用编译器吗？
对构建系统的需求可能不会立即显现出来。大多数工程师
在学习编码时不使用构建系统：大多数人会先调用
例如 gcc 或 javac，或
集成开发环境 (IDE)。只要所有源代码都在
相同目录下，这样的命令就行了：
javac *.java
此命令指示 Java 编译器获取当前 并将其转换为二进制类文件。在最简单的情况下，就是 所需的一切。
不过，一旦代码扩展，复杂问题就开始了。javac 很智能
在当前目录的子目录中查找
导入。但无法找到存储在
文件系统（可能是由多个项目共享的库）。它也只知道
如何构建 Java 代码。大型系统通常涉及用
各种编程语言，这些部分之间具有依赖项网络，
这意味着任何编译器都无法构建整个系统。
在处理来自多种语言或多次编译的代码后 构建代码不再是一步到位。现在，您必须评估 您的代码所依赖的部分，并以适当的顺序构建这些部分，例如， 为每件零件制作一套不同的工具如果任何依赖项发生变化， 重复此过程，以避免依赖过时的二进制文件。对于 这个过程很快就会变得繁琐且容易出错。
此外，编译器对如何处理外部
依赖项，例如 Java 中的第三方 JAR 文件。如果没有构建系统
则可以从互联网下载依赖项并坚持
将其放在硬盘上的 lib 文件夹中，并将编译器配置为读取
库。久而久之，将难以维护
这些外部依赖项的更新、版本和来源。
Shell 脚本呢？
假设你的爱好项目一开始就非常简单，你可以自行构建 但会开始遇到上述一些问题 。也许您仍然认为自己不需要构建系统，并且可以自动执行 使用一些简单的 Shell 脚本 以便按照正确的顺序构建应用这会有用一段时间 您很快就会遇到更多问题：
变得单调乏味。随着系统变得越来越复杂 构建脚本所用的时间几乎与编写实际代码的时间一样多。调试 Shell 脚本很痛苦，越来越多的黑客手段 相互交流。
速度很慢。为了确保您不会意外依赖过时的库 让 build 脚本在每次构建新依赖项时都按顺序构建 运行应用。您考虑添加一些逻辑来检测哪些部分需要 但这听起来极其复杂，对脚本来说也容易出错。或 您考虑指定每次重新构建哪些部分， 则会返回 Square 1
好消息：是时候发布了！最好弄清楚所有参数， 您需要将其传递给 jar 命令，以进行最终的构建。请注意 如何上传和推送到中央存储库构建和 推送文档更新，并向用户发送通知。嗯， 这可能需要另一个脚本...
惨了！您的硬盘崩溃了，现在您需要重新创建整个 系统。你足够聪明了，能将所有源文件都保留在版本中 但您下载的库会怎么样呢？你能找到他们吗 确保它们的版本与您第一次 下载了这些应用？您的脚本可能取决于 安装在特定位置，能否恢复相同的环境， 这些脚本又能正常运行吗？您设置的所有这些环境变量 确保编译器正好运行，然后就被遗忘了？
尽管存在一些问题，但您的项目已经非常成功， 聘用更多工程师。现在，您已意识到这并不可取 还需要经历同样的痛苦 每次有新开发者加入您的团队时，都会进行自制。且 尽管已经尽了最大努力，但每个阶段 用户的系统。通常，在个人计算机上有效的内容并不能 每次需要花几个小时调试工具路径或 以了解不同之处。
您决定需要实现构建系统的自动化。从理论上讲， 只需获得一台新计算机，然后对其进行设置来运行您的构建 运行脚本你仍需经历痛苦 但现在没有人脑 检测和解决小问题的能力。现在，每天早上 可以看到昨晚的构建失败了 进行了一项更改，这些更改在他们的系统上行之有效，但对自动化 构建系统每次都是一个简单的解决办法，但经常会发生，以至于您 每天要花大量时间来探索这些简单的 修复。
随着项目的扩大，构建速度会逐渐变慢。等待中的一天 您悲伤地凝视着应用的空闲桌面 有一个同事，他正在休假，希望有办法利用 所有这些都浪费了计算能力
您遇到了一个典型的规模问题。对于在 最多几百行代码，最多持续一到两周时间（此时间 一位刚刚毕业的初级开发者 只需一个编译器即可。脚本可能需要一点时间 但是，当您需要在多个开发者和 构建脚本，即使是完美的构建脚本也是不够的，因为构建 并难以解释这些机器的细微差别。此时， 这种简单的方法就会失效，是时候投资开发一个真正的构建系统了。