Back to Details

reducing-entropy

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Reducing Entropy

减少代码熵

More code begets more code. Entropy accumulates. This skill biases toward the smallest possible codebase.
Core question: "What does the codebase look like after?"
代码越多，衍生的代码就越多。代码熵会不断累积。本技能倾向于打造尽可能精简的代码库。
核心问题： 优化后的代码库是什么样子？

Before You Begin

开始之前

Load at least one mindset from 
references/
  1. List the files in the reference directory
  2. Read frontmatter descriptions to pick which applies
  3. Load at least one
  4. State which you loaded and its core principle
Do not proceed until you've done this.
从
references/
目录中加载至少一种思维模式
  1. 列出参考目录中的文件
  2. 阅读前置描述，选择适用的思维模式
  3. 加载至少一种思维模式
  4. 说明你加载的思维模式及其核心原则
完成此步骤前请勿继续。

The Goal

目标

The goal is less total code in the final codebase - not less code to write right now.
  • Writing 50 lines that delete 200 lines = net win
  • Keeping 14 functions to avoid writing 2 = net loss
  • "No churn" is not a goal. Less code is the goal.
Measure the end state, not the effort.
目标是最终代码库的总代码量更少——而非当前编写的代码更少。
  • 编写50行代码以删除200行代码 = 净收益
  • 保留14个函数以避免编写2个函数 = 净损失
  • “无代码变更”并非目标，精简代码才是目标。
以最终状态而非工作量衡量成果。

Three Questions

三个关键问题

1. What's the smallest codebase that solves this?

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

Not "what's the smallest change" - what's the smallest result.
  • Could this be 2 functions instead of 14?
  • Could this be 0 functions (delete the feature)?
  • What would we delete if we did this?
不是“最小的变更是什么”——而是“最小的最终结果是什么”。
  • 能否用2个函数替代14个函数？
  • 能否用0个函数实现（即删除该功能）？
  • 如果这么做，我们可以删除哪些内容？

2. Does the proposed change result in less total code?

2. 拟议的变更是否会减少总代码量？

Count lines before and after. If after > before, reject it.
  • "Better organized" but more code = more entropy
  • "More flexible" but more code = more entropy
  • "Cleaner separation" but more code = more entropy
统计变更前后的代码行数。如果变更后行数更多，则拒绝该变更。
  • “结构更清晰”但代码量更多 = 代码熵更高
  • “更灵活”但代码量更多 = 代码熵更高
  • “关注点分离更清晰”但代码量更多 = 代码熵更高

3. What can we delete?

3. 我们可以删除哪些内容？

Every change is an opportunity to delete. Ask:
  • What does this make obsolete?
  • What was only needed because of what we're replacing?
  • What's the maximum we could remove?
每一次变更都是删除代码的机会。请思考：
  • 此变更会让哪些内容过时？
  • 哪些内容只是因为我们要替换的旧代码才存在？
  • 我们最多可以移除哪些内容？

Red Flags

警示信号

  • "Keep what exists" - Status quo bias. The question is total code, not churn.
  • "This adds flexibility" - Flexibility for what? YAGNI.
  • "Better separation of concerns" - More files/functions = more code. Separation isn't free.
  • "Type safety" - Worth how many lines? Sometimes runtime checks in less code wins.
  • "Easier to understand" - 14 things are not easier than 2 things.
  • “保留现有代码” - 这是现状偏见。我们关注的是总代码量，而非变更频率。
  • “这增加了灵活性” - 为了什么而灵活？YAGNI（你不会用到它）。
  • “更好的关注点分离” - 文件/函数数量更多 = 代码量更大。关注点分离并非无成本。
  • “类型安全” - 这值得付出多少代码行数？有时用更少的代码实现运行时检查反而更优。
  • “更易于理解” - 14个模块并不比2个模块更容易理解。

When This Doesn't Apply

不适用场景

  • The codebase is already minimal for what it does
  • You're in a framework with strong conventions (don't fight it)
  • Regulatory/compliance requirements mandate certain structures
  • 代码库对于其实现的功能而言已经足够精简
  • 你使用的框架有严格的约定（不要违背这些约定）
  • 监管/合规要求强制规定了特定的代码结构

Reference Mindsets

参考思维模式

See 
references/
for philosophical grounding.
To add new mindsets, see 
adding-reference-mindsets.md
.
Bias toward deletion. Measure the end state.
请查看
references/
目录获取相关理念基础。
如需添加新的思维模式，请查看
adding-reference-mindsets.md
。
倾向于删除代码。以最终状态衡量成果。