认知负荷才是关键：以人脑工作记忆为约束的软件设计实践指南

本文以开源仓库 cognitive-load（项目定位：🧠 Cognitive load is what matters）的核心文档 README.tr.md 为骨架，系统拆解"认知负荷"这一软件开发中最容易被忽视的隐形成本：它是什么、由哪两类构成，以及如何用十多种可落地的实战手段把代码中的外在认知负荷降到最低。读完本文，你将掌握一套覆盖条件表达式、模块划分、微服务粒度、语言特性取舍与架构选型的降负荷方法论，并能直接把它用于日常代码评审、结对编程与架构审查。

在开始之前，请记住一个事实：人类阅读代码的时间远多于书写代码的时间。所以每写下一行代码之前，都应该问自己一句——"我是不是给代码塞进了过量的认知负荷？"（原文表述见 README.tr.md 的 Giriş 部分）。尤其在 AI 时代，当我们需要用自己的人脑去审查大量 LLM 生成的代码时，这个问题比以往任何时候都更加重要（这一点在主英文文档 README.md 的 Introduction 中有明确强调）。

认知负荷是什么：一个来自人脑的硬约束

认知负荷，是开发者为了完成一项任务需要动多少脑子。

阅读代码时，我们需要在脑海中临时容纳变量的取值、控制流逻辑、函数调用序列等信息。而普通人的工作记忆大约只能同时容纳 4 个这样的信息块。一旦认知负荷逼近这个阈值，理解代码就会变得异常困难。

假设我们被要求去修复一个完全陌生的项目，并且被告知"之前有一位非常聪明的开发者参与过"——酷炫的架构、花哨的库、时髦的技术一应俱全。听起来很棒，但换个角度说：这位作者其实是为我们制造了极高的认知负荷。作为接手者，我们需要把散落在各个抽象层里的隐含信息逐一重新装回自己的工作记忆，才能开始动工。

因此，我们应该尽可能降低项目中的认知负荷。文档还特别提醒：认知负荷与"打断"（interruption）关系密切——每被打断一次，工作记忆里暂存的信息就面临一次丢失与重建的成本。

需要说明的是，本文（与源文档一致）是在非正式意义上使用"认知负荷"这一术语：它有时与认知科学的正式概念重合，但作者并不追求严格对号入座，够用即可。

两类认知负荷：内在的不可削减，外在的必须削减

• 内在负荷（Intrinsic）——由任务本身的固有难度引起。它位于软件开发的核心，无法削减，因为这是问题领域天然携带的复杂性。
• 外在负荷（Extraneous）——由信息的呈现方式引入，由与任务无直接关系的因素造成，例如"聪明作者"的各种个人癖好。这类负荷可以大幅削减，也正是本文要集中火力解决的问题。

为了让"认知负荷水平"可被直观讨论，源文档引入了一套简易标注体系，全文贯穿使用：

• 🧠：工作记忆刚刚清空，认知负荷为零
• 🧠++：工作记忆里已有两个事实，认知负荷上升
• 🤯：认知过载，超过 4 个事实

我们的大脑远比这个模型复杂，但这个简化模型足以支撑本文的全部讨论。

实践一：复杂的条件表达式——用语义化中间变量换回工作记忆

源文档用一个 Go 示例展示最典型的"一读就懵"场景：

if val > someConstant // 🧠+
    && (condition2 || condition3) // 🧠+++, 前一个条件必须为真，c2 或 c3 必须有一个为真
    && (condition4 && !condition5) { // 🤯, 到这个点我们已经晕了
    ...
}

读到这里，你需要同时记住：val 与常量的比较结果、条件组之间的逻辑关系、以及每个子条件的含义——三个事实叠加，工作记忆濒临过载。

重构方案是引入名字有意义的中间变量，把"事实"从大脑搬进代码：

