大众普遍认为 "Clean Code" 是由 Robert C. Martin (Uncle Bob) 在 2008 年发明的，但这是一种曼德拉效应。Kevin Henney 通过“代码诠释学”挖掘了这一术语的真实历史：
尽管该书后来受到争议，但两位嘉宾给出了公允的评价：这是一个文集（Anthology），质量取决于章节作者。
👆 点击卡片翻转，查看深度解析
来源： Richard Gabriel (Pattern Language 社区)
定义： 代码不应仅仅是易读的，而应像家一样。包含两个核心体验：
误区： 像刷牙一样的个人习惯。
真相： 这是一个专业工作环境的要求（如米其林厨房）。
目的： 不是为了显得干净，而是为了持续、快速、安全地交付价值（菜品）。
背景： 提及 HTMX 框架及 Single Goal Principle。
核心： 传统的“关注点分离”往往导致逻辑分散在 UI、API、DB 层。LoB 主张将为了达成同一目标的代码物理上放在一起。
金句： "Single Goal Principle" > "Single Responsibility Principle"。
来源： Eliyahu Goldratt《目标》(The Goal)。
逻辑： 任何系统都有一个瓶颈（约束）。
应用： 只有当代码质量成为阻碍价值流动的瓶颈时，优化它才有意义。如果在非瓶颈处进行“洁癖式”优化，就是浪费资源（过度工程）。
问题： 盲目追求“函数要小”，会导致碎片化 (Fragmentation)。
衡量标准： "Small" 不应指代码行数，而应指需要的思维量。如果为了理解逻辑需要在10个小文件间跳转，这种“小”反而增加了认知负荷。
结论： 不大不小，刚好放入大脑工作记忆（Working Memory）的代码才是最好的。
定义： 研究文本时考虑其历史背景的方法。
案例： 为什么以前建议拆分文件？
背景： 90年代因物理分工（DBA/UI团队不同），必须物理隔离文件以防冲突。现在全栈时代，这种做法已过时。
启示： 不要盲从旧建议，要理解其产生的上下文。
访谈最终得出结论：Clean Code 不是一个静态的、绝对的标准，而是一种关系（Relational Thing）。
它关乎：
最终建议：关注“最佳简单系统（Best Simple System）”，追求低认知负荷和行为局部性，而不是死守行数限制。