读前：这一章要回答什么

第 1 章很短，没有代码，也没有正式提出任何原则。但它定下了全书的基调：作者把软件设计的全部问题收束到一个词上，复杂性（complexity）。后面每一章，无论讲模块、异常、注释还是命名，最终都要回到同一个问题：这样做让系统更容易理解和修改了吗？

这一章还交代了两件对你读书方式影响很大的事：一是作者认为设计不是项目开头的一个阶段，而是贯穿软件一生的持续活动；二是这本书该怎么用，作者的答案是配合代码评审、学会认红旗。本站的训练场就是照着这个思路搭的。

核心观点

The greatest limitation in writing software is our ability to understand the systems we are creating.— 第 1 章开头

心智模型：两条路，和这本书的地图

先把作者给的两类办法画出来。左边是"消除"：复杂性直接没了；右边是"封装"：复杂性还在，但被关进了模块，大多数人大多数时候看不见它。书的主体（第 4～11 章）大多在讲第二条路怎么走好，但第一条路贯穿全书。下图把各章大致归了类，这是本站的整理，不是原书的划分，不少章节两边都沾。

下面用一个小例子把两条路走一遍：一个网络服务里的收包队列，生产者往里放包，满了就丢弃并计数。

// 网络线程（为简化，假设单线程）
if (count == kCap) {
    dropped++;
} else {
    ring[tail] = pkt;
    tail++;
    if (tail == kCap) tail = 0;   // 回绕：特殊情况
    count++;                      // count、head、tail 三者要保持一致
}
// 工作线程里还有一段对称的 head 处理，同样有回绕判断

// head、tail 只增不减（uint64_t，实际不会溢出），
// 元素个数就是 tail - head，下标取模即可，不再需要 count 和回绕判断。
if (tail - head == kCap) {
    dropped++;
} else {
    ring[tail++ % kCap] = pkt;
}

// 固定容量的包队列。满时 tryPush 返回 false，空时 tryPop 返回 nullopt。
class PacketQueue {
public:
    bool tryPush(const Packet& p);
    std::optional<Packet> tryPop();
};

if (!queue.tryPush(pkt)) dropped++;

两条路不是二选一：第三个面板的实现里，用的正是第二个面板的写法。先尽量消除，消除不了的再封装。至于"封装进一个类"什么时候值得、什么时候只是多了一层，第 4 章会给出判断标准。

这本书怎么读，本站怎么用

作者坦白说，书里的原则偏抽象，又很难找到"小到能放进书里、又大到能体现真实问题"的例子，所以光读书可能不够。作者的建议是把书和代码评审结合起来：读别人代码的时候，想想它是否符合书里的概念、和代码的复杂程度有什么关系。

本站按这个思路分成三层，建议每章按顺序走一遍：

每一章建议这样走

1. 读前（5 分钟）：看本站这一章的"读前"和"读原书时留意"，记住那三个问题。
2. 读原书：带着问题读。本站不翻译、不复述原书，很多关键论证只在原书里。
3. 读后（15 分钟）：回来看核心观点、原创例子和"边界与反方"，做自测题。自测错了，回原书找对应小节。
4. 训练：去训练场做本章的题。答错的题 10 分钟后会再出现，答对的按间隔复习逐渐拉长间隔。
5. 动手：有项目任务的章节，在 minikv 上做对应的重构；最后在页面底部写下"读后一句话"。

另外还有速查页（全部红旗和原则，各配一个小例子）和几篇专题，例如APOSD 与 Clean Code 的分歧。

红旗与代码评审

作者认为，提高设计能力最好的办法之一是学会认红旗（red flag）：一段代码可能比它需要的更复杂的迹象。书中会在各章陆续指出红旗，书末汇总了最重要的十几个。第 1～3 章还没有正式的红旗，第 4 章的"浅模块"是第一个。

When you see a red flag, stop and look for an alternate design that eliminates the problem.— 第 1.1 节

这句话里有两个容易忽略的要求。第一是停下来：红旗出现时你通常正忙着让功能跑起来，最自然的反应是"先这样吧"。第二是找替代设计，而不是在原设计上打补丁。作者还提醒，刚开始可能要试好几种方案才能消掉一个红旗，不要轻易放弃，试得越多学得越多；久而久之你的代码红旗会越来越少，你也会自己发现新的红旗。

为什么要配合代码评审？作者给的理由很朴素：看别人代码里的设计问题，比看自己的容易；评审还能让你见到新的设计思路和编程技巧。本站补充一个写评审意见的小模板，你可以在训练场的题目里反复练：

位置：文件和行号
现象：看到了什么（哪个红旗 / 哪种复杂性症状）
后果：以后谁、在什么情况下会因此多花力气或出错
替代：至少一种更好的设计（最好两种，并说明你的倾向）

这四行里最重要的是"后果"：它把"我觉得不好看"变成"它会让以后的修改变难"，这正是第 2 章给复杂性下的定义。

边界与反方

练一练

第 1～3 章还没有红旗，题目以判断和设计选择为主。先自己判断，再看解析。

自测题

小结与读后一句话

• 软件的瓶颈是理解：复杂性会随系统演化不可避免地累积，设计的目标是延缓它、控制它。
• 两条路：消除复杂性（更简单、更显然），封装复杂性（模块化）。
• 软件设计贯穿整个生命周期，每个开发者都应该一直想着设计，并拿出一部分时间改进它。
• 原则用来比较方案，不是菜谱；每条都有边界，要适度。
• 学会认红旗，配合代码评审；看到红旗就停下来，多试几种替代设计。

下一章回答本章留下的问题：复杂性到底是什么？作者会给出一个实用的定义、三种症状和两个成因，后面全书都用这套词汇说话。

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