FDE 该读的这本 Google 书，不教你写代码

一本书名带 Google 的书，第一章讲的不是算法，也不是架构，而是一句简短的定义：软件工程是在时间维度上累积的编程。

这句话是理解《Software Engineering at Google》的钥匙。该书由 Titus Winters、Tom Manshreck 和 Hyrum Wright 合著。据 Google Research 的页面，本书由 O’Reilly 于 2020 年出版；作者在 Abseil 上的页面给出的发布时间是 2020 年 3 月。

对想做前线部署工程师（FDE）的人来说，这本书比大多数“整洁代码”类书籍更值得读。想想这份工作：如果你在客户那里写的代码，在你转去其他项目之后还在运行，那么书中关于时间的问题，也就是你的问题。

不是讲编码的书，也不是讲设计的书

Abseil 页面说得很直白：这本书讲的其实不是编程，而是 Google 的工程实践。前言说得更进一步：这本书不讲软件设计。全书内容分为三组：文化、流程和工具。

作者还特意说明，书中描述的经验并不是要规定你的组织该怎么做。这一点对 Google 以外的读者都很重要。你不会有 Google 规模的 monorepo，也不会有专门的工具团队，所以读这本书，要学的是它提出问题的方式，而不是照搬它的流程。

还有一个实际的好处：作者在 abseil.io/resources/swe-book 提供免费的 HTML 版，同时也鼓励想支持这项工作的读者购买 O’Reilly 的纸质版。

观点一：代码要比项目活得更久

书中指出，编程与软件工程有三个核心区别：时间、规模和权衡。只运行一次的脚本是编程；在客户那里运行三年、经手好几代工程师的数据管道，是软件工程。

在此基础上，书中把可持续的代码库定义为：凡是应该修改的东西，你都有能力修改。这个定义与代码是否优雅无关，关心的是修改的能力：替换一个库、修补一个安全漏洞、迁移到新的运行时版本，而系统不会崩溃。

假设你为一家银行部署了一个 Agent。六个月后，基础模型发布新版本，SDK 也改了接口。如果你离开后客户无法自行升级，那么无论交付当天的演示多么出色，这次部署都不可持续。

观点二：每一种行为都会有人依赖

第 1 章提出了 Hyrum 定律，以合著者 Hyrum Wright 命名。其要义是：当一个系统的用户足够多时，它的每一种可观察行为都会有人依赖。

对 FDE 来说，这条定律几乎能解释每一次“可我什么都没改”的事故。设想你为客户做了一个 API，它返回结果的顺序是文档从未承诺过的。客户的报表团队却悄悄依赖着这个顺序。你优化了查询，顺序变了，高管看板上的数字就错了。

这里要养成的本能是，在改动任何东西之前先问：谁在读这份输出？他们怎么读？他们可能依赖着哪些你从未承诺过的东西？

观点三：升级是权衡，不是原则

这本书并不主张永远升级。是否升级，取决于升级的成本、带来的价值以及项目的预期寿命。一个只存活三周的原型，不需要和一个运行十年的核心系统遵循同样的纪律。

面试小建议：如果被问到某个艰难的技术决策，就用这三个变量来讲述。讲清成本、价值和项目寿命的回答，比“我选了最新的技术”更有说服力。

谁该读，从哪里读起？

如果你有两到四年经验，只在单一产品里做过功能开发，就从前言和第 1 章读起。这两部分足以改变你看待自己工作的方式。之后再按文化、流程、工具三组往下读，先读与你眼下问题最相关的那一组。

如果你有五到八年经验，曾让系统挺过多次升级，这本书会给你一套词汇，帮你说清自己经历过的事。这套词汇在面试中很有价值，在说服客户暂时不要升级时也用得上。

如果你想找一本讲系统设计的书，那就不是这本了，作者自己也这么说。

衡量一个好的 FDE，要看一个在演示时很少有人问的问题：你离开一年后，客户的系统还能修改吗？