isValid = val > someConstant
isAllowed = condition2 || condition3
isSecure = condition4 && !condition5
// 🧠, 我们不必再记忆条件本身，因为有描述性变量
if isValid && isAllowed && isSecure {
    ...
}

原理：变量名本身就是长期记忆的钩子。isValid、isAllowed、isSecure 一经声明，读者就无需在工作记忆中保留"条件到底是什么"这个事实，只需把三个已命名的布尔值"拎"起来即可。这条规则在仓库的 README.agents.md 中同样被列为给 AI Agent 的第一条硬性守则："把复杂的表达式抽取成命名有意义的中间变量，让条件可读"。

实践二：嵌套 if——用提前返回（early return）保住"快乐路径"

嵌套分支的认知成本是逐层累积的：

if isValid { // 🧠+, 好，嵌套代码只作用于合法输入
    if isSecure { // 🧠++, 只有合法且安全的输入才会走到这里
        stuff // 🧠+++
    }
}

每加深一层，读者就要在心里多挂一个前提条件。而改用提前返回之后：

if !isValid
    return

if !isSecure
    return

// 🧠, 我们不再关心之前的 return，能走到这里说明一切正常

stuff // 🧠+

效果：读者只需关注"一切正常"的快乐路径（happy path），工作记忆无需背负一堆前置条件。这正是 README.agents.md 中"优先提前返回而非嵌套 if，通过让读者只关注快乐路径来释放工作记忆"这一条的直接体现。

实践三：继承噩梦——用组合（composition）取代深继承

假设产品要求我们为管理员用户改几处逻辑：🧠

AdminController extends UserController extends GuestController extends BaseController

• 一部分功能在 BaseController 里，得去看一眼：🧠+
• 基础角色机制是在 GuestController 里引入的：🧠++
• UserController 里又改动了一些行为：🧠+++
• 终于到了 AdminController，可以写代码了：🧠++++

但等等——还有 SuperuserController extends AdminController。改 AdminController 可能会连带破坏继承自它的类，所以还得先去翻 SuperuserController：🤯（认知过载）。

为了搞清楚一个改动的影响面，读者被迫在一整条继承链里来回跳转，工作记忆被各层职责的碎片塞满。结论很明确：优先使用组合而非继承，不要强迫读者跨多个类去追踪行为（这句也是 README.agents.md 的原文规则）。关于组合与继承的详细论证，互联网上有大量优质材料，此处不再展开。

实践四：浅层模块泛滥——拥抱"深层模块"（deep module）

先给出源文档的核心定义（此语境下 method、class、module 可以互换）：

• 深层模块（Deep module）——接口简单，内部却完成复杂且强大的工作。
• 浅层模块（Shallow module）——接口相对复杂，但提供的功能其实很简单。

"方法不能超过 15 行""类应该尽可能小"之类的软件教条，经时间检验大多并不成立。当浅层模块过多时，理解项目会变得异常困难——因为你不仅要记住每个模块各自负责什么，还要记住它们彼此之间如何交互。 想弄懂一个浅层模块的用途，往往得先去看所有与它相关的模块。在大量浅层组件之间来回跳转，是极其耗费心智的；线性思维（linear thinking）才更符合人类本能。信息隐藏（information hiding）是软件设计中至关重要的原则，而浅层模块恰恰藏不住多少复杂性。

作者用亲历的实验佐证：两个约 5000 行的个人项目，第一个有 80 个浅层类，第二个只有 7 个深层类。在 1.5 年未维护后回头再看——第一个项目里 80 个类如何互相连接，几乎要像解绳结一样费力，必须在编码前重建海量认知负荷；而第二个项目因为类少、接口简洁清晰，几乎瞬间就能重新上手。

最好的组件，是那些提供强大功能却拥有简单接口的组件。 —— John K. Ousterhout，《A Philosophy of Software Design》

最经典的深层模块范例是 Unix 输入/输出系统。它的接口只有五个基本函数：

