如果让你推荐一个“每个程序员都该看一遍”的演讲，你会选什么？在 Hacker News 和 Reddit 的 r/programming 社区，有一个答案被反复提及十几年——Rich Hickey 在 Strange Loop 2011 大会上的《Simple Made Easy》。Hickey 是 Clojure 语言的作者，但这场演讲几乎不谈 Clojure，谈的是一件更根本的事：为什么你写的代码越来越难改，哪怕你一直在用“最好用”的工具？
它的核心论点只有一个词的区分：simple（简单）不等于 easy（容易）。听起来像文字游戏？恰恰相反，这个区分是我见过的对“软件为什么腐烂”最锋利的解释框架。它回答了几个我们每天都在经历却很少深究的问题：为什么用了框架反而更慢？为什么“顺手”的技术选型常常是慢性毒药？为什么 code review 时说不清哪里不对，但就是觉得味道不对？
更难得的是，这场演讲是反热点的。它不教你任何新框架、新语言，而是给你一副透视眼镜——看完之后你看所有代码、所有工具的视角都会变。在 AI 能批量生成代码的今天，这种判断力反而比任何具体技能都值钱。
| 项目 | 内容 |
|---|---|
| 视频标题 | Simple Made Easy |
| 频道 | Strange Loop（官方频道） |
| 演讲者 | Rich Hickey（Clojure 语言作者） |
| 时长 | 约57分钟 |
| 播放量 | 超100万，是该频道播放量最高的演讲之一 |
| 发布背景 | 2011年9月，美国圣路易斯 Strange Loop 技术大会主题演讲 |
| 核心主题 | 区分“简单”与“容易”，剖析软件复杂性的根源与解法 |
演讲开篇，Hickey 做了一件很聪明的事：查词典。easy 来自拉丁语 adjacere，意思是“躺在附近”——触手可及、不用挪窝。所以一件事“容易”，意味着它离你很近：离你已有的技能近、离你熟悉的工具近、离你现在的舒适区近。这也意味着 easy 是相对的：对写惯 Java 的人，Spring“容易”；对写惯 Python 的人，Django“容易”——换个人，答案就变了。
而 simple 的词源是 sim-plex：sim 是“一”，plex 是“股/编”——一股，没有缠绕。一根线是简单的，编成辫子就复杂了。Hickey 强调：简单是客观属性。一段代码是否只做一件事、概念之间是否纠缠，不因为观察者的背景而改变。
[延伸分析] 这个区分解开了行业里一大堆鸡同鸭讲的争论。当有人说“这个框架很简单”时，他其实在说“这个框架对我来说容易上手”；而当架构师说“这个设计不简单”时，指的是概念耦合太多。两拨人用的是同一个词，说的却是两个维度。把这两个词拆开后，技术选型会上至少一半的争执可以直接消解。
Hickey 给出了一个判断：程序员真正的瓶颈不是打字速度、不是学新 API，而是复杂性的累积让系统越来越难理解和修改。演讲中引用了 Dijkstra 的名言："Simplicity is a prerequisite for reliability"（简单是可靠性的前提）——你没理解的东西，不可能做可靠。
他自己最著名的一句话是："Programmers know the benefits of everything and the tradeoffs of nothing."（程序员对一切只有收益清单，对权衡一无所知。）我们选择每个工具时都能说出一堆好处——正则表达式强大、继承可复用、注解很方便——却从不算这些能力塞进来之后，系统付出的理解成本。
[延伸分析] 这句话放在今天尤其扎心。现在的技术决策常常是“AI 推荐 + 播放量 + Star 数”三件套，全是收益侧信号；而代价侧——这个库把多少概念缠在了一起？出问题时你要理解多少层才能 debug？——没有任何榜单会告诉你。复杂性的账单永远延迟支付，账期通常是十八个月后的某次紧急上线。
演讲里最原创的概念是 complect（Hickey 复活的一个古英语词，意为“编织在一起”）。他说，复杂性的制造机制从来不是“代码行数多”，而是把两个本该独立的概念编成了一股线：状态和身份编在一起、数据和代码编在一起、执行顺序和业务逻辑编在一起、两个组件互相引用编在一起。
他随后列了一张“容易但不简单”清单，今天看依然刀刀见血：
[延伸分析] 注意这张清单的共同点：它们全都是“easy”的——上手快、IDE 友好、写起来爽。这正是 Hickey 的杀伤力所在：复杂性不是来自你不熟悉的东西，恰恰来自你最熟悉、最喜欢的东西。你代码里最难改的那部分，大概率就是当年“三行搞定”最得意的那部分。
整套论证里最硬核的一节：不要把 state（状态）和 identity（身份）编在一起。Hickey 指出，一个可变对象是悖论式的存在——this 指代的“它”在时间流逝中会变成完全不同的东西。上一毫秒的它和这一毫秒的它共享同一个名字，却不再是同一个值。所有读它的代码都必须回答一个问题：“我看到的是哪个时刻的它？”于是锁、竞态、时序 Bug 全部登场——多线程“见鬼”现象的哲学根源就在这里。
他的解法后来广为人知：用不可变的值建模数据，把“随时间变化”单独交给一层极小的、受控的状态机制。值可以被无限共享、随意传递，永不撒谎；变化被收敛成一条条可追溯的事件。
[延伸分析] 这段论证的影响力远超 Clojure 圈。React 的单向数据流和"state snapshot"、Redux 三原则里的"state is read-only"、Rust 的所有权模型、Java 后来的 record 类型、甚至数据库领域 log-structured 的复兴，本质上都在做同一件事：把值和变化拆开。2011 年这听起来像函数式小众的执念，到今天已经是主流工程共识——一场演讲改变一个行业的设计品味，并不夸张。
Hickey 主张 data-oriented programming：能用 map、向量、集合这类通用数据结构表达的信息，就不要为它定制一堆类。他的理由是：通用结构是语言里被测试得最充分的代码，配套的打印、比较、序列化、遍历能力全都免费；而每定义一个类，你就要重写一遍 equals、hashCode、toString，还要为此引入一层只能被特定方法访问的封装——这就是把数据和操作它的函数编在一起。
[延伸分析] 这个观点在当年被 OOP 阵营骂得很凶，但看看今天的现实：整个互联网的数据交换事实标准是 JSON——一种“一堆通用数据结构”的格式。前后端之间没人传类实例图；配置语言 YAML/TOML 全是通用结构。十几年的行业演化，等于给这场演讲投了票。当然也要公平：核心业务领域模型仍然需要类型系统的约束，Hickey 反对的是“万物皆类”的教条，而非类型本身——这一点是他和极端动态派的重要区别。
面对“那到底怎么复用代码”的疑问，Hickey 给出的答案是抽象（abstraction）而非继承：调用方只依赖一个小而清晰的接口/协议，实现可以随意替换；组件之间用队列、消息解耦，而不是直接函数调用把控制流编在一起。他特别推崇 SQL 式的声明式风格——你只描述“要什么”，不用把“怎么遍历、按什么顺序”编进逻辑里。顺序和逻辑分离、控制和实现分离，是他对“不 complect”原则的正向表述。
[延伸分析] 这其实就是后来“六边形架构”“事件驱动”这些架构风格的理论底座。判断一个系统耦合度最朴素的问题也在这里：A 组件坏了，B 组件是功能受损，还是行为只是变慢/延迟？前者说明两者编在一起了，后者说明用了队列式的解耦。这个问题可以直接写进你的架构评审 checklist。
演讲结尾回应了最常见的质疑：“我的业务要快速迭代，没时间追求简单。”Hickey 的回答是：easy 带来的快是短跑，simple 带来的快是长跑。追求 easy，头三个月飞快，之后每一步都在为解开缠绕付利息；追求 simple，起步略慢，但系统始终保持“一股线”的状态，改动永远只需要理解一条线。所以他给出的行动纲领不是“少做事”，而是：在每一个技术选择点，把默认排序倒过来——先问“它简单吗”（客观、少缠绕），再问“它容易吗”（顺手、熟悉）。
[延伸分析] 我把这个称为“选型时的第二次呼吸”：第一反应永远是选 easy 的——这很正常，人是认知吝啬鬼；修炼在于停顿三秒，强迫自己回答“它的简单性代价是什么”。十四年过去，这场演讲被反复推荐的原因就在这里：它不提供任何具体答案，但它永久性地改写了你提问的顺序。
flowchart TD
SM["Simple Made Easy<br/>Rich Hickey, 2011"]
SM --> C1["概念辨析"]
SM --> C2["复杂性的根源"]
SM --> C3["解法工具箱"]
SM --> C4["回报"]
C1 --> D1["Easy 容易<br/>词源: adjacere 就在手边<br/>相对的 · 因人而异"]
C1 --> D2["Simple 简单<br/>词源: sim-plex 一股线<br/>客观的 · 不缠绕"]
C2 --> E1["complect 编织纠缠<br/>复杂性的制造机制"]
E1 --> F1["状态 与 身份 编在一起<br/>→ 竞态与时序 Bug"]
E1 --> F2["数据 与 代码 编在一起<br/>→ 万物皆类的教条"]
E1 --> F3["顺序 与 逻辑 编在一起<br/>→ 命令式控制流迷宫"]
E1 --> F4["组件 与 组件 编在一起<br/>→ 直接调用, 一坏俱坏"]
C3 --> G1["不可变的值<br/>共享传递, 永不撒谎"]
C3 --> G2["通用数据结构<br/>map / 向量 / 集合"]
C3 --> G3["小接口 + 抽象<br/>而非继承复用"]
C3 --> G4["队列解耦<br/>声明式 > 命令式"]
C4 --> H1["可理解<br/>只需看懂一股线"]
C4 --> H2["可变更<br/>改动只影响一条链"]
C4 --> H3["可测试可组合<br/>纯值 + 纯函数"]
D2 -.行动纲领.-> G1
D2 -.行动纲领.-> G3
H1 -.长期.-> I["长跑快于短跑:<br/>先问简单, 再问容易"]
第一，改造你的 code review 问题清单。 下次评审时，别再只问“逻辑对不对”，加上三个 Hickey 式问题：这次改动有没有把两个概念编在一起？有没有让“值”变成了可变的“状态”？新引入的依赖是把复杂性藏进了深接口，还是摊到了每个调用方脸上？很多“说不出哪里不对”的 PR，用这三问一照，问题立刻现形。
第二，重写你的技术选型标准。 把选型表的列从“功能丰富度、社区活跃度、上手速度”，增加一列“概念缠绕度”：这个框架要求我理解几个隐式约定？出问题时调试要穿过几层魔法？配置、注解、反射各占多少理解成本？上手快是 easy 的收益，理解成本低才是 simple 的收益——两列都填完再决策。
第三，从今天就能落地的三个小习惯。 默认用不可变数据结构（Python 里用 tuple 和 frozenset 代替会变的 list/dict，函数入参不原地修改）；状态收敛到少数明确入口，其余代码只做“值进值出”的纯函数；组件间优先考虑消息/队列而不是互相 import。这些改动单看都很小，但它们的方向是“拆线”而不是“编线”。
第四，AI 时代的加成。 当 AI 能让“写出能跑的代码”变得近乎免费，“什么代码值得写、什么架构值得留”的判断力就成了稀缺资源。Hickey 这套“简单性优先级”恰好是判断力的操作系统：AI 批量生成 easy 的代码毫无压力，但替你解开 complecting 的缠绕，目前还做不到——那是留给人的部分。
Easy 让你今天写得快，Simple 让你三年后改得动——这场演讲给你的不是技巧，而是一副能看见代码里每一股缠绕的眼镜。
本文由「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 等场景全覆盖。