Build better software to build software better | Engineering at Slack

November 6, 2025 · 18 min read

Build better software to build software better David Reed, Staff Software Engineer

我们管理着负责交付 Quip 和 Slack Canvas 后端的构建流水线。一年前，我们正追逐着各种激动人心的想法，以帮助工程师更快地发布更好的代码。但我们面临一个巨大的问题：构建需要 60 分钟。构建如此缓慢，使得整个流水线变得不够敏捷，工程师得到反馈的时间也过晚。

我们通过结合现代高性能构建工具（Bazel）和经典的软件工程原则，解决了这个问题。以下是我们如何做到的。

思考构建（与代码）性能

想象一个简单的应用程序。它有一个提供 API 和数据存储的后端服务器，以及一个呈现用户界面的前端。像许多现代应用程序一样，前端和后端是解耦的；它们可以独立开发和交付。

这个构建的依赖关系图如下所示：

我们用箭头表示构建元素（如源文件和可部署工件）之间的依赖关系，形成一个有向无环图。在这里，我们的后端依赖于一组 Python 文件，这意味着每当 Python 文件更改时，我们都需要重新构建后端。同样，每当 TypeScript 文件更改时，我们需要重新构建前端——但当 Python 文件更改时则不需要。

将我们的构建建模为由明确定义的工作单元组成的图，让我们可以应用与加速应用程序代码时可能使用的相同类型的性能优化：

1. 减少工作量。存储已完成的高成本工作的结果，以便只需执行一次，用空间换取时间。
2. 分担负载。将正在进行的工作分配到更多的计算资源上并行执行，以更快地完成，用计算资源换取时间。

缓存与并行化

这些技术对大多数工程师来说都很熟悉，从代码的角度思考它们有助于巩固它们如何应用于构建系统。以这个 Python 示例为例：

1
2

def factorial(n):
    return n * factorial(n-1) if n else 1

计算阶乘可能非常耗时。如果我们需要经常计算，速度会变得相当慢。但直觉上，我们知道一个数的阶乘不会改变。这意味着我们可以应用策略 1 来缓存这个函数的结果。这样，对于任何给定的输入，它只需要运行一次。

1
2
3

@functools.cache
def factorial(n):
    return n * factorial(n-1) if n else 1

缓存存储我们的输入（n）并将其映射到相应的输出（factorial() 的返回值）。n 是缓存键：它类似于构建图中的源文件，函数的输出对应于构建的工件。

细化我们的直觉，我们可以说这个函数需要具有几个特定属性，缓存才能生效。它必须是密闭的：它只使用明确给定的输入来产生特定的输出值。并且它必须是幂等的：对于任何给定的输入集，输出总是相同的。否则，缓存就是不合理的，并会产生相当令人惊讶的效果。

一旦我们有了缓存，我们就希望最大化我们的命中率：即调用 factorial() 时从缓存中获取答案的次数比例，而不是通过计算。我们定义工作单元的方式可以帮助我们保持较高的命中率。

为了说明这个想法，让我们看一个更复杂的代码片段：

1
2
3
4
5

@functools.cache
def process_images(
  images: list[Image],
  transforms: list[Transform]
) -> list[Image]: ..

这个函数附加了一个缓存，但缓存效果不佳。该函数接受两个输入集合：一个图像列表和一个要应用于每个图像的变换列表。如果调用者更改了这些输入中的任何一个，比如说在列表中添加了一个 Image，他们也就更改了缓存键。这意味着我们无法在缓存中找到结果，并且必须从头开始做所有的工作。

换句话说，这个缓存的粒度不够细，因此命中率很低。更有效的代码可能如下所示：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16

def process_images(
  images: list[Image],
  transforms: list[Transform]
) -> list[Image]:
  new_images = []
  for image in images:
    new_image = image
    for transform in transforms:
       new_image = process_image(new_image, transform)
    new_images.append(new_image)

  return new_images

@functools.cache
def process_image(image: Image, transform: Transform) -> Image:
  ...

我们将缓存移动到一个更小的工作单元——将单个变换应用于单个图像——并相应地使用更小的缓存键。我们仍然可以保留更高级别的 API；只是不在那里进行缓存。当调用者使用一组输入调用更高级别的 API 时，我们可以通过只处理我们以前未见过的 Image 和 Transform 组合来满足该请求。其他所有内容都来自缓存。我们的缓存命中率和性能都应该得到改善。

缓存帮助我们减少工作量。现在让我们看看如何分担负载。如果我们使用线程将图像处理分散到多个 CPU 核心上会怎样？

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

