thinking-dhh

name	thinking-dhh
description	DHH's thinking framework — convention over configuration, ship fast, perfect is the enemy

4. "正常人在8小时内可以把事情做得很好。加班是管理失败的症状，而不是勤奋的标志。" ——DHH，《重来》（Rework，2010）

5. "好的软件是迭代出来的，不是设计出来的。你不可能在纸上设计出完美产品，然后按照图纸施工。" ——DHH，Basecamp博客，2014

6. "测试不是信仰。测试是工具。如果测试阻碍了你的开发速度，那测试就变成了问题。" ——DHH，Twitter/X，2014-2019期间对TDD文化的批评

7. "我们拒绝的功能比接受的多10倍。大多数功能提案在第一天就被否决了。" ——DHH，Basecamp团队采访，2018

8. "Ruby on Rails不是为了改变世界而创造的。它是因为我厌倦了当时写web应用的痛苦，我想让那种痛苦消失。" ——DHH，Rails创始人访谈，2015

实战模板（3个）

模板一：功能评估检查（足够好模式）

功能提案：[描述]
日期：[今天]
评估人：足够好模式

问题一：这个功能解决的是真实问题吗？
- 有没有用户明确要求？（vs PM/老板觉得用户需要）
- 这个问题有多痛？（1-10）
- 如果不做这个功能，用户现在怎么解决这个问题？

问题二：这个功能需要多少开发资源？
- 预估工时：[X]天
- 机会成本：这X天如果做别的能做什么？
- 复杂度评分（1-5）：[复杂度越高越要谨慎]

问题三：最小可行版本是什么？
- 能不能用更少的代码/功能达到80%的价值？
- 能不能先做一个"看起来像"的版本验证需求？
- 最坏情况：如果没人用，损失是多少？

问题四：增加复杂度评估
| 维度 | 影响 | 严重程度 |
|------|------|---------|
| 代码量增加 | [X]行 | 高/中/低 |
| 维护负担 | [增加什么维护工作] | 高/中/低 |
| 学习成本 | [新人要学多久] | 高/中/低 |
| 依赖复杂度 | [引入了什么依赖] | 高/中/低 |

足够好评估：
□ 做最小版本（1-2天能完成的核心功能）
□ 不做（问题不真实或复杂度太高）
□ 以后再做（等更多信息）
□ 合并到别的功能里（不要单独加功能）

决策：[具体行动]
理由：[为什么这个决策是"足够好"的]

模板二：技术选型评估（固执-灵活模式）

技术选型：[X技术]
日期：[今天]

第一步：形成观点（固执）
- 你对这个技术的立场是什么？（强力支持/强力反对/中立）
- 你的立场基于什么依据？
- 你有没有深入使用过这个技术？

第二步：反向证据
- 最强的反驳证据是什么？
- 有没有使用这个技术失败的案例？
- 什么情况下这个技术不是最佳选择？
- 你有没有可能是错的？[诚实评估]

第三步：评估场景匹配度
| 维度 | X技术 | 当前需求 | 匹配度 |
|------|------|---------|-------|
| 规模 |        |          |        |
| 团队大小 |        |          |        |
| 维护能力 |        |          |        |
| 时间约束 |        |          |        |

第四步：决策树
- 如果X技术失败，最坏情况是什么？能不能承受？
- 有没有"后悔药"？（能否平滑迁移）
- 如果不用X，有没有备选？

固执程度评级：
- 10 = 强烈信念，几乎不可能改变
- 7-9 = 较强信念，会被强力证据说服
- 4-6 = 中等信念，容易被说服改变
- 1-3 = 开放态度，以实际证据为主

最终建议：[做/不做/继续观察]
置信度：[X%]

模板三：发布决策清单（MVP模式）

发布版本：[版本号]
日期：[今天]
发布内容：[简述]

第一步：必要检查
□ 核心功能能正常工作吗？（不是所有功能，是核心）
□ 用户能完成主要任务吗？（端到端走一遍）
□ 崩溃率在可接受范围吗？（<1%？）
□ 性能在可接受范围吗？（首屏<3秒？）

第二步：回滚计划
- 能不能一键回滚？（还是需要手动修复）
- 回滚需要多少时间？
- 什么情况下应该立即回滚？

第三步：灰度策略
- 能不能先发布给5%的用户？
- 有没有监控能看到异常？
- 负责人能第一时间收到告警吗？

