关联知识库：认知负荷才是关键：从复杂到简单的代码设计哲学
认知负荷理论：从复杂到简单的代码设计哲学
原文链接
导读概览
这是一篇来自软件架构师Artem Zakirullin的深度代码设计经验分享，题为《Cognitive load is what matters》（《认知负荷才是关键》）。文章从开发者的"脑容量"讲起，阐述了为什么写代码最重要的事，不是用什么高级架构，不是追逐酷炫技术，而是别让别人看你的代码后"想骂人"。文章获得了OpenAI创始成员Andrej Karpathy和埃隆·马斯克的认可。
核心观点提炼
1️⃣ 认知负荷的本质
"认知负荷是指开发人员为了完成一项任务所需要承担的思考量"
- 人类认知限制：普通人能够支配的记忆力大约可以容纳4个构建块
- 认知负荷阈值：一旦达到阈值，理解难度就会开始陡然上升
- 内在vs外在：内在负荷源自任务固有难度，外在负荷由信息呈现方式导致
2️⃣ 优秀代码的识别标准
- 低认知负荷：新人能在几小时内为代码库做出贡献
- 简单直观：看代码后觉得"比我想的要简单"
- 易于理解：不需要费力消化复杂的设计决策
- 自我隐藏：好的代码设计往往看起来平淡无奇
3️⃣ 复杂性的真相
"复杂系统通常反映的是良好设计的缺失"
- 复杂代码应该从简单代码演化而来
- 从零开始设计复杂系统是糟糕的想法
- 过度抽象、分层架构、DDD等"聪明技巧"可能掩盖根本性错误
代码设计核心原则
条件语句的艺术
- 避免复杂条件：不要玩脑筋急转弯
- 描述性变量：引入清晰的中间变量
- 逻辑分离：将复杂条件分解为简单判断
️ 继承vs组合哲学
- 继承链问题：继承链是认知负荷的天花板
- 组合优先：用组合替代继承
- 简单关系：避免复杂的继承层次结构
⚡ 模块设计策略
- 深模块设计：接口简单，但功能复杂
- 信息隐藏：隐藏内部复杂性，只暴露简单接口
- 避免浅模块：相对于所提供的小功能，接口相对复杂
语言功能选择
- 限制选项：通过限制选项的数量来降低认知负荷
- 功能关联：丰富的语言功能要彼此关联
- 避免过度使用：不要为了"优雅"而使用新特性
架构设计原则
- 避免过度分层：分层架构只有在需要明确扩展点时才有意义
- 简单API调用：简单的API调用往往比复杂的事件驱动更好
- 实用优先：选择经过验证的组件，而不是追求"聪明"的解决方案
DDD实践指导
- 问题空间思考：DDD本质是关于问题空间的思考
- 避免机械化：不要变成固定的文件夹结构或命名规则
- 领域建模：专注于领域建模和边界划分
实战经验总结
新人友好性优先
- 识别代码对新人的认知负荷
- 新人40分钟内应该能理解项目结构
- 低认知负荷让新人快速贡献
代码可读性
- 描述性命名：变量名和函数名要清晰表达意图
- 逻辑清晰：代码逻辑要直观易懂
- 注释适度：在复杂逻辑处添加必要注释
️ 维护性设计
- 简单修改：修改一处代码不应该影响其他地方
- 易于调试：问题定位要简单直接
- 测试友好：代码结构要便于编写测试
深度思考与启发
1️⃣ 关于"简单"的哲学
Artem的观点颠覆了很多人对"好代码"的认知。他提醒我们，真正优秀的代码设计往往看起来平淡无奇，而那些看起来"很厉害"的复杂代码可能掩盖了根本性问题。
2️⃣ 认知负荷的复杂性
认知负荷是代码设计中最困难的部分。一旦涉及复杂的逻辑、抽象层次、架构模式，就需要考虑理解成本、维护难度、团队协作等一系列复杂问题。简单设计虽然限制了某些"优雅"特性，但大大简化了认知复杂度。
3️⃣ 抽象的双刃剑
抽象是代码设计的经典手段，但也是认知负荷的来源。过度抽象可能导致理解困难、调试复杂、维护成本高等问题。高级工程师更倾向于从根本解决问题，而不是依赖过度抽象。
4️⃣ 架构模式的陷阱
分层架构、事件驱动、DDD等模式看起来很优雅，但过度使用可能导致系统难以理解、调试困难。简单的函数调用往往更直接、更容易维护。
实践建议
设计阶段
- 从简单开始：先实现核心功能的最小可行代码
- 识别认知热点：找出最复杂的逻辑和抽象
- 认知负荷最小化：仔细考虑哪些复杂性是真正必要的
️ 实现阶段
- 命名优先：先设计好变量名和函数名
- 逻辑简化：将复杂逻辑分解为简单步骤
- 模块设计：设计深模块，隐藏内部复杂性
维护阶段
- 新人测试：让新人尝试理解代码，衡量认知负荷
- 持续简化：基于实际使用情况不断简化代码
- 文档补充：在复杂逻辑处添加必要说明
总结
Artem Zakirullin的这篇文章为我们提供了一个全新的视角来看待代码设计。他告诉我们：
- 好的代码是平淡的：真正优秀的代码往往看起来"没什么特别"
- 简单优于复杂：从简单代码开始，让复杂性自然演化
- 实用优于炫技：选择经过验证的模式，而不是追求"聪明"的解决方案
- 认知负荷是敌人：尽量减少认知负担，让代码更容易理解和维护
这些观点对于当前追求"优雅架构"、"设计模式"、"DDD"等时髦概念的技术社区来说，是一剂清醒剂。它提醒我们回归代码设计的本质：用最简单的方式写出最容易理解的代码。
正如Artem所说："减少认知负荷并不是一个高深的哲学，而是开发者日常需要实践的基本功。或许，每次写代码时，我们都该问问自己：这段代码，是帮同事省脑子，还是让他们掉头发？"
本文档基于InfoQ翻译的《认知负荷才是关键》内容整理，原文作者为软件架构师Artem Zakirullin
浙公网安备 33010602011771号