principle-minimize-reader-load

尽量降低读者负担

可维护性取决于读者理解代码所需付出的工作。关注两个维度：

1. 追踪层数。 从问题到答案之间有多少层间接关系。
2. 需要记住的状态。 读者必须在脑中保留多少隐藏或可变的上下文。

原因： 代码被阅读的次数远多于编写的次数。代码行数、圈复杂度和“整洁架构”都只是衡量指标。真正重要的是读者负担。这两个维度彼此独立。一个有 50 个全局变量的扁平文件，可能和 6 层适配器堆栈一样难以推理。两者都要把控。这是 Guard the Context Window 的人类对应版本。读者的工作记忆也有限。

做法：

• 合并代价大于收益的层： 只有一个调用者的包装器、没有第二种实现的适配器，以及从未真正需要的推测性间接层。将它们内联。
• 让相邻层改变抽象。 如果某一层只是重复相同的方法和参数，无法起到压缩作用，就会增加读者负担。合并纯转发层。
• 要求接口具备压缩能力。 如果宽泛的接口隐藏的复杂性很少，读者就得同时了解接口和实现。优先选择能够隐藏重要决策的边界。
• 缩小状态范围： 优先选择纯函数（返回值优于修改状态）、局部变量优于字段、字段优于模块状态、模块状态优于全局变量。尽量推导，避免同步。
• 在边界处命名不变量， 而不是在每个使用方中重复说明，让读者只需了解一次。
• 在新增一层或一项状态之前，先问：它能否在别处至少同等程度地降低读者负担？

检验方法： 新读者能否在 30 秒内回答“X 从哪里来？”和“什么会改变 X？”如果不能，就减少层数或状态。