open(path, flags, permissions)
read(fd, buffer, count)
write(fd, buffer, count)
lseek(fd, offset, referencePosition)
close(fd)

而这一接口的现代实现可能包含数十万行代码——大量复杂性被隐藏在其下，但正因接口简单，使用起来毫不费力。源文档还提醒：不要误会这里是在为臃肿的 God 对象（职责过多的"上帝对象"）辩护，恰恰相反。

资料延伸：该深层模块案例出自 John K. Ousterhout 的《A Philosophy of Software Design》，书中还包含对 Parnas 经典论文《On the Criteria To Be Used in Decomposing Systems into Modules》的出色诠释。围绕"小函数是否有害""是否该停止推荐 Clean Code"的讨论，也值得一读。

实践五："单一职责"的正确解读——对"一个人"负责，而非"一件事"

很多时候，我们遵循"一个模块只应负责一件事"的模糊原则，结果造出一堆浅层模块。可是"一件事"到底指什么？实例化一个对象也是"一件事"，那么 MetricsProviderFactoryFactory 这样的类是不是也合情合理？这类类的名字和接口，比它们的整个实现还要烧脑——这算哪门子抽象？ 一定是哪里出了问题。

源文档给出了正解：

一个模块，应当且仅当对一个用户或利益相关者负责。

这才是"单一职责原则（SRP）"的真正内涵。直白地说：如果我们在一个地方引入了 bug，随后两个不同的业务方都来投诉，那我们就违反了该原则——这跟模块里"做了几件事"无关。

但即便这样理解，这条规则在今天也可能弊大于利——因为它的解释空间和人一样多。更好的判断方式，是看它产生了多少认知负荷：要时刻记住"某处的改动会在不同业务流中引发连锁反应"，本身就是一件极其费神的事。仅此而已，没有需要背诵的时髦术语。

实践六：浅层微服务泛滥——"分布式的单体"是难以修复的灾祸

深层/浅层原则与规模无关，同样适用于微服务架构。过多的浅层微服务毫无益处——行业正在转向所谓的"宏服务"（macroservices），即不那么浅（=更深）的服务。过度拆分最可怕的产物，就是被称为"分布式单体"（distributed monolith）的形态：名义上分布式，实际上被隐式依赖层层织死，是最难修复的坏味道之一。

作者讲过一个真实咨询案例：一个 5 人团队在初创公司里搞出了 17 个微服务，进度落后 10 个月，距离上线遥遥无期。每来一个新需求，至少要在 4 个以上的微服务里改代码；跨服务集成问题几乎无法复现和排查；无论是上市时间还是认知负荷都高到不可接受。🤯

面对新系统的不确定性，正确姿势是什么？关键原则是：尽可能晚地做决策——但要晚到仍然能负得起责任的那个点，因为那时你手中的信息最多。而一上来就引入网络层，等于从第一天起就把设计决策变得难以逆转。团队唯一的辩护居然是"FAANG 公司证明了微服务架构有效"——该醒醒了。

历史是最好的老师：Tanenbaum–Torvalds 论战中，微内核设计在"理论和审美"上似乎占尽优势；然而三十多年过去，微内核路线的 GNU Hurd 至今仍在开发中，而单体内核的 Linux 无处不在——包括承载本页面的服务器。一个真正设计良好、模块边界清晰的单体，往往比一堆微服务更灵活，维护时的心智成本也低得多。只有当"各模块需要独立部署"成为硬性需求（例如为了扩展开发团队规模）时，才应该在模块之间引入网络层——也就是未来的微服务。

实践七：特性丰富的语言——限制选择，本身就是降负荷

编程语言发布新特性时我们总是兴奋，花时间学习、基于新特性写代码。但如果特性过多，我们可能为几行代码就纠结半小时"该用这个还是那个"——这本身就是浪费时间。更糟的是：几个月后回来读这段代码时，你还得把当初的思考过程完整重演一遍。

你不仅要理解这个复杂的程序，还要理解程序员在浩如烟海的特性中，为什么偏偏选这种方式来解决问题。 🤯