第四步：信息同步
- 运营/客服知道新功能了吗？
- 知道如何处理用户问题了吗？
- 有没有准备好FAQ/公告？

第五步：发布后验证
- 发布后1小时内检查什么指标？
- 发布后24小时内检查什么指标？
- 什么指标表示功能成功？

MVP检查结论：
□ 可以发布
□ 需要修复才能发布
□ 需要缩小范围才能发布

发布负责人：[X]
发布时间：[具体时间]

应用场景

场景一：评估要不要加某个功能

当产品经理提议"我们加一个X功能"：

1. DHH三问：真问题吗？代价多大？有更简单方案吗？
2. 最小版本：能不能用最小的方式验证这个需求？
3. 减法原则：加上这个功能的同时，有没有可以移除的功能？
4. 拒绝的力量：DHH团队拒绝90%的功能提案——不是每个好主意都要现在做

场景二：技术选型（要不要引入新技术）

当团队讨论要不要用某个新框架/工具：

1. 真问题吗：当前技术的痛点是什么？是真实痛点还是"用新技术"的冲动？
2. 复杂度评估：引入这个技术的总代价（学习+维护+迁移）值得吗？
3. 固执-灵活：你对不用这个技术有多固执？你愿不愿意被实际证据说服？
4. DHH版：你们的问题是不够大吗？如果不是微服务规模，用Rails可能更好

场景三：发布节奏和迭代策略

在决定发布节奏时：

1. MVP优先：先发布一个能用的最小版本，不要憋大招
2. 快速反馈：发布后立即收集用户反馈，用真实数据修正方向
3. 接受重写：DHH："我们在每个版本都会重写一部分代码，因为学习本身就是设计"
4. 足够好的发布：不是"完美才发布"，而是"够用就发布，然后迭代"

场景四：处理"技术债"

当开发者说"我们需要重构，需要2个月"：

1. 真实影响：这个技术债导致的额外工作量是多少？（量化）
2. 机会成本：这2个月如果做新功能，业务价值是什么？
3. 渐进式：能不能在不重写的情况下逐步改善？
4. DHH的回答："大部分技术债是开发者给自己的借口，想重写不是因为真的需要，是因为想用新技术"

反模式

反模式一："完美主义瘫痪"

症状：总觉得代码不够好、架构不够完美、功能不够完整，永远不发布。

后果：竞争对手发布了类似但"不完美"的产品，抢占了市场；团队士气低落，看不到产品上线。

DHH的解药："完美是完成的敌人。发布一个80分的产品，然后迭代到90分，比永远等待100分更有价值。"

反模式二："过度工程"

症状：提前设计"能服务5年"的架构，使用"未来可能需要"的设计，引入"这个很流行"但实际不需要的技术。

后果：系统越来越复杂，没人能完全理解；维护成本指数级上升；新人上手需要几个月。

DHH的解药："如果你的团队只有10个人，不要用微服务。大多数'过度工程'是为了让架构师感觉良好，不是为了解决实际问题。"

反模式三："TDD原教旨主义"

症状：必须100%测试覆盖才敢发布，必须先写测试才写代码，测试失败就不能部署。

后果：开发速度变慢，创新被压制；当测试本身有bug时，整个系统被误判。

DHH的立场：测试是工具，不是信仰。测试的目的是让你有信心快速迭代，不是为了满足"100%覆盖率"这个虚荣指标。

反模式四："功能通胀"

症状：每个版本都在加功能，产品越来越臃肿，但活跃用户不增长；团队忙于维护旧功能，没时间做新功能。

后果：用户体验下降，产品失去焦点；维护成本吞噬开发资源；团队失去方向感。

DHH的解药：加每个功能的同时问：有没有可以移除的功能？坚持"减法原则"——最好的新功能往往是去掉的功能。

反模式五："加班=努力"

症状：项目紧就加班，上线前通宵，节假日赶工，把加班当成解决问题的默认方式。

后果：短期产出增加，长期效率下降； burnout；代码质量下降引入更多bug；创新能力和判断力受损。

DHH的数据：Basecamp团队坚持每周4天工作制，他们的产品质量和产出效率在行业内名列前茅。"正常人在8小时内可以把事情做得很好。"

---

DHH思维框架的核心：完美是完成的敌人，足够好才是行动的开始。固执但不僵化，迭代优于完美计划，简约设计比功能堆砌更有力量。最重要的决定往往不是你做什么，而是你不做什么。