def process_images_threaded(
  images: list[Image],
  transforms: list[Transform]
) -> list[Image]:
  with ThreadPoolExecutor() as executor:
    futures = []
    for image in images:
      futures.append(executor.submit(process_images, [image], transforms))

    # 返回的图像可能是任意顺序！
    return [future.result() for future in futures.as_completed(futures)]

让我们找出能够并行运行工作所需的条件，同时注意一些关键的注意事项。

1. 与缓存一样，我们需要严谨且完整地定义我们想要并行化的工作的输入和输出。
2. 我们需要能够将这些输入和输出跨某种边界移动。这里是一个线程边界，但也可能是进程边界或到其他计算节点的网络边界。
3. 我们并行运行的工作单元可能以任意顺序完成或失败。我们的代码必须管理这些结果，并明确记录它所提供的保证。在这里，我们注意到图像可能不会按相同顺序返回的注意事项。这是否可以接受取决于 API。

我们工作单元的粒度也在我们能够有效并行化方面发挥作用，尽管这其中有很多细微差别。如果我们的工作单元数量少但规模大，我们就无法将它们分散到尽可能多的计算资源上。任务大小和数量之间的正确权衡因问题而异，但这是我们在设计 API 时需要考虑的问题。

过渡到构建性能

如果你是软件工程师，你可能已经多次应用这些技术来提高代码性能。让我们将这些原则和直觉应用到构建系统中。

在 Bazel 构建中，你定义构成有向无环图的目标。每个目标有三个关键要素：

1. 作为此构建步骤的依赖项或输入的文件。
2. 作为此构建步骤输出的文件。
3. 将输入转换为输出的命令。

（实际情况要复杂一些，但目前了解这些就够了）。

让我们回到最初的那个示例应用程序。

Bazel 目标定义可能类似于以下伪代码：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

python_build(
    name = "backend",
    srcs = ["core/http.py", "lib/options.py", "data/access.py"],
    outs = ["backend.tgz"],
    cmd = "python build.py", 
)
ts_build(
    name = "frontend",
    srcs = ["cms/cms.ts", "collab/bridge.ts", "editing/find.ts"],
    outs = ["frontend.tgz"],
    cmd = "npm build"
)

你可以将构建目标看作是定义（但不调用！）一个函数。注意到从上面的 Python 示例中延续下来的一些主题吗？我们详尽地定义了每个构建步骤的输入（srcs）和输出（outs）。我们可以将目标的 srcs（以及构建这些目标的任何目标的传递性 srcs，我们稍后会看到更多）视为我们希望缓存的函数的输入。

因为 Bazel 在沙箱中构建，所以将输入转换为输出的 cmds 只能接触我们声明的输入文件。而且因为我们的输入和输出只是磁盘上的文件，我们解决了跨边界移动它们的问题：它们只需要被复制！最后，我们必须向 Bazel 做出一个承诺：我们的构建步骤的 cmds 实际上是幂等且密闭的。

当我们做到这些时，我们就免费获得了一些非凡的能力。

• Bazel 自动缓存我们的构建操作的结果。当目标的输入没有变化时，使用缓存的输出——无需构建成本！
• Bazel 将构建操作分布到我们允许的尽可能多的 CPU 核心上，甚至可以分布到构建集群中的多台机器上。
• Bazel 只执行我们需要用于所需输出工件的那些操作。换句话说，我们总是为所需的输出运行最少量的必要工作。

就像在我们的代码示例中一样，当我们拥有一个明确定义的依赖图，由幂等、密闭且粒度适中的构建单元组成时，我们将从 Bazel 的魔力中获得最大收益。这些品质使得 Bazel 的原生缓存和并行化能够带来巨大的速度提升。

理论说够了。让我们深入探讨实际问题。

为什么 Quip 和 Canvas 更难构建

关键在于：Quip 和 Canvas 比我们之前看的简单示例要复杂得多。这是我们为了理解构建如何工作而绘制的一个真实图表。不必担心阅读所有细节——在深入探讨问题和解决方案时，我们将使用一个示意图版本。

当我们分析这个图时，发现了一些关键缺陷，这意味着我们没有获得从 Bazel 获得速度提升所需的特征：

• 有向无环依赖图 → 该图定义不明确，实际上包含循环！
• 幂等、密闭、大小合适的工作单元。 → 构建执行单元非常庞大，并非所有都是幂等的，并且由于许多构建步骤会修改工作目录，密闭性是一个挑战。
• 细粒度的缓存键以保持高缓存命中率。 → 我们的构建相互关联如此紧密，以至于我们的缓存命中率为零。想象一下，我们尝试调用的每个缓存的“函数”都有 100 个参数，其中总是有 2-3 个会发生变化。

