一、全书概览
一句话总结
程序员真正的瓶颈不是技术不够，而是大脑的认知资源管理不当——这本书教你用认知科学的方法重新武装自己的编程大脑。
全书结构
全书分四大部分、13 章，从「读代码→想代码→写代码→协作代码」层层递进。
| 部分 | 章节 | 主题 | 一句话概括 | |------|------|------|------------| | 第一部分：代码阅读 | 1 | 剖析程序设计之惑 | 程序员的三种困惑来源：缺知识、缺信息、缺加工能力 | | | 2 | 速读代码 | 组块（chunking）是突破短时记忆限制的关键 | | | 3 | 快速学习编程语法 | 遗忘曲线 + 提取练习，别再一遇到语法就搜搜索引擎 | | | 4 | 理解复杂代码 | 找焦点、向外扩散、建立心智模型 | | 第二部分：代码思考 | 5 | 深入理解代码 | 角色分配、命名规范、代码范式 | | | 6 | 更好地解决编程问题 | 问题表征方式决定解决策略 | | | 7 | 迷思概念：错误的思维方式 | 很多 bug 不是粗心，而是思维模型本身有误 | | 第三部分：代码编写 | 8 | 如何更好地命名 | 先写代码再命名，命名要符合团队模板 | | | 9 | 认知负荷管理 | 内部、外部、关联认知负荷的三种类型 | | | 10 | 复杂问题拆解 | 大问题拆成小问题，降低认知需求 | | 第四部分：代码协作 | 11 | 代码编写行为 | 编程的五种子任务和中断恢复策略 | | | 12 | 设计和改进大型系统 | 代码库的11个维度评估 | | | 13 | 对新程序员进行适岗培训 | 新人上手难的根本原因是认知超载 |
作者背景
费莉安·赫尔曼斯，荷兰莱顿大学副教授，TC39（JavaScript 标准委员会）成员，自创了 Hedy 编程教学语言。她的研究方向就是"人类如何利用认知科学学习编程"——这本书算是她研究成果的集大成。豆瓣评分 7.8，在程序员学习类书籍中算中上水准。
二、逐章要点
第1章：剖析程序设计之惑
核心观点
程序员在编程时遇到的困惑，本质上可以归为三类——缺知识、缺信息、缺加工能力。
关键概念
| 困惑类型 | 表现 | 解决方向 | |----------|------|----------| | 缺乏知识 | 不认识某个语法、不知道某个 API | 补充学习，建立长时记忆 | | 缺乏信息 | 代码分散在多个文件、缺少上下文 | 改善代码组织，增加注释 | | 缺乏加工能力 | 代码逻辑太复杂，大脑处理不过来 | 降低认知负荷，拆分问题 |
三种记忆系统
书里重点介绍了大脑的三种记忆：
- 长时记忆（LTM）：容量近乎无限，存储你学过的所有知识
- 短时记忆（STM）：容量极小，约 4-7 个信息单元，但处理速度快
- 工作记忆：处理和操作信息的"工作台"，容量同样有限
行动清单
- [ ] 下次代码看不懂时，先判断是三种困惑中的哪一种，对症下药
- [ ] 意识到自己"读不懂"不是笨，而是认知资源不够用
第2章：速读代码
核心观点
研究表明，程序员约 60% 的时间花在阅读代码上，而非编写代码。但几乎没有学校教你怎么读代码。
组块（Chunking）——全书最核心的概念
作者引用了认知心理学家 De Groot 的经典国际象棋实验：
- 实验一：让国际象棋大师和普通选手记忆真实棋局 → 大师远胜普通选手
- 实验二：随机摆放棋子 → 大师和普通选手表现一样差
结论：大师的优势不是短时记忆容量更大，而是他们能把棋局组块——看到的是"西西里开局，但骑士偏左两格"，而不是"车在 A7，兵在 B5，王在 C8"。
对应到编程：高级程序员看到 for (let i = 0; i < arr.length; i++) 时，大脑直接识别为"遍历数组"这个整体概念，占用一个工作记忆槽位；而初级程序员可能逐字逐词处理，占用多个槽位，很快就超载了。
如何培养组块能力
- 反复接触常见代码模式（设计模式、惯用法）
- 把代码块和其功能绑定，形成自动识别
- 多读别人写的代码，积累模式库
行动清单
- [ ] 每周读一段陌生开源项目的代码，练习模式识别
- [ ] 把常见的代码模式（排序、遍历、状态管理）做到"一眼认出"的程度
第3章：快速学习编程语法
核心观点
每次遇到陌生语法就打开搜索引擎，看似高效，实际上是在摧毁你的提取记忆能力。
遗忘曲线 + 提取强度
书里用 Bjork 的"记忆强度模型"解释了这个问题：
- 存储强度：信息在记忆中存储的牢固程度
- 提取强度：你能否在需要时回忆起该信息的强度
搜索引擎的陷阱在于：搜索太容易了 → 大脑认为不需要记住 → 存储强度上去了，但提取强度始终在低位徘徊 → 下次还是要搜 → 恶性循环。
正确的语法学习策略
| 方法 | 说明 | 效果 | |------|------|------| | 提取练习 | 合上书本/搜索引擎，主动回想语法 | ★★★★★ | | 间隔重复 | 在遗忘曲线的关键节点复习 | ★★★★☆ | | 交叉练习 | 混合练习不同类型的语法 | ★★★★☆ | | 搜索引擎 | 每次都查 | ★☆☆☆☆（养成依赖） |
行动清单
- [ ] 选一个你经常要查的语法，背下来，不再搜索
- [ ] 学新语言时，每学完一个概念就关掉教程，自己默写一遍
第4章：理解复杂代码
核心观点
不要线性地从头读到尾，找一个焦点，从那里开始向外扩散理解。
代码阅读策略
- 找焦点：先扫描整个代码，找一个你最感兴趣或最关键的入口点
- 理解焦点代码：搞清楚这段代码做了什么
- 向外扩散：从焦点出发，追踪它调用了什么、被什么调用
- 标注和注释：在代码中添加自己的理解笔记
- 建立心智模型：画出代码的整体结构图
书里还提到了一个"古法"技巧：选取代码中所有标识符，构建一个可视化工具来快速把握代码结构。虽然操作起来比较原始，但思路很有启发。
行动清单
- [ ] 下次读大段陌生代码时，不要从头读，先找到入口函数作为焦点
- [ ] 读代码时在新分支上做标注注释，帮助自己理解
第5章：深入理解代码
核心观点
代码中的命名、角色分配和编程范式，都会影响你的理解深度。
关键概念
- 角色：代码中变量和函数扮演的不同角色（计数器、标志位、容器等），理解角色有助于快速把握代码意图
- 编程范式：面向对象、函数式、过程式等不同范式提供了不同的思维框架
- 命名的重要性：好的命名等于好的文档，差的名字等于隐藏的 bug
行动清单
- [ ] 审视自己最近写的代码，变量名是否准确反映了其角色
- [ ] 尝试给一段代码用不同范式重写，感受认知负担的差异
第6章：更好地解决编程问题
核心观点
问题如何表征，决定了你能否解决它。
问题表征的例子
计算一个数除以 2：
- 十进制思维：做除法运算
- 二进制思维：直接右移一位
同样的数学操作，不同的"表征方式"导致难度天差地别。编程中的很多难题，换个角度描述就豁然开朗了。
编程问题解决的五个步骤
- 理解问题
- 建立心智模型
- 选择表征方式
- 执行解决方案
- 验证和反思
行动清单
- [ ] 遇到复杂算法问题时，先尝试用不同方式"描述"问题，再动手写代码
- [ ] 把问题画出来——流程图、状态图、数据结构图都行
第7章：迷思概念：错误的思维方式
核心观点
很多 bug 不是粗心导致的，而是程序员头脑中关于"程序如何运行"的心智模型本身就有误。
迷思概念的类型
| 迷思类型 | 举例 | 真相 | |----------|------|------| | 语言机制误解 | "Python 会自动关闭文件" | 大部分情况下不会 | | API 行为误解 | "这个函数会返回新数组" | 实际上是在原数组上修改 | | 系统运行误解 | "数据库连接用完会自动释放" | 不会，会泄漏 |
如何纠正迷思概念
- 写测试来验证你的假设
- 阅读官方文档，而不是依赖道听途说
- 建立正确的心智模型，而不是记住孤立的规则
行动清单
- [ ] 列出你最近遇到的 3 个 bug，分析哪些是"迷思概念"导致的
- [ ] 对不确定的 API 行为，写个测试验证，而不是靠猜
第8章：如何更好地命名
核心观点
先写代码，再命名。写代码时你的大脑正在忙于解决问题，没余力想出好名字。
命名最佳实践
| 原则 | 正确示例 | 错误示例 |
|------|----------|----------|
| 使用完整单词 | totalCount | tc |
| 反映领域概念 | calculateDiscount | process |
| 团队保持一致 | 统一用 get / set | 一会儿 get 一会儿 fetch |
| 音节不宜过多 | user | individualAccountHolder |
| 避免误导 | isDeleted（布尔型） | isDeleted（返回字符串） |
行动清单
- [ ] 建立团队命名模板文档，统一风格
- [ ] Code Review 时重点检查命名质量
第9章：认知负荷管理
核心观点
编程中有三种认知负荷，只有一种是"好"的。
三种认知负荷
| 类型 | 说明 | 管理 | |------|------|------| | 内部认知负荷 | 任务本身的复杂度 | 拆分任务、分步解决 | | 外部认知负荷 | 代码呈现方式带来的额外负担 | 改善代码结构、加注释 | | 关联认知负荷 | 用于学习和内化知识的负荷 | 需要刻意保留，不能压缩到零 |
关键洞察：关联认知负荷是你把当前经验转化为长期知识所需的"加工空间"。如果 100% 的大脑都在解决眼前问题，就没有余力进行总结和内化了。所以编程时要有意识地留出"反思时间"。
行动清单
- [ ] 解决复杂问题后，花 5 分钟写下你学到了什么
- [ ] 识别自己代码中增加外部认知负荷的部分，重构它们
第10章：复杂问题拆解
核心观点
建模是把复杂问题变简单的核心技能——为代码建立正确的抽象层次。
建模的方法
- 识别问题中的实体和关系
- 为每个实体建立抽象
- 定义实体之间的交互方式
- 逐步细化，从高层设计到具体实现
行动清单
- [ ] 开始编码之前，先用自然语言描述系统的主要实体和它们的关系
- [ ] 对每个复杂函数，问自己"它真正在做什么？"然后按职责拆分
第11章：代码编写行为
核心观点
编程实际上是五种不同子任务的交替：搜索、理解、编写、扩展、探索。
五种编程子任务
| 子任务 | 描述 | 被中断时的恢复难度 | |--------|------|---------------------| | 搜索 | 在代码库中查找相关代码 | 低 | | 理解 | 理解代码做了什么 | 高 | | 编写 | 根据理解写新代码 | 高 | | 扩展 | 在已有代码基础上添加功能 | 中 | | 探索 | 尝试不同方案解决新问题 | 中 |
中断恢复策略
在被中断前，写下你当前的心智模型和待完成的目标清单。知道自己在做"哪种"子任务，有助于快速恢复上下文。
行动清单
- [ ] 被打断之前，花 30 秒写下一句话："我正在做……下一步要……"
- [ ] 保护深度工作时段，减少不必要的打断
第12章：设计和改进大型系统
核心观点
代码库可以用 11 个维度来评估，不同维度对不同编程任务的影响不同。
代码库的 11 个维度
| 维度 | 含义 | 高分意味着 | |------|------|------------| | 易错性 | 语言/框架是否容易出错 | 不容易出 bug | | 一致性 | 代码风格是否统一 | 不需要学不同习惯 | | 弥散性 | 概念单元是否能在单屏展示 | 便于整体理解 | | 可见性 | 是否有隐藏的"坑" | 透明、可预测 | | 暂定性 | 工具是否支持实验性修改 | 支持快速原型 | | 黏滞性 | 修改是否牵一发动全身 | 易于局部修改 | | 渐进性 | 语言是否支持逐步实验 | 支持迭代开发 | | 表达性 | 语法和语义是否一致 | 少特殊规则 | | 贴近性 | 语言是否贴近问题领域 | 域建模自然 | | 记号性 | 是否支持长命名和注释 | 可读性好 | | 抽象性 | 抽象层次是否合理 | 关注点分离 |
行动清单
- [ ] 用这 11 个维度评估你当前项目，找出最需要改进的 2-3 个
- [ ] 在做技术选型时，不只看性能和生态，也考虑这些认知维度
第13章：对新程序员进行适岗培训
核心观点
新人上手慢，很多情况下不是因为"编程能力差"，而是因为接收的信息量超过了认知负荷上限。
知识的诅咒
高级程序员看"数组索引越界"是一个完整的概念，占用一个认知槽位；初级程序员看到的是三个独立元素——"数组""索引""越界"——占用三个槽位。所以同样的错误信息，新人的认知负担是老手的三倍。
新人培训建议
- 分阶段引入信息，不要一次性灌输
- 先让新人熟悉代码结构（建立地图），再深入细节
- 鼓励提问，把"不知道"当作正常状态
- 为新人建立共享的心智模型（统一的术语、架构图、决策记录）
行动清单
- [ ] 团队有新人加入时，先给一张代码库"地图"，而不是直接丢文档
- [ ] 建立团队知识库，记录重要的架构决策和术语定义
三、关键概念速查
| 概念 | 定义 | 一句话理解 | |------|------|------------| | 组块（Chunking） | 把多个信息单元组合成一个整体来记忆 | 像把散棋子看成"开局定式" | | 工作记忆 | 处理和操作信息的"工作台" | 容量 4-7 项，是编程的真正瓶颈 | | 长时记忆 | 大容量、持久的信息存储 | 你的"知识库"，越充实越好 | | 存储强度 | 信息在记忆中的存储牢固度 | 搜索引擎能提高存储强度 | | 提取强度 | 需要时能否回忆起信息 | 搜索引擎会降低提取强度 | | 认知负荷 | 大脑处理信息时消耗的认知资源 | 分内部、外部、关联三种 | | 心智模型 | 对系统如何工作的内在表征 | 你的"大脑模拟器" | | 图式 | 已有知识的组织结构 | 长时记忆中的"知识索引" | | 迷思概念 | 错误的心智模型 | bug 的深层原因 | | 知识的诅咒 | 专家难以理解初学者的困惑 | 你觉得简单的事，新人可能觉得是天书 | | 提取练习 | 主动回忆信息而非被动阅读 | 最有效的记忆强化方式 | | 关联认知负荷 | 用于学习和内化的认知资源 | 不该压缩到零的"好负荷" | | 信标（Beacon） | 代码中帮助识别结构的注释或标记 | 帮助分块的高级注释 |
四、核心框架/模型
1. 记忆系统协作模型
┌─────────────────────────────────────────────────┐
│ 工作记忆（工作台） │
│ 容量有限：4-7 个信息单元 │
│ │
│ ┌──────────┐ ┌──────────────────────┐ │
│ │ 短时记忆 │ ←→ │ 长时记忆 │ │
│ │ (临时存储)│ │ 容量近乎无限 │ │
│ └──────────┘ │ - 语法知识 │ │
│ │ - 设计模式 │ │
│ │ - 项目领域知识 │ │
│ │ - 心智模型/图式 │ │
│ └──────────────────────┘ │
│ ↑ │
│ 组块（Chunking） │
│ 把多个信息单元压缩为一个整体 │
└─────────────────────────────────────────────────┘
2. 编程困惑分类模型
代码看不懂？
├── 缺乏知识 → 补学习（语法、API、设计模式）
├── 缺乏信息 → 补上下文（注释、文档、代码组织）
└── 缺乏加工能力 → 降负荷（拆分、组块、工具辅助）
3. 三种认知负荷模型
总认知负荷 = 内部负荷 + 外部负荷 + 关联负荷
内部负荷 ──── 任务固有复杂度 ──── 通过拆分降低
外部负荷 ──── 代码/工具造成的额外负担 ──── 通过重构降低
关联负荷 ──── 用于学习的"投资" ──── 不能降到零！
4. 代码阅读焦点点扩散法
步骤1: 扫描代码，找焦点（入口函数/最感兴趣的部分）
↓
步骤2: 深入理解焦点代码的行为
↓
步骤3: 向上追溯——谁调用了它？
↓
步骤4: 向下追踪——它调用了什么？
↓
步骤5: 向旁扩展——相关数据和配置在哪里？
↓
步骤6: 建立完整的心智模型，画出结构图
五、金句摘录
程序设计是一个认知过程，这个过程对程序员的认知要求颇高。
记不住语法无疑会使程序员陷入恶性循环：因为记不住语法，所以需要进行搜索；但因为总是依靠搜索引擎而不是设法记住语法，所以编程概念的提取强度始终无法提高，致使不得不一而再再而三地进行搜索。
在高级程序员眼里，"数组索引越界"是一个完整的概念；而在初级程序员看来，这样一条简单的错误消息可能包含 3 个独立的元素。
团队新人之所以得到"编程能力不强"的评价，许多情况下只是因为知识的诅咒在从中作梗：他们接收的信息过多，令大脑不堪重负。
表征会影响许多问题的解决策略。
编程是搜索代码、理解代码、编写新代码、扩展已有代码、探索解决方案这五种子任务的交替。
如果你的大脑 100% 都用来解决眼前问题，就没有余力把解决方案转化为可复用的知识。
先写代码再命名。写代码时你的大脑正在忙于解决问题，没余力想出好名字。
六、行动清单
每天
- [ ] 遇到要查的语法，先试着回想 30 秒，实在想不起来再搜索
- [ ] 写完一段逻辑后，花 1 分钟用自然语言总结"这段代码做了什么"
- [ ] 被打断之前写下一句话状态备忘
每周
- [ ] 读一段陌生开源项目的代码，练习组块识别
- [ ] 复盘本周遇到的 bug，区分哪些是"粗心"哪些是"迷思概念"
- [ ] 检查自己写的变量名/函数名，是否准确反映其角色
每月
- [ ] 用 11 个代码库维度评估当前项目，找改进点
- [ ] 选一个经常要查的语法/API，通过提取练习做到不再需要搜索
- [ ] 更新团队的知识库：架构图、术语表、决策记录
长期
- [ ] 建立常见设计模式和惯用法的"自动识别"能力
- [ ] 为每个复杂子系统建立准确的心智模型，并用文档固化
- [ ] 在新人培训中应用分阶段信息引入策略
七、一句话总结
编程的本质不是敲键盘，而是大脑的认知管理——管好你的记忆、负荷和心智模型，代码能力自然水涨船高。
八、读者热议
豆瓣评分：7.8 / 10
SereinSos（2026-03-31）—— 高度认同
很认同书内的"组块"的认知学习概念（用围棋棋局识别来举例子，看来模式识别真的是很重要的概念）。在我看来有两点很值得学习：第一就是看代码抓大放小，比如在以梳理代码逻辑为目标时忽略对于域限定符的关注；第二就是尽可能不要线性地读代码。
佩索啊（2024-08-04）—— 结构化总结
- 短期记忆，长期记忆，工作记忆。2. 分组分块理解记忆、组织思考。3. 熟悉语法，常见的设计模式，算法框架都是很有用的。4. 回想可以增强长期记忆。8. 与程序设计相关的 3 种认知负荷：内部、外部、关联认知。
尚善（2024-04-23）—— 褒贬参半 ⭐⭐⭐
书中各个方法和观点整体偏主观，不同人适用程度不尽相同。虽然从认知角度看待编程过程是有益的，但不推荐花费过多时间。
阅微草堂（2024-04-13）—— 短评
因为工作都是从已有的代码开始的，同时接受计算机教育中重视编码——重头开始一个人新建所有代码，并不重视阅读代码特别是大型代码。程序员宁愿自己写代码，也不愿重用或修改现有的代码，因为"自己写更容易"。
喵喵的评价
这本书的价值在于提供了一个"认知科学 × 编程"的交叉视角。对于已经写了几年代码的开发者来说，很多道理你可能已经在实践中摸索到了（比如"注释写高层次的而不是废话注释""新人上手要循序渐进"），但本书帮你把这些经验理论化了——知道为什么有效，比知道有效更重要。
不过缺点也明显：部分内容偏学术，实操性不够强；关于认知负荷的测量方法在日常场景中基本无法落地；个别观点（比如建议把函数式代码改写成命令式）存在争议。建议挑重点章节读（2、3、8、9、13），其他章节按需翻阅。
笔记生成：2026-04-27 by 喵喵 🐈
相关笔记
同作者仅有此篇 同主题：