「Code is not meant to be read」——代码不是用来读的。这句话出自一个写了二十多年代码、以研究编程效率和程序员工作流出道的开发者之口，而且出自一个以“代码质量”为日常话题的频道。这种自我阵营内部的炮轰，正是它值得看的第一层理由：它挑战的不是外行对编程的误解，而是内行每天默诵的信条。
我们从小被教育：“程序是写给人读的，只是顺便让机器执行。”这句出自《SICP》序言的名言，几乎成了程序员的道德律令。Code Review、重构、Clean Code、SOLID，整个现代软件工程的大厦，很大程度上都建立在“代码的主要读者是人”这块基石上。而 ThePrimeagen 在这段广为流传的视频里，直接对着这块基石抡起了锤子。
他的论点并不是“代码可以随便写”，而是更尖锐的一问：如果可读性被神化成了唯一的美德，我们会不会正在用它制造新的复杂度？ 当一个简单的业务改动需要你在二十个文件之间跳转、当你为了“面向接口编程”而写下一堆只有一个实现的接口、当“整洁”本身成为一种需要额外维护的负担——可读性还是那个我们以为的美德吗？
这段视频在程序员社区引发了大量讨论，赞成者认为它说出了被政治正确压抑的真相，反对者认为它在为懒惰开脱。但无论站哪边，看完它你都会被迫重新回答一个根本问题：我每天追求的“好代码”，到底是在为谁服务？ 本文基于视频核心论点与社区公开讨论整理（播放量等数据以 YouTube 页面实际为准），并补充了我自己的延伸分析。
| 项目 | 内容 |
|---|---|
| 视频标题 | Code is not meant to be read |
| 频道 | ThePrimeagen（前 Netflix 工程师，专注程序员效率与编程语言） |
| 时长 | 约15分钟（以页面实际为准） |
| 播放量 | 数十万级，为其频道高传播内容之一（据社区转发热度推断，未经官方核实） |
| 核心主题 | 对“可读性至上”教条的批判性反思：代码的真正约束是什么 |
视频最具冲击力的观点是：我们把手段当成了目的。软件的交付物是“正确运行且可持续演化的行为”，而不是“优美的文本”。可读性确实重要，但它只是达成上述目标的众多约束之一，和性能、正确性、交付速度处在同一层级——而行业话语却把它抬到了目标函数的位置，仿佛代码写得“整洁”，系统就自动健康了。
ThePrimeagen 用了一个很妙的反问：一段无人再读、但稳定跑了十年的代码，和一段人人称赞整洁、但每季度都要返工的代码，哪个更好？这个思想实验暴露了教条的荒谬之处——可读性的价值只有在“被读取”的那一刻才兑现，而绝大多数代码的生命周期里，“被读取”是低频事件，“被执行”和“被冷落”才是常态。
【延伸分析】这个论点其实可以用经济学的“沉没成本与期权价值”来重述：为可读性做的每一份投入，本质上是在为“未来某次阅读”购买期权。期权的定价应该与行权概率成正比。一个只有你一个人维护、且你熟到闭眼能改的模块，买再贵的“可读性期权”都是浪费；一个二十人协作的核心模块，期权才值得重仓。视频没有用这个框架，但这是我认为理解它最快的路径。
业内流传一个说法：程序员读代码与写代码的时间比是 10:1（这个量级常被归于 Steve McConnell 在《Code Complete》中引用的研究，属估算值而非精确测量）。视频对这个数字发起了正面质疑：这个统计把“打开代码文件”都算成了“阅读”，但实际上，程序员大部分的“读”，是在搜索、定位、跳转——是导航行为，不是阅读行为。
这两者的区别至关重要。阅读小说是线性的，而程序员面对的是超文本：Ctrl+Click 跳定义、全局搜索符号、Find Usages 找引用。真正需要“像读书一样从头读到尾”的代码，占比极小。因此，为线性阅读优化的那些实践——详尽的命名艺术、处处俱到的注释、教科书式的分层——服务的其实是一种罕见的阅读场景，却让我们付出了每天的开发成本。
【延伸分析】这一点与 IDE 演进史互为印证：从 Visual Studio 到 IntelliJ 再到今天的 AI 辅助编码，工具的进化方向从来不是“让代码更像散文”，而是“让导航和检索更强”。Copilot 类工具更进一步——它直接压缩了“从零写”的场景。如果未来的主流工作流是“人提意图、AI 产草稿、人做审查”，那么被考验的阅读能力将是审读与定位，而非逐行品读。可读性的内涵本身正在迁移。
视频里最有实操冲击力的部分，是对过度抽象的控诉。ThePrimeagen 描绘了一个所有大厂程序员都经历过的场景：你想改一个字段的校验逻辑，结果发现调用链是 Controller → Service → UseCase → DomainService → Repository → Mapper → Entity，每一层都“职责单一”、都“面向接口”、都“可测试”，而你的一个改动需要同步修改七个文件、三个接口定义和两套 DTO。
这就是我称之为“抽象税”的东西（视频中的表述更口语化）：抽象不是免费的，每引入一层间接，你就给未来所有经过这里的改动征了一笔过路费。当抽象层的数量超过它们解决的问题数量时，架构就从资产变成了负债。他特别点名了教条化的 Clean Code 实践——为每个函数拆出只有一行的实现、为每个类配一个接口“以便将来替换实现”——指出这类仪式感代码制造了大量永远不会到来的“将来”。
【补充背景】对 Clean Code 的批评并非孤例。计算机界对 Robert C. Martin 那本书的争议持续多年，常见的批评包括：书中的示例拆分导致函数数量爆炸、部分建议有性能代价、以及对“整洁”的定义缺乏可度量的标准。ThePrimeagen 的贡献是把散落的批评收束成一个传播力极强的口号式命题。
视频背后的理论根基，其实早在 1987 年就由 Fred Brooks 写下了。他在 IEEE Computer 上发表的经典论文 《No Silver Bullet》 中，把软件复杂度一刀切成两半：本质复杂度（essential complexity）——问题本身固有的、无法消除的部分；偶然复杂度（accidental complexity）——工具、语言和历史遗留强加给你的部分。布鲁克斯的核心论断是：工具的进步只能压缩偶然复杂度，而本质复杂度岿然不动。
拿这个框架看“可读性之争”，很多争论会突然变得清晰：团队里那股挥之不去的“复杂感”，有多少来自问题本身（业务规则就是绕），有多少来自我们自制的抽象（七层调用链）？ 糟糕的工程实践把偶然复杂度堆到本质复杂度之上，让团队误以为“问题就是难”；而教条化的“整洁实践”，则常常是另一场偶然复杂度的搬家——从代码里搬进了类图和接口定义里。复杂度守恒，你只能选择它住在哪里。
【延伸分析】Lehman 软件演化定律（1970年代起由 Meir Lehman 提出）补上了另一半：使用中的真实系统必须持续变化，否则其可用性趋于衰减。也就是说，改动不是意外而是常态，“未来会怎么改”天然不可预测。这两条定律合在一起，正好击碎了“提前抽象”的合法性：既然你无法预测未来，那你为“未来灵活性”预付的每一笔抽象税，赌的都只是你的想象。
必须公平地说，这段视频最容易被断章取义。ThePrimeagen 反对的是可读性教条，而不是可读性本身。他在频道其他内容中反复强调的主线其实相当务实：让程序先正确地跑起来（make it work），在真实的重复出现之前不做预防性抽象，性能敏感的热路径代码要敢于为速度牺牲“优雅”，以及——最重要的一点——程序员应该把时间花在理解问题上，而不是表演工程美学。
他自己的直播写码风格也印证了这一点：大量使用直白的循环和条件，函数偏长，很少为了拆而拆，但变量命名和逻辑流非常清晰，跟着看毫不费力。这揭示了一种被教条掩盖的可能性：直白的代码可以同时是易读的。真正伤害可读性的往往不是“函数太长”，而是“为了短而拆散后，你必须在脑中重建的碎片数量”。
【我的判断】这类“反教条”内容的最大风险，是被初学者当作放纵的许可证。但注意其适用前提：ThePrimeagen 的放松是有底气的——他有极强的语言功底和调试能力兜底。对新手而言，先经过教条阶段的刻意练习（知道拆分的收益在哪），再学会不拆（知道拆分的代价在哪），顺序不能颠倒。教条是脚手架，住进去才是悲剧。
如果抛弃“可读性”这个模糊标准，用什么替代？斯坦福教授 John Ousterhout 在 2018 年的《A Philosophy of Software Design》中给出了我认为更精确的答案：深模块（Deep Module）。好的抽象是“接口窄、功能深”——暴露给使用者的心智负担小，背后藏的实现量大；坏的抽象是“浅模块”——接口一大堆，进去没什么货。衡量标准不是“读起来美不美”，而是“每个模块向使用者收了多少认知税”。
Ousterhout 主张每个模块的“最佳复杂度”不为零：把适度的复杂度关进少数深模块内部，换取外部世界的极简。这和 Clean Code 式的“复杂度摊薄到无数小函数小类”正好相反。2022 年他与 Martin Fowler 在 YouTube 上有一场公开对谈（在 YouTube 搜索 “John Ousterhout Martin Fowler” 可找到官方记录），两种哲学的正面对撞非常值得一看——那场对谈可以看作本视频情绪化论点的学术完整版。
最后是一个操作性极强的推论。既然代码阅读的主形态是导航而非通读，那么提升效率的最高杠杆点，可能不在改代码风格，而在改导航工具链。ThePrimeagen 是 Vim 的重度布道者，原因正在于此：Vim 的核心竞争力不是打字快，而是符号级移动与检索的肌肉记忆——用 grep 类工具全库搜索、用 ctags/LSP 跳定义、用模糊搜索打开文件，把“读代码”变成一套高速导航系统。
这给普通开发者的启示很直接：评估一下你每天“找代码”花掉的时间。如果你还在用鼠标滚动文件树、肉眼定位一个函数，你的阅读效率瓶颈根本不在代码风格，而在工作流。先用工具把导航速度拉满，再谈可读性投资——这是这个视频给出的、最少人听但最值钱的建议。
flowchart TD
A["可读性神话审判"] --> B["代码第一交付物：行为"]
A --> C["局部漂亮不等于系统易懂"]
A --> D["真正的敌人：复杂度"]
B --> E["读写比被高估：导航多于通读"]
E --> F["把代码当超文本：搜索式阅读"]
D --> G["本质复杂度：问题固有"]
D --> H["偶然复杂度：工具与自造包袱"]
D --> I["Lehman定律：系统必须持续演化"]
H --> J["过度抽象 = 抽象税"]
C --> J
J --> K["解法一：Deep Module 深模块"]
J --> L["解法二：YAGNI 三次规则"]
F --> M["解法三：升级导航工具链"]
G --> N["接受无法消除的部分"]
第一，给你的抽象记过路费账。 每次准备引入一层间接（接口、回调、泛型、中间层），先问一句：它现在解决了几个真实存在的问题？如果答案是零或一，先不引入。采用“三次规则”——同样的模式出现第三次时再抽象，此时你才真正知道共性是什么。为想象中的未来写代码，本质是在用今天的确定性补贴明天的不确定性，而汇率极差。
第二，按“读取频率”给代码分级投资。 核心业务路径、多人协作的模块、新手常改的区域——重仓可读性，命名、注释、测试一个都别省。而一次性脚本、即将废弃的迁移代码、只有你维护的冷路径——直白优先，能跑就赢。把“整洁预算”当真金白银分配，而不是无差别撒给每一行。
第三，把复杂度关进深模块。 与其把系统拆成一百个浅层小类，不如设计少数几个“接口窄、肚子深”的模块，让复杂性集中封印。判断标准就用 Ousterhout 的那把尺子：使用这个模块的人，需要理解多少东西才能正确调用它？ 需要理解得越少，模块越好。下次 Code Review 时，用这个问题替代“这样可读吗”，讨论质量会立刻上一个台阶。
第四，本周花两小时升级你的导航系统。 学会 IDE 的结构搜索和 Find Usages 快捷键；在终端装一个 ripgrep；如果你用 VS Code 或 JetBrains 系，把“最近文件”和“跳转定义”练到不用想。对多数开发者而言，这两小时带来的日常收益，超过重构一百个函数命名。
代码的价值不在于它读起来多美，而在于它让多难的问题变得多简单——可读性是工具，不是信仰。
本文由「51学通信」技术团队出品。51学通信由通信行业18年老兵爱卫生（微信ID: gprshome201101）维护，聚焦5G/6G核心网、3GPP标准解读、通信前沿技术深度分析。 出版作品有《5G核心网原理与实践》《IMS原理与实践》等4本通信专业书籍。知识星球「51学通信」提供深度技术答疑和行业洞察。
[!tip] 51学通信知识星球 星主：爱卫生（微信：gprshome201101）——公众号「51学通信」创办者，19 年通信行业运维与讲师经验，著有《GPRS网络信令实例详解》《EPC原理与实践》《5G核心网原理与实践》三本纸质书（各大电商平台有售）。 星球定位：深耕 5G 核心网、IMS、NFV/AI、云原生等 ICT 领域，主打运维岗位与信令分析。 当前规模：5200 篇主题 / 990 个回答，198 元/年。 加入福利：加入星球后请加爱卫生微信，拉您进知识星球年度陪伴与答疑群——不限量回复您的各种问题，另有群内分享。 AI 加持：51学通信知识星球已作为 skill 接入 WorkBuddy，使用 deepseek-4-flash 在海量星球帖子中精准找贴、找视频、找 FAQ 和案例，做总结、找文档和 PPT 等场景全覆盖。