这段话出自 Rob Pike 之口。源文档引用其核心观点：

通过限制选项的数量来降低认知负荷。

语言特性本身没有问题，前提是它们彼此正交（orthogonal），即相互独立、不产生新的组合爆炸。

为了说明语言特性堆叠带来的痛苦，源文档收录了一位拥有 20 年 C++ 经验工程师的自述（可展开阅读），要点包括：

• RSS 里积压了约三百篇 C++ 文章，一年没读，反而感觉良好；
• 最黑暗的角落（各类未定义行为）积累的经验不可复用；
• requires ((!P<T> || !Q<T>)) 与 requires (!(P<T> || Q<T>)) 中 || 的含义截然不同（前者是约束析取，后者是经典逻辑或）；
• C++20 修复了 trivial 类型 memcpy 不能开启对象生命周期的问题，但语言的认知负荷只增不减——必须记住"什么被修复了、何时修复的、修复前什么样"；
• 初始化方式从 20 种变成 21 种，initializer list 构造函数的选取规则几乎无人能背；
• 结论振聋发聩："这份增长的认知负荷并非来自业务任务，也非领域固有复杂度，而纯粹是历史原因堆积出来的外在认知负荷。"

实践八：业务逻辑与 HTTP 状态码——用自描述字符串替代需要记忆的映射

后端返回状态码时，业务语义被压进了数字：

• 401：JWT token 过期
• 403：权限不足
• 418：用户被封禁

前端工程师要实现登录功能，就必须在脑中临时装载如下映射：401 是 token 过期 🧠+；403 是权限不足 🧠++；418 是用户被封 🧠+++。前端同学（但愿）会在自己这边维护一张"数字状态码 → 含义"的字典，让后来的贡献者免于重建这份映射。

接着 QA 工程师登场了："嘿，我收到了 403，这到底是 token 过期还是权限不足？"——QA 无法直接开始测试，因为他们得先在大脑里重建后端工程师当年制造的那份认知负荷。

为什么要让这种自定义映射长期占据我们的工作记忆？更好的做法是把业务细节从 HTTP 传输协议中抽离出来，直接在响应体里返回自描述（self-descriptive）的代码：

{
    "code": "jwt_has_expired"
}

前端侧认知负荷：🧠（全新，无需记忆任何东西）；QA 侧认知负荷：🧠。同样的规则适用于所有数字状态（数据库里或其他任何地方）——优先使用自描述字符串。我们早已不在为了省内存而优化的 640K 时代了。

顺带一提：人们常花大量时间争论 401 和 403 该用哪个，各自依据自己的心智模型下判断；新开发者来了，又得重演一遍这套思考过程。就算你写了 ADR（架构决策记录）帮新人理解决策，本质上也说不太通——错误顶多能分成"用户相关"和"服务器相关"，其余部分本就模糊。另外，区分"authentication（身份验证）"与"authorization（授权）"本身就很费脑，为降低认知负荷，不妨直接用更直白的词："login（登录）"和"permissions（权限）"。

实践九：滥用 DRY——一点复制，好过一点依赖

"不要重复自己（DRY）"是每个软件工程师最早学到的原则之一，它如此深入人心，以至于看到多出来的几行代码都无法忍受。这条原则总体正确，但一旦过度使用，就会制造我们无法承受的认知负荷。

如今人人都在"逻辑分离的组件"上构建软件，这些组件往往还分布在代表不同服务的多个代码库中。当你想彻底消灭重复时，很可能在无关组件之间制造紧耦合：一处的改动在看似无关的地方引发连锁故障；单个组件难以替换或修改，因为会波及整个系统。🤯

同样的陷阱也会发生在一个模块内部：基于那些"长远看其实并不存在"的相似性，过早抽取公共功能，结果造出一堆难以修改和扩展的无用抽象。

Rob Pike 有句名言：

