principle-minimize-reader-load
Compare original and translation side by side
🇺🇸
Original
English🇨🇳
Translation
ChineseMinimize Reader Load
最小化读者负担
Maintainability is the work a reader must do to understand code. Track two axes:
- Layers to trace. How many indirections sit between the question and the answer.
- State to hold. How much hidden or mutable context the reader must keep in their head.
Why: Code is read far more than it is written. LOC, cyclomatic complexity, and "clean architecture" are proxies. Reader load is the thing that matters. The two axes are independent. A flat file with 50 globals can be as hard to reason about as a 6-layer adapter stack. Guard both. This is the human analog of Guard the Context Window: working memory is finite for readers too.
The pattern:
- Collapse layers that do not earn their keep: wrappers with one caller, adapters with no second implementation, indirection introduced for a future that never came. Inline them.
- Shrink state scope: prefer pure functions (returns over mutations), locals over fields, fields over module state, and module state over globals. Derive instead of sync.
- Name the invariant at the boundary, not in every consumer, so the reader learns it once.
- Before adding a layer or a piece of state, ask: does this reduce reader load somewhere else by at least as much?
The test: Can a new reader answer "where does X come from?" and "what can change X?" in under 30 seconds? If not, cut layers or cut state.
可维护性指的是读者理解代码所需付出的工作量。需要关注两个维度:
- 追踪层级:问题与答案之间存在多少间接调用。
- 需记忆的状态:读者必须在脑海中记住多少隐藏或可变的上下文。
原因:代码的阅读次数远多于编写次数。LOC、cyclomatic complexity和"整洁架构"都是间接指标,而读者负担才是核心关键。这两个维度是相互独立的。一个包含50个全局变量的扁平文件,可能和一个6层的适配器栈一样难以推理。要同时防范这两种情况。这类似于守护上下文窗口的人类版本:读者的工作记忆也是有限的。
模式:
- 合并无价值的层级:仅被单次调用的包装器、没有第二种实现的适配器、为从未到来的未来而引入的间接调用,这些都应被合并,直接内联。
- 缩小状态作用域:优先选择纯函数(用返回值而非修改),局部变量优先于字段,字段优先于模块状态,模块状态优先于全局变量。优先推导而非同步。
- 在边界处定义不变量,而非在每个消费者中定义,这样读者只需学习一次。
- 在添加层级或状态之前,问自己:这是否能在其他地方减少至少同等程度的读者负担?
测试标准:新读者能否在30秒内回答“X来自哪里?”和“什么能改变X?”?如果不能,就削减层级或状态。