构建更好的软件以更好地构建软件

We manage the build pipeline that delivers Quip and Slack Canvas’s backend. A year ago, we were chasing exciting ideas to help engineers ship better code, faster. But we had one huge problem: builds took 60 minutes. With a build that slow, the whole pipeline gets less agile, and feedback doesn’t come to engineers until far too late.

我们管理着交付 Quip 和 Slack Canvas 后端的构建管道。一年前，我们在追逐激动人心的想法，以帮助工程师更快地交付更好的代码。但我们有一个巨大的问题： 构建耗时 60 分钟。构建如此缓慢，整个管道变得不够灵活，反馈直到太晚才传递给工程师。

We fixed this problem by combining modern, high-performance build tooling (Bazel) with classic software engineering principles. Here’s how we did it.

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

Thinking About Build (and Code) Performance

思考构建（和代码）性能

Imagine a simple application. It has a backend server that provides an API and data storage, and a frontend that presents the user interface. Like many modern applications, the frontend and backend are decoupled; they can be developed and delivered independently.

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

The graph of this build looks like this:

这个构建的图看起来是这样的：

An example service build graph. It shows a set of Python files building into a backend artifact and a set of TypeScript files building into a frontend artifact.

We represent the dependencies between the elements of the build, like source files and deployable artifacts, with arrows, forming a directed acyclic graph. Here, our backend depends on a collection of Python files, meaning that whenever a Python file changes, we need to rebuild the backend. Likewise, we need to rebuild our frontend whenever a TypeScript file changes — but not when a Python file does.

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

Modeling our build as a graph of clearly-defined units of work lets us apply the same kind of performance optimizations we might use to speed up application code:

将我们的构建建模为一个清晰定义的工作单元图，让我们能够应用同样的性能优化，来加速应用代码：

Do less work. Store the results of expensive work you do so that you only have to do it once, trading off memory for time.
减少工作量。存储您所做的昂贵工作的结果，这样您只需做一次，以时间换取内存。