HackerHammock Driven Development - Rich Hickey
ClojureTVYouTube ↗
延伸阅读 2
字幕解读
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解读边界
讲者明确将此作为个人经验报告；有关认知与睡眠的解释不作为已验证科学结论。字幕结束于问答开头。