写作是一种慢速编译

我有一个不太高效的习惯：动手之前先写一篇东西。不是设计文档，也不是 RFC，就是一篇给未来的自己看的说明文。

写作暴露你没想清楚的地方

代码可以含糊。变量名起得糟糕、边界条件没考虑，它照样能跑，只是三个月后你会对着它发呆。

文字不行。你写“这个模块负责同步状态”，读者会立刻问：同步什么状态？从哪到哪？失败了怎么办？一旦这些问题问出口，你就知道自己的设计还缺一块。

写作是唯一一种强迫你把隐含假设说出来的活动。

它比设计文档更便宜

正式的设计文档有格式、有评审、有签署流程。成本太高，导致大家只在“大改动”时才写，而大多数问题恰恰藏在“小改动”里。

我的做法是写一段 300 字的说明，包含三件事：

1. 这个改动要解决谁的什么问题
2. 我打算怎么做，为什么不是别的做法
3. 什么情况下我会承认它失败了

第 3 条最有用。它逼你提前定义验收标准，而不是事后找理由。

慢，但是值得

写完再写代码，前 30 分钟看起来是浪费的。但它的收益在三个地方：

• 减少返工：想清楚边界条件，比写完再补便宜得多
• 减少会议：一段清晰的文字，可以替代一次同步会
• 留下痕迹：半年后你会感谢自己，而不是对着 git blame 猜

一点方法论

如果不知道从哪开始，试试这个顺序：

• 先写一句话结论，放在最前面
• 再写反对意见，把自己最强的反驳写出来
• 最后写细节，只写支撑结论必需的部分

这个顺序的好处是：如果一句话结论写不出来，说明你还没想清楚，后面的内容都不必写。

---

写作和编译确实很像。你把模糊的、互相矛盾的想法放进脑子里，经过一轮又一轮的压缩和消歧，最后输出一段能被别人（和未来的自己）执行的指令。

区别在于，编译器会报错，而写作不会。它只是安静地让你以为你想清楚了。