一点复制，好过一点依赖。

我们对"不要重新发明轮子"执念之深，以至于愿意为一个小函数引入庞大笨重的第三方库——而这个函数我们自己几行就能写完。别忘了：你引入的所有依赖，最终都是你的代码。 当某个第三方库抛错时，你需要翻阅 10 层以上的调用栈去定位问题（而错误必然会发生）——这个过程痛苦且极其消耗心智。

实践十：与框架紧耦合——把框架当库用，而不是把业务写进框架

框架里充满了"魔法"。过度依赖框架，等于强迫未来所有开发者先去学会那套魔法——这可能要花几个月。框架固然能让我们几天内把 MVP 跑起来，但长期看，它倾向于持续追加不必要的复杂性与认知负荷。

更糟的是，当新需求与框架的架构假设冲突时，框架会变成严重束缚；此时人们往往被迫 fork 框架、维护自己的定制版本。想象一下新人要创造价值，还得先学会这套私有框架——那得重建多大的认知负荷？🤯

但我们绝不是主张从零发明一切！ 正确的姿势是：用与框架解耦的方式写代码——业务逻辑不应驻留在框架内部，而应该"使用"框架的组件。把框架放在核心逻辑之外，以"库"的方式使用它。这样新人从第一天起就能为项目创造价值，而不必先趟过框架相关复杂性的泥沼。

实践十一：分层架构——当抽象只带来间接性，它就是净负债

这类架构自带某种工程浪漫。作者坦言自己曾是 Hexagonal/Onion（六边形/洋葱）架构多年的热情布道者，在各种项目里使用并鼓励其他团队跟进。结果呢？项目复杂度上升，光是文件数量就翻了一倍，大量代码像是"胶水代码"。面对频繁变更的需求，要跨多个抽象层同步修改，疲惫至极。🤯

抽象本该隐藏复杂性，而在这里它只是平添了间接性（indirection）。 为了搞清楚哪里出错、缺了什么，你必须在调用链之间来回跳转；而分层架构的层间解耦，要求你付出成倍、且常常断裂的追踪步骤才能抵达故障点——每一次追踪都要占用有限的工作记忆。🤯

这种架构起初直觉上很合理，但每次落地都弊大于利：数年不必要的脑力劳动、没有明确业务价值的胶水代码，还因为强迫新人先学我们的"心智模型"而拖慢了上市时间。最终作者放弃了它，回归经典的依赖倒置原则（dependency inversion principle）：没有 port/adapter 这类术语要学，没有多余的水平抽象层，没有外在认知负荷。

如果你认为分层能让你快速替换数据库或其他依赖，那就错了。换存储引发的问题多如牛毛，数据访问层有没有抽象反而是最小的担忧——抽象最多帮你省下迁移时间的约 10%，真正的痛点在数据模型不兼容、通信协议、分布式系统难题，以及 Hyrum's Law 所说的隐式接口：

当 API 的用户足够多时，你在契约里承诺了什么并不重要——总有人会依赖你系统的所有可观察行为。

作者亲历的一次存储迁移耗时约 10 个月：旧系统是单线程的，产生的事件是顺序的，所有下游系统都悄悄依赖了这一可观察行为（它既不在 API 契约里，也不在代码中）；新分布式存储没有这一保证，事件乱序到达。写新的存储适配器只花了几小时（得益于抽象），但随后整整 10 个月都花在跟乱序事件及其他挑战搏斗上——现在再说"抽象帮我们快速替换组件"，就显得很可笑了。

所以，如果这种分层架构的高认知负荷在未来根本兑现不了回报，我们为什么要为它买单？ 何况在大多数情况下，替换核心组件的"那个未来"根本不会到来。这些架构并非根本性的东西，它们只是更根本原则的主观、有偏见的产物。与其依赖这些主观解读，不如遵循底层规则本身：依赖倒置、单一事实来源（single source of truth）、认知负荷、信息隐藏。 业务逻辑不应依赖数据库、UI 或框架这类底层模块；我们应该能在不考虑基础设施的情况下为核心逻辑编写测试——仅此而已。

