reducing-entropy

减少熵

代码越多，催生的代码就越多。熵会不断累积。这项技能倾向于尽可能精简代码库。

核心问题：“之后的代码库会是什么样子？”

开始之前

至少从 references/ 加载一种思维方式

1. 列出参考目录中的文件
2. 阅读文件头部的描述，选择适用的一种
3. 加载至少一种
4. 说明加载了哪一种，以及它的核心原则

完成这些之前，不要继续。

目标

目标是让最终代码库中的代码总量更少，而不是减少眼下要写的代码。

• 编写 50 行代码，删除 200 行代码 = 净收益
• 保留 14 个函数，以避免编写 2 个函数 = 净损失
• “不折腾”不是目标。更少的代码才是目标。

衡量最终状态，而不是投入的精力。

三个问题

1. 解决这个问题所需的最精简代码库是什么样的？

不要问“最小的改动是什么”，而要问“最小的结果是什么”。

• 能否用 2 个函数代替 14 个？
• 能否一个函数都不用（删除这个功能）？
• 如果要这么做，我们会删除什么？

2. 拟议的改动是否会减少代码总量？

统计改动前后的行数。如果改动后更多，就否决它。

• “组织得更好”，但代码更多 = 熵更大
• “更灵活”，但代码更多 = 熵更大
• “职责划分更清晰”，但代码更多 = 熵更大

3. 有什么可以删除？

每次改动都是删除代码的机会。问问自己：

• 这会让什么变得多余？
• 有什么只是因为我们要替换的内容才需要？
• 最多可以删除什么？

危险信号

• “保留现有内容”——现状偏见。要考虑的是代码总量，而不是改动幅度。
• “这样更灵活”——为了什么灵活？YAGNI。
• “职责划分更清晰”——文件和函数越多，代码就越多。职责划分并非没有代价。
• “类型安全”——值得增加多少行代码？有时用更少的代码进行运行时检查更合算。
• “更容易理解”——14 项并不比 2 项更容易理解。

不适用的情况

• 代码库对于其功能而言已经足够精简
• 你使用的框架有严格的约定（不要与之对抗）
• 法规或合规要求规定了某些结构

参考思维方式

参见 references/，了解其理念基础。

要添加新的思维方式，请参见 adding-reference-mindsets.md。

---

倾向于删除。衡量最终状态。