reducing-entropy

降低熵

代码越多，越容易滋生更多代码。熵不断累积。本技能倾向于尽可能小的代码库。

核心问题： "代码库在之后会是什么样子？"

开始之前

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

1. 列出参考目录中的文件
2. 阅读前置描述以选择适用的思维模式
3. 加载至少一种
4. 说明你加载了哪种及其核心原则

在完成此操作之前，请勿继续。

目标

目标是最终代码库中的总代码更少——而不是现在要写的代码更少。

• 写50行代码删除200行 = 净收益
• 保留14个函数以避免写2个 = 净损失
• "无变动"不是目标。更少的代码才是目标。

衡量最终状态，而非工作量。

三个问题

1. 解决这个问题的最小代码库是什么？

不是"最小的改动是什么"——而是最小的结果是什么。

• 能否用2个函数代替14个？
• 能否用0个函数（删除该功能）？
• 如果这样做，我们会删除什么？

2. 提议的改动是否导致总代码减少？

计算改动前后的代码行数。如果之后 > 之前，则拒绝。

• "组织更好"但代码更多 = 熵增加
• "更灵活"但代码更多 = 熵增加
• "更清晰的分离"但代码更多 = 熵增加

3. 我们能删除什么？

每次改动都是删除的机会。问：

• 这会使什么变得过时？
• 什么只是因为我们要替换的东西而存在？
• 我们最多能移除什么？

警示信号

• "保留现有的" - 现状偏见。问题是总代码量，而非变动量。
• "这增加了灵活性" - 为谁增加灵活性？YAGNI。
• "更好的关注点分离" - 更多文件/函数 = 更多代码。分离不是免费的。
• "类型安全" - 值得多少行代码？有时运行时检查用更少的代码胜出。
• "更容易理解" - 14件事并不比2件事更容易理解。

何时不适用

• 代码库对于其功能已经是最小的
• 你处于具有强约定的框架中（不要对抗它）
• 法规/合规要求强制某些结构

参考思维模式

参见 references/ 获取哲学基础。

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

---

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