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`。 --- **偏向于删除。衡量最终状态。**