Hammock Driven Development - Rich Hickey
ClojureTV在 YouTube 播放 ↗
字幕解读
Rich Hickey 把编程首先看成问题求解：先写清问题、约束、未知项与备选方案，再给专注思考和后台酝酿留出时间。他建议记录、比较、研究已有方案，并利用睡眠与暂时离开电脑来重新组织认识。最后仍要实现和运行方案，用新事实修正原有假设，而非把前期设计当成永不修改的答案。
自动字幕 · 引文按字幕原文展示，可点时间戳回看片段。
内容要点
- 先辨认问题和错误假设；测试通过不等于构思本身正确。
- 写下事实、约束与未知，比较不同方案，再给持续思考和酝酿留时间。
- 实现后仍需运行、观察和修正；这不是一次设计后拒绝反馈的瀑布流程。
视频章节 6
- 为什么需要留出思考时间
- 实现错误与构思错误
- 把问题、事实与未知写下来
- 研究、比较与批判自己的方案
- 专注、后台思考与睡眠
- 实现、反馈与承认错误
具体观点与证据 4
实现测试和类型检查通常无法发现最初的问题定义或解决思路就是错的。
讲者承认它们可处理实现缺陷，并非主张取消测试。
problem s of misconception are not generally addressed by testing or type systems所谓权衡必须至少比较两个方案的优缺点，而非给单一方案的缺点找理由。
比较须围绕实际问题与约束。
you have to look at at least two solutions to your problem把事实、约束与未知写下来，并研究既有方案，为后续深入思考提供材料。
演讲是个人经验报告，睡眠和后台思维不是经过本文实验验证的方法学。
looking at other solutions to the same problem is the number one way前期思考之后仍须运行实现验证假设，新事实出现时应重新评估并改变方案。
这不是一次性完备设计或拒绝迭代的瀑布模式。
when the facts change do not dig in do it over again补充字幕原文 2
先处理构思层面的错误，而非只纠正实现。
most of the big problems we have with software are problems of misconception实施后允许返回修改；不是拒绝反馈。
you're going to try stuff and go back解读边界
讲者明确将此作为个人经验报告；有关认知与睡眠的解释不作为已验证科学结论。字幕结束于问答开头。
阅读准备 带上一个还没想清楚的设计问题。
相关视频与证据 2
互补方法慢思考与即时反馈，必须二选一吗？
Hammock 强调思考但也明确允许试验后返回修改；Inventing 主张创作者与产物保持即时联系。它们可以分别服务问题构思与实现探索，而不是简单的快慢对立。
Hammock Driven Development - Rich Hickey
实施后允许返回修改；不是拒绝反馈。
you're going to try stuff and go backBret Victor - Inventing on Principle ↗
创作者应立即看到其修改所产生的影响；这是演讲提出的具体设计原则。
creators need an immediate connection to what they create▶ 2:01–2:08 · 观看片段适用边界 互补是本站提出的阅读视角。短引文不证明两种方法必然兼容所有任务，也不构成两位作者之间的辩论。
方法补充从识别结构纠缠，退回到审视构思
Simple Made Easy 让我们检查概念之间不必要的关联；Hammock 则提醒许多严重问题源于错误构思。两者把关注点从更快地写出代码移向先理解问题与结构。
"Simple Made Easy" - Rich Hickey (2011) ↗
简单的判断标准是原本能够独立的概念是否被纠缠；熟悉和好上手是另一维度。
start seeing interconnections between things that could be independent▶ 59:28–59:32 · 观看片段Hammock Driven Development - Rich Hickey
先处理构思层面的错误，而非只纠正实现。
most of the big problems we have with software are problems of misconception适用边界 两段分别谈系统结构与问题求解，不可把所有构思错误归因为耦合，也不是效率提升的实证证明。