如果我们一开始就强行将 Bazel 应用于构建，那将是无效的。在缓存命中率为零的情况下，Bazel 的高级缓存管理无济于事，而且 Bazel 并行化相比构建代码中已经存在的临时并行化几乎不会增加任何好处。为了获得 Bazel 的魔力，我们首先需要做一些工程工作。

分离关注点

我们的后端代码和构建代码是紧密交织在一起的。在没有类似 Bazel 的构建系统的情况下，我们默认使用应用程序内框架来协调构建图中的各个步骤。我们使用 Python 的多进程策略和核心代码库内置的异步例程来管理并行化。Python 业务逻辑整合了 Protobuf 编译并构建了 Python 和 Cython 工件。最后，由更多 Python 脚本协调的 tsc 和 webpack 等工具，将 TypeScript 和 Less 转换为 Slack Canvas 和 Quip 的桌面及 Web 应用程序使用的独特前端捆绑包格式。

当我们开始解开这个复杂的结时，我们专注于后端和构建代码的结合如何扭曲了前端构建的图。以下是该图的一个更易于理解的表示。

请注意，我们的前端捆绑包的依赖树是多么“庞大”。它不仅包括它们的 TypeScript 源代码和构建过程，还包括整个构建好的 Python 后端！这些 Python 源文件和工件是每个前端捆绑包的传递性源。这意味着，不仅 TypeScript 更改，而且每一个 Python 更改，都会改变前端的缓存键（我们之前提到的数百个参数之一），需要进行昂贵的完全重建。

这个构建问题的关键在于 Python 应用程序和 TypeScript 构建之间的那条依赖边。

这条边平均每次构建要花费我们 35 分钟 —— 超过总成本的一半！—— 因为每次更改都会导致完整的后端和前端重建，而前端重建尤其昂贵。

在解决这个问题的过程中，我们意识到性能成本不仅仅是一个构建问题。它是我们在整个应用程序中普遍未能分离关注点的一个症状：后端、前端和构建代码。我们存在耦合：

• 在我们的后端和前端之间
• 在我们的 Python 和 TypeScript 基础设施及工具链之间
• 在我们的构建系统和应用程序代码之间

除了使构建性能在定量上更差之外，这些耦合在我们的软件开发生命周期中也产生了定性影响。工程师无法推理他们所做后端更改的潜在影响范围，因为它也可能破坏前端。或者破坏构建系统。或者两者都破坏。而且因为我们的构建需要一个小时，我们无法通过在拉取请求级别运行构建来给他们早期警告。缺乏健康信号，以及推理潜在后果的困难，意味着我们太频繁地破坏我们的构建和主分支，而这不是我们工程师的错。

一旦我们通过关注点分离的视角理解了问题，就清楚地认识到，仅靠构建系统的更改无法成功。我们必须彻底切断前端与后端、Python 与 TypeScript、应用程序与构建之间的依赖关系。这意味着我们必须投入比原计划多得多的时间。

在几个月的时间里，我们煞费苦心地梳理了每个构建步骤的实际需求。我们用 Starlark（Bazel 用于构建定义的语言）重写了 Python 构建编排代码。Starlark 是一种故意受限的语言，其限制旨在确保构建满足 Bazel 生效的所有要求。用 Starlark 构建有助于我们强制执行与应用程序代码的完全分离。在需要保留 Python 脚本的地方，我们重写了它们，以移除除 Python 标准库之外的所有依赖：没有指向我们后端代码的链接，也没有额外的构建依赖。我们去掉了所有的并行化代码，因为 Bazel 会为我们处理。我们将在下面关于分层的思考中重新审视这个范式。

原始构建代码的复杂性使得定义“正确”行为具有挑战性。我们的构建代码大多没有测试。判断是否正确的唯一标准是在特定配置下现有构建系统产生的结果。为了让自己放心，并给工程师们注入信心，我们用 Rust 构建了一个工具，用于比较现有流程产生的工件与新代码产生的工件。我们利用差异来指导我们找到新逻辑不完全正确的点，然后迭代，再迭代。

当我们最终能够绘制出一个新的构建图时，这项工作得到了回报：

我们已经切断了所有三个关键耦合，并且排除了任何 Python 更改可能破坏构建或改变前端输出的担忧。我们的构建逻辑与它构建的单元一起位于 BUILD.bazel 文件中，具有明确定义的 Starlark API 以及构建代码和应用程序代码之间的清晰分离。我们的缓存命中率大大提高，因为 Python 更改不再构成 TypeScript 构建缓存键的一部分。

这项工作的成果是构建时间的大幅减少：如果前端被缓存，我们可以在短短 25 分钟 内构建整个应用程序。这是一个很大的改进，但还不够！

