读前：这一章要回答什么

第 2 章的结论是：复杂性由成百上千个小依赖、小模糊累积而成，单看每一个都无伤大雅。这一章顺着这个结论追问：既然没有哪一个小妥协是致命的，那么决定系统走向的，就是开发者面对每个任务时的心态。

作者把两种心态叫作战术式编程（tactical programming）和战略式编程（strategic programming），并给出了一个具体到百分比的建议。这一章没有技术细节，但它是全书的"动机篇"：后面每一章都在教你怎么投资，而这一章说明为什么要投资、投多少。

核心观点

Your primary goal must be to produce a great design, which also happens to work.— 第 3.2 节

心智模型：两个方向相反的循环

两种心态的差别不在某一次决定，而在它们各自形成的循环。战术式的循环越转越紧，战略式的循环越转越松：

战术式循环最可怕的地方，是它很难跳出来：乱到一定程度时，清理要花好几个月，进度不允许；只修一两处又看不出效果（第 2 章说过，复杂性没有单个罪魁祸首）。于是最理性的选择似乎还是继续打补丁。作者说，一旦走上战术式的路，就很难再改。

投资多少、多久回本：一个玩具模型

作者在 3.3 节建议把大约 10%～20% 的总开发时间用于投资：一开始项目会慢 10%～20%，几个月内开始受益，不久之后就会比纯战术式至少快 10%～20%，此后投资就变成"免费"的了。作者估计回本期大约 6～18 个月，同时明确说：这只是个人观点，没有数据。

下面这个模型可以帮你体会这个论证的结构，但请记住它只是本站编的玩具，参数是随手定的，不是书里的数据，也不是任何测量结果。

玩一玩之后，你应该能看到作者论证的几个要点：战略队一开始一定落后；交叉点出现在"复杂度开始明显拖慢战术队"之后；推迟投资不只是晚几周受益，而是要先还清已经积累的复杂性。也请注意模型证明不了什么：交叉点在哪里完全取决于那几个随手定的常数。现实中它取决于代码会被改多少次、团队换人多快、开发者多久会忘掉代码细节。作者给的理由正是最后这一条：代码过几个月，写的人就忘了当时的想法，复杂的代码会让后续开发明显变慢。

一个原创例子：上线前一天的评审

明天上线，需求是"连接时开启 TCP keepalive"。connect() 已经有 6 个参数，项目里有 23 个调用点。两种改法：

Conn connect(const std::string& host, int port, int timeoutMs,
             bool useTls, bool verifyCert, int retries,
             bool keepAlive = false);             // 新增，默认值保证 23 个调用点不用改

// 需要的地方
auto c = connect(host, 443, 3000, true, true, 2, true);

struct ConnectOptions {
    std::chrono::milliseconds timeout{3000};
    bool useTls = false;
    bool verifyCert = true;
    int retries = 0;
    bool keepAlive = false;                         // 新增
};
Conn connect(const std::string& host, int port, const ConnectOptions& opts = {});

// 需要的地方（C++20 指定初始化）
auto c = connect(host, 443, {.useTls = true, .retries = 2, .keepAlive = true});

这就是作者说的"小额投资"：一两个小时，不会耽误上线，却让这一类改动从此变便宜。反过来，如果每次都选左边，这个函数的参数表会一年比一年长，直到没人敢动它。训练场里还有几道上线压力下的决策题。

创业公司、Facebook 与 Google

3.4 节讨论了战略式编程最常见的反对理由：我们现在等不起。作者的回应可以整理成下表（右列是本站的评注）：

作者用 Facebook 作为鼓励战术式编程的例子（早年的口号 "Move fast and break things"，新人入职第一周就往生产环境提交代码），说它作为公司极为成功，但代码库因此吃了苦头，后来口号也改成了强调稳固基础设施的版本。作者随即补充：Facebook 的代码大概并不比一般创业公司差，只是特别显眼。与之对照的是同时期成长起来、更重视代码质量和设计的 Google 和 VMware，它们的技术文化在招聘上几乎无人能敌。

作者的结论很克制：两种路线的公司都能成功；只不过在一个重视设计、代码干净的公司里工作，要有意思得多。

边界与反方

练一练

本章的题目大多是"上线压力下怎么选"。没有标准答案的地方，解析会说明另一种选择在什么条件下合理。

再加一道，取材于读者讨论组（对应上面"边界与反方"里的"讨论组"一栏）：

本章共 12 道题，全部在训练场。

自测题

小结与读后一句话

• 战术式编程追求尽快能跑，每次引入一点复杂性；战术龙卷风是它的极端形态。
• 能跑的代码还不够：首要目标是好的设计，它恰好也能跑。
• 投资分主动（试几种设计、设想变化、写文档）和被动（发现问题就修在根上）。
• 作者建议拿出约 10%～20% 的时间，以小额、持续的方式投资；回本期 6～18 个月是作者的个人估计。
• 技术债大多永远还不清；"忙完再清理"是滑坡。两种公司都能成功，但战略式更省钱，也更有意思。

知道了要投资，下一个问题是投在哪里。第 4 章给出全书最核心的答案：把模块做深。

读后一句话：用你自己的话写下这一章最重要的一个观点，最好结合你最近的一次取舍。