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