不要为了"架构"本身添加抽象层；只有当确有实际理由需要扩展点（extension point）时才添加。抽象层不是免费的——它们必须被存放在我们有限的工作记忆里。

实践十二：领域驱动设计（DDD）——问题空间是它的主场，别把解空间当信仰

DDD 确实有不少闪光点，但常常被误读。"我们用 DDD 写代码"这种说法本身就有点怪——DDD 更多关乎问题空间（problem space），而非解空间（solution space）。

统一语言（ubiquitous language）、领域（domain）、限界上下文（bounded context）、聚合（aggregate）、事件风暴（event storming）——这些都是问题空间的产物，目的是帮助我们习得领域洞见、划定边界，让开发者、领域专家和业务人员能用统一语言高效沟通。然而我们往往绕开这些，转而强调特定文件夹结构、service、repository 等解空间技术。

我们每个人对 DDD 的解读大概率都是独一无二、高度主观的；若把代码建立在这种主观理解之上，即制造大量外在认知负荷——未来开发者就惨了。🤯

相比之下，**Team Topologies（团队拓扑学）**提供了一个更好、更易理解的框架，帮助我们跨团队分摊认知负荷；工程师在了解它之后往往形成相似的心智模型。而 DDD 似乎给十个读者创造出十种不同的心智模型——它非但没有成为共识的公共基础，反而成了无谓争论的战场。

熟悉项目中的认知负荷：熟悉 ≠ 简单

源文档收录了 Dan North 的一段重要评论，直击一个隐蔽误区：

问题在于，熟悉不等于简单。 两者的体感一样——都是"几乎不用费脑力就能在代码间穿行"——但成因截然不同。你使用的每一个"聪明"（读作"自嗨"）的、非惯用的技巧，都在向其他人收取学习成本。一旦别人完成了那份学习，代码对他们来说就不那么难了。正因如此，你很难看出自己熟悉的代码该如何简化——这正是我总想在"新人被同化之前"让他们来批判代码的原因。

其他要点同样发人深省：前作者们大概率不是一次性写出这堆烂摊子的，而是一小步一小步累积出来的——所以你是唯一一个需要"一次性理解全部"的人；作者课堂上讲过一段数百行条件判断的巨型 SQL 存储过程，当被问"怎么能允许它烂成这样"时，答案朴素而深刻——"条件只有 2、3 个时，再加一个没什么区别；等条件到了 20、30 个，再加一个也没什么区别！"；代码库上不存在"自动简化的力量"，只有你刻意做出的选择，而简化是要花力气的——人们却总是太匆忙。

如果项目的各种心智模型已经内化进你的长期记忆，你就不会感到高认知负荷；需要学习的心智模型越多，新开发者创造价值所需的时间就越长。 反过来，若认知负荷足够低，新人可以在入职后最初几小时内就向代码库提交贡献——这不意味着牺牲质量或放任代码变成泥潭。

这些"独特的心智模型"是什么？它往往是一套规则，通常是 Clean Architecture / 事件驱动架构 / DDD 的混合物——是作者对自己最热衷事物的个人诠释，是他人必须内化的外在认知负荷。

实操建议：新人入职后，想办法量化他们的困惑程度（结对编程很有帮助）；如果连续困惑超过大约 40 分钟，就说明代码里还有待改进之处。

一些范例：无聊、却好懂的架构

• 我们的架构就是标准 CRUD 应用架构：Postgres 之上的 Python 单体；
• Instagram 用仅 3 名工程师支撑了 1400 万用户；
• 那些让我们惊叹"哇，这帮人聪明得离谱"的公司，大多失败了；
• 整个系统由一个函数串联起来——想知道系统怎么运作，去读那个函数就够了。

