Hacker"Simple Made Easy" - Rich Hickey (2011)
Strange Loop ConferenceYouTube ↗
延伸阅读 4
测一条业务规则，为什么要连数据库？ →把「谁该收到提醒」单独拿出来，就能分别检查规则是否正确、通知能否送达。一个模块究竟答应了调用者什么？ →想换掉一个模块，却发现别处依赖它碰巧返回的顺序。从「接口写了什么」往前走一步：哪些决定本该藏在里面，又有哪些行为已经被人当成承诺？本片参与的问题 · 少即是少处理例外与纠缠切开代码，就切开了依赖吗？ →从一条要发邮件的规则开始。先把判断和执行分开，再检查分层、对象和抽象：改动一条业务规则时，哪些地方还是必须一起改？本片参与的问题 · 把可以独立的职责真正拆开一条记录能同时回答「现在」和「当时」吗？ →两次查询得到了不同答案。先问你在读哪个时刻的值，再问谁能修改它。保存历史与协调写入解决的是不同的问题。本片参与的问题 · 从状态的时间依赖走向带时间的事实
字幕解读
Rich Hickey 把简单定义为关注点之间没有纠缠，把容易定义为熟悉、可获得或符合个人能力。他主张评估工具生成的系统，而不只看编写体验；测试、类型系统和模块划分无法替代对依赖的理解。讲座用状态、对象和控制流说明隐含耦合，再讨论值、函数、小抽象、队列和声明式规则如何拆开职责，同时承认资源竞争仍有未解决的复杂性。
英文字幕轨道 · 引文按字幕原文展示，可点时间戳回看片段。
内容要点
- 简单的判断标准是原本能够独立的概念是否被纠缠；熟悉和好上手是另一维度。
- 可变状态把值与时间绑在一起；藏进方法或类里仍可能把这种依赖传给调用方。
- 用小抽象和声明式接口分离要做什么与如何实现，再以队列等机制分开执行时机和位置。
视频章节 6
- 简单与容易
区分结构上的独立与使用者的熟悉程度。
- 从编写体验转向系统产物
说明认知限制、隐含依赖和测试的边界；速度曲线是说明性假设。
- 选择较少纠缠的工具
比较构造的产物，解释为什么模块划分不等于简单。
- 状态、值与替代构造
讨论状态泄漏、不可变值、函数、数据、协议和声明式工具。
- 设计独立的职责
承认环境资源竞争难题，并拆解 what/how/who/when/where/why。
- 保持数据通用与持续简化
避免把数据绑定到表示细节，以可独立变化的部分构成系统。
具体观点与证据 4
评估语言和工具应看它们产生系统的可靠性、可维护性等长期性质，而不只看输入代码是否方便。
区分作者体验与成品复杂性，不否定工具易用性本身。
We have to start assessing our constructs based around the artifacts,类和层次分开不代表系统简单，隐藏语义依赖仍会把模块绑在一起。
模块组织只有结合关注点解耦才有效。
don't associate simplicity with partitioning and stratification, right?把可变实现包在普通方法后并不能隔离状态复杂性，真正稳定的函数式接口才能阻止其向调用者扩散。
允许内部实现可变，要求外部观察满足相同输入相同输出。
a true functional interface, same input, same output.多个组件各自按CPU核数配置线程池，局部合理策略可能在同一进程争夺资源；这类环境复杂性仍未解决。
讲者承认资源政策协调的限制，而非宣称不可变数据解决所有复杂性。
I'll just size my thread pool to be the number of cores.补充字幕原文 2
简单的判断标准是原本能够独立的概念是否被纠缠；熟悉和好上手是另一维度。
start seeing interconnections between things that could be independent可变状态把值与时间绑在一起；藏进方法或类里仍可能把这种依赖传给调用方。
Having state in your program is never simple, right?解读边界
字幕轨道标记为非自动生成，但本次未听音频核对；原字幕仍有拼写和转写问题。 简单/复杂是讲者提出的分析框架，不应转换成经过测量的质量分数。 讲者承认动态性等取舍以及资源竞争问题；不能总结为所有场景都禁用状态。