# 前言

我们是不是都这样开始写代码的？一开始就几个文件，用 `go build` 或者点一下 IDE 的编译按钮，一切都很快。
然后项目变大了。有了模块，引入了第三方库，需要打包、部署。我们开始写一些脚本，用 `Make` 或者 `Ant`。

这些脚本定义了任务（task）：先做这个，再做那个，做完他的做你的。
这很正常且直观，因为我们就是这样一步步手动操作的。

# 问题

随着团队越来越多，事情变复杂了，因为每个人的开发环境可能不一样，同样的构建脚本可能在其他人机器上就会报错，同样的鸡排其他人肠胃不好吃了要拉肚子。

>在我机器上是好的啊

怎么办？于是只能运行前先检查环境、清理环境、安装环境。

然后你会发现，速度就越来越慢了。为什么？

## 无法并行

系统知道任务 B 和 C 都依赖于 A，但它**不敢**让 B 和 C 同时开始。因为任务内部可能做任何事（比如修改同一个临时文件），并发会导致竞态条件。

为了安全，它只能线性执行

## 结果的缓存

系统**不知道**任务 `compile-utils` 的内在逻辑。它无法判断这次运行 `compile-utils` 和上次运行的结果是否应该相同。

为了绝对正确，它只能每次都重新运行

## 依赖

一个深层依赖的变动，常常导致整个链路的重建，因为系统无法进行精细的影响范围分析
![Gemini_Generated_Image_uv3g7fuv3g7fuv3g.png](https://developer.qcloudimg.com/http-save/yehe-1367556/c29481305d7e0f3e483d2f5bbc07f808.png)
# 改变

这时，基于制品的构建系统（Bazel, Pants, Buck）提出了一个根本性的范式转换：
**从“命令式”转向“声明式”。**

我们不再编写“如何构建”的脚本，而是声明“构建目标是什么”以及“它由什么构成”。比如：
```
# 这不是脚本，这是一个声明
java_library(
    name = "utils",
    srcs = ["StringHelper.java", "DateUtils.java"],
    deps = ["@com_google_guava//jar"], # 明确声明外部依赖
)
```
我们不是在命令系统，而是在**描述蓝图**。我们把所有知识（源码、依赖、构建规则）都明确地、结构化地交给了系统。

**这下，系统从“执行者”变成了“决策者”。**

 因为它现在掌握了完整的知识图谱：
- 它知道每个 `java_library` 只是一个纯函数：输入是 `.java` 文件和一些 `.jar`，输出是一个 `.class` 包。
- 它知道这个函数是确定性的：相同的输入，必然产生相同的输出。
- 它知道所有目标的依赖关系图。


事情就发生了根本的改变：
1. **安全的并发**：所有没有直接依赖关系的目标，可以绝对安全地同时编译。系统调度整个集群的资源。
2. **精确的增量构建与全局缓存**：因为函数是确定性的，所以只要输入（源文件+依赖的哈希值）没变，输出就可以从缓存中直接取出。这个缓存可以是本地的，也可以是全团队共享的远程缓存。这意味着，如果你的同事刚刚编译过 `utils` 库，那么你构建时几乎可以瞬间得到结果。
3. **可重现性**：整个构建过程被彻底“冻结”了。工具链版本、第三方库的确切版本（甚至哈希值）都被锁定。你可以在一年后，拉取今天的代码，得到完全相同的构建结果。
![Gemini_Generated_Image_58xyfh58xyfh58xy.png](https://developer.qcloudimg.com/http-save/yehe-1367556/2def8679f8fe18bd9ba1e3c2f345014b.png)

# 对我们的要求

**但我们要遵循更严格的纪律。** 我们必须遵循新的契约：
- **规则即法律**：你不能随意写一个脚本去“预处理”文件。所有构建动作必须封装在系统认可的“规则”里。这起初像是一种束缚。
- **依赖必须显式声明**：不能隐式地使用传递依赖。你必须明确写下所有依赖。这增加了维护成本，但换来了依赖图的清晰和可维护性。
- **环境隔离**：每个构建动作都在沙箱中运行，只能看到自己声明需要的文件。这杜绝了隐藏的依赖和副作用。


**那么，什么时候值得我们拥抱这种转变呢？**
**我觉得是这样的：**
- 新同事搭建环境需要一整天，而不是一小时。
- 构建时间从几秒变成几分钟，甚至几十分钟。
- “clean”成了解决构建问题的标准操作。
- 开始害怕升级关键第三方库的版本。
- 不同服务因为依赖了同一个库的不同版本，而在集成时出现诡异问题。

这时，引入基于制品的构建系统及其哲学（**细粒度模块、严格传递依赖、单一版本规则、版本锁定**），就不再是“过度设计”，真的。

# 总结

写到这里，内容早已不止是 Bazel之类的构建工具，而是一种应对复杂性的系统工程思维。

这关乎我们如何看待自己与工具的关系。

我们是不是愿意前期消耗一些精力，然后后期将我们从重复劳动中解放出来？

我们是不是都这样开始写代码的？一开始就几个文件，用 go build 或者点一下 IDE 的编译按钮，一切都很快。然后项目变大了。有了模块，引入了第三方库，需要打包、部署。我们开始写一些脚本，用 Make 或者 Ant。

关于构建系统的思考

十倍工程师

数据库

项目构建从简单脚本到复杂系统的演变过程，揭示了传统构建方式的痛点：环境差异、低效串行执行、重复编译。基于制品的构建系统（如Bazel）通过声明式编程实现安全并发、精确缓存和可重现构建，虽然需要遵循严格规则，但能显著提升大型项目的构建效率和可靠性。

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云AI代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

功能1上新10个字符

功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符。

功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符。

功能5描述100个字符功能5描述100个字符功能5描述100个字符功能5描述100个字符功能5描述100个字符功能5描述100个字符

功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符

功能4上新

文章&问答评论现已支持表情

全新交互，全新视觉，新增快捷键、悬浮工具栏、高亮块等功能并同时优化现有功能，全面提升创作效率和体验

社区富文本编辑器全新改版！诚邀体验～ 

精选全网热门MCP server，让你的AI更好用 🚀

💥开发者 MCP广场重磅上线！

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

关于构建系统的思考-腾讯云开发者社区-腾讯云

关于构建系统的思考

关于构建系统的思考

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