这些架构相当"无聊"、容易理解，任何人不费太多脑力就能把握。架构评审时请带上初级开发者——他们能帮你精准定位心智负担最重的区域。

结论：用反例证明论点

试着想象：第二章节推断的结论其实是错的。如果是这样，那么连同我们刚刚否定的结论，连同前一章里我们已认定成立的推论，也许全都站不住脚了。🤯

感觉到了吗？你不仅得在全文里跳来跳去地抓取含义（浅层模块！），而且这一段本身就很难懂——我们刚刚在你脑中制造了一份不必要的认知负荷。别这样对待你的同事。

我们应当削减一切超出工作本身固有（内在）负荷之外的多余心智负担。维护软件本就是难的，东西会坏，我们需要省下每一分脑力：系统组件越少，问题越少，调试时的心智负担也越低。

调试的难度是写代码的两倍。因此，如果你把代码写到最"聪明"的程度，按定义你就不够聪明去调试它。 —— Brian Kernighan

主文档 README.md 还给出了一套长期观察清单，用来代替"哇，这架构感觉真好"这类即时主观感受：

• 复现和调试一个问题容易吗？还是必须在调用栈与分布式组件之间来回跳跃、在脑中拼凑全貌？
• 我们能快速做出修改吗？还是存在大量"未知的未知"，人人都不敢碰代码？
• 新人能快速上手加功能吗？有没有需要学习的独特心智模型？

附：面向 AI Agent 的降负荷编码守则

仓库中的 README.agents.md 是一份专门写给"在人类大脑上写代码"的工程师（包括 AI Agent）的浓缩守则，与本文各章节一一对应，可作为日常开发与代码评审的对照清单：

• 别写无用的 "WHAT" 注释（尤其是逐行复述代码的），只允许更高抽象层面的概览注释；多写解释动机的 "WHY" 注释；
• 让条件可读，把复杂表达式抽取成命名有意义的中间变量；
• 优先提前返回而非嵌套 if，让读者只关注快乐路径；
• 优先组合而非深继承，别逼读者跨多个类追踪行为；
• 不要写浅层方法/类/模块（接口复杂、功能简单，如 MetricsProviderFactoryFactory）；
• 优先深层模块，用简洁接口包裹强大功能；
• 不要滥用语言特性，坚持最小子集，别让读者精通语言才能读懂代码；
• 使用自描述的值，避免需要死记硬背的自定义映射；
• 不要滥用 DRY——一点复制好过不必要的依赖；
• 避免不必要的抽象层，跨层跳转令人精疲力竭，线性思维才符合人类天性。

业界反响

源文档末尾收录了多位业界人士的评论，侧面印证了主题的普适性：Rob Pike（Unix、Go 语言作者）评价"Nice article"；Andrej Karpathy（ChatGPT、Tesla）称这是"关于软件工程最真实、却最少被践行的观点"；Elon Musk 仅回复一词"True"；Addy Osmani（Chrome）从浏览器这种最复杂软件系统的开发实践出发，印证了"组件隔离 + 明确定义的接口"与"简洁接口背后强大功能"正是控制认知负荷的关键；antirez（Redis 作者）则补充了《A Philosophy of Software Design》缺失的"设计牺牲（design sacrifice）"概念——主动牺牲某些特性以换取简单性或性能，例如 Redis 长期以来拒绝为 hash 字段提供过期能力、以及新数据类型 Vector Sets 选择保存向量的近似版本而非全精度值。John Ousterhout 本人也评论道："大型系统中限制开发速度的首要因素，不是你要写多少行代码，而是你在落笔之前必须在脑中收集多少信息。"

---

本文基于仓库根目录的 README.tr.md（土耳其语版）撰写，内容与主英文文档 README.md、AI Agent 守则 README.agents.md 及中文译文 README.zh-cn.md 同源；相关示意图存放于仓库 img 目录。该文档是一份持续更新的"活文档"，欢迎对照源码与多语言版本深入研读。