通过分层设计实现可组合性

一旦我们切断了后端 ←→ 前端的耦合，我们就更仔细地研究了前端构建。为什么它需要 35 分钟？当我们梳理构建脚本时，发现了更多关注点分离的挑战。

我们的前端构建器曾经努力追求性能。它接收一大组输入（TypeScript 源文件、LESS 和 CSS 源文件，以及由环境变量和命令行选项控制的各种旋钮和开关），计算需要执行的构建活动，将该活动并行化到一组工作进程上，并将输出整理成可部署的 JavaScript 捆绑包和 CSS 资源。以下是这部分构建图的草图。

与我们在本项目中发现的大部分情况一样，这个策略代表了编写时的一系列合理权衡：在缺乏更大构建框架的情况下，这是一种务实地尝试加速构建某一部分的做法。而且它比不并行化相同工作更快！

这种实现有两个关键挑战。

1. 就像我们上面的 process_image() 示例一样，我们的可缓存单元太大了。我们接收所有源文件并产生所有捆绑包。如果只有一个输入文件更改了怎么办？这改变了缓存键，我们必须重新构建所有内容。或者，如果我们想只构建一个捆绑包以满足构建过程中其他地方的需求怎么办？我们运气不好；我们必须依赖整个庞大的过程。
2. 我们正在跨进程并行化工作，这很好——除非我们可以跨机器并行化，而机器拥有更多的 CPU 核心。如果我们有这些可用资源，我们在这里无法使用它们。而且我们实际上使 Bazel 在其并行化独立构建步骤的核心功能上效果降低：Bazel 和脚本的工作进程正在争夺同一组资源。脚本甚至可能在并行化 Bazel 已经知道不需要的工作！

在这两个方面，我们很难以新的方式组合构建功能：要么是以不同的形式编排多个捆绑包构建，要么是采用不同的并行化策略。这是一个分层违规。

如果我们像这里一样，从操作系统到应用层绘制能力层级，我们可以看到构建器的边界横跨了多个层级。它结合了业务逻辑、任务编排框架的重要部分以及并行化。我们真正想要的只是顶层——逻辑——这样我们就可以在新的编排上下文中重新组合它。我们最终得到了一个工作编排器（构建器）嵌套在另一个工作编排器（Bazel）内部，两个层级争夺着同一个资源池的份额。

为了更有效，我们实际上只需要做得更少。我们删除了大量代码。新版本的前端构建器要简单得多。它不进行并行化。它有一个小得多的“API”接口。它接收一组源文件，并构建一个输出捆绑包，TypeScript 和 CSS 被独立处理。

这个新的构建器具有高度的可缓存性和可并行性。每个输出工件都可以独立缓存，仅以其直接输入为键。一个捆绑包的 TypeScript 构建和 CSS 构建可以并行运行，既可以相互并行，也可以与其他捆绑包的构建并行。我们的 Bazel 逻辑可以决定范围（一个捆绑包？两个？全部？），而不是试图管理所有捆绑包的构建。

再次看到与我们的示例 process_images() API 的共鸣了吗？我们创建了细粒度的、可组合的工作单元，这极大地提高了我们并行化和缓存的能力。我们还分离了业务逻辑及其编排的关注点，使我们能够在新的 Bazel 构建中重新组合逻辑。

这个改变给我们带来了一些非常好的结果：

• 由于捆绑包构建以及 TypeScript 和 CSS 构建可以相互独立地缓存，我们的缓存命中率提高了。
• 如果有足够的资源，Bazel 可以同时并行化所有捆绑包构建和 CSS 编译步骤。这为我们带来了完全重建时间的显著减少。

作为一个额外的好处，我们不再运行自己的并行化代码。我们已经将该职责委托给了 Bazel。我们的构建脚本只有一个关注点：围绕编译前端捆绑包的业务逻辑。这对可维护性来说是一个胜利。

成果与启示

我们使构建速度大大加快。更快的构建带来工程师更短的周期时间、更快的事件解决和更频繁的发布。在将这些原则应用到我们的整个构建图之后，我们获得的构建速度比开始时快了多达六倍。

从定性的角度来看，我们得出的关键原则是：软件工程原则适用于整个系统。而整个系统不仅仅是我们的应用程序代码。它还包括我们的构建代码、发布流水线、开发和生产环境的设置策略，以及这些组件之间的相互关系。

因此，无论你是在编写应用程序代码、构建代码、发布代码还是所有这些代码，我们向你提出这个建议：分离关注点。思考整个系统。为可组合性而设计。当你这样做时，你应用的每个方面都会变得更强大——并且，作为一个愉快的副作用，你的构建也会运行得快得多。