Back to Details

entropy-review

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Entropy Review

熵评审

Objective

目标

Review whether a software design, implementation plan, or implemented change introduces software entropy proportionate to the problem it solves.
Do not optimize for the fewest lines of code, and do not reject architecture, testing, or defensive design. Distinguish between:
  • Essential complexity inherent in the problem and its hard constraints.
  • Accidental complexity introduced by implementation, technology, or representation choices rather than by the problem itself. Pay particular attention to speculation, a drive for completeness, premature planning, and mechanism-first thinking.
Protect working software, fast feedback, reversible evolution, and long-term comprehensibility.
Treat software entropy as the tendency of accumulated concepts, structures, state, and rules to make a system increasingly difficult to understand, verify, and change.
Seek the minimum sufficient complexity for the current goal. Preserve necessary structure without letting completeness or robustness become reasons for unrelated mechanisms.
评审软件设计、实现方案或已落地的变更所引入的软件熵是否与其解决的问题相匹配。
不要为了最少代码行数而优化，也不要排斥架构设计、测试或防御性设计。需区分以下两类复杂度：
  • 本质复杂度：问题本身及其硬约束所固有的复杂度。
  • 偶然复杂度：由实现方式、技术选型或表达选择（而非问题本身）引入的复杂度。需特别关注投机性设计、追求完备性、过早规划以及「机制优先」的思维模式。
要保障可工作的软件、快速反馈、可逆演进和长期可理解性。
将软件熵定义为：系统中积累的概念、结构、状态和规则会让系统的理解、验证和修改难度持续上升的趋势。
为当前目标寻求最低足够复杂度。保留必要的结构，但不能让完备性或健壮性成为引入无关机制的理由。

Workflow

工作流程

1. Pin the Current Goal

1. 明确当前目标

Establish:
  • What specific problem must be solved now?
  • What facts prove that the problem exists?
  • What observable outcome proves that the problem is solved?
  • Which hard constraints must not be violated?
  • Which adjacent problems are explicitly out of scope?
Mark judgments without evidence as assumptions. Do not use assumptions as reasons to expand the solution.
明确以下内容：
  • 当前必须解决的具体问题是什么？
  • 有哪些事实证明该问题确实存在？
  • 哪些可观测的结果能证明问题已解决？
  • 哪些硬约束是不可违反的？
  • 哪些相邻问题明确不在范围内？
将没有证据支撑的判断标记为假设，不得将假设作为扩展解决方案的理由。

2. Describe the Minimum Sufficient Solution

2. 描述最低足够方案

Describe the smallest end-to-end solution that satisfies the current goal:
  • Cover only currently specified behavior.
  • Reuse existing concepts, structures, and paths where possible.
  • Produce observable and verifiable results early.
  • Preserve hard constraints.
  • Do not require one change to solve future stages.
Use this solution as a comparison baseline, not as a predetermined final answer.
描述满足当前目标的最小端到端方案：
  • 仅覆盖当前已明确的行为。
  • 尽可能复用现有概念、结构和路径。
  • 尽早产出可观测、可验证的结果。
  • 遵守硬约束。
  • 不要求一次变更解决未来阶段的问题。
将该方案作为对比基准，而非预先确定的最终答案。

3. Inventory New Obligations

3. 盘点新增义务

Identify every concept, layer, state, rule, exception, process, and maintenance duty introduced by the design, plan, or change.
Ask for each one:
  1. Which current goal does it directly serve?
  2. What current evidence shows that it is needed now?
  3. Which specified behavior or constraint would break if it were removed?
  4. Is there a smaller, more direct, or more reversible alternative?
  5. Can it be deferred until more feedback is available?
  6. Does it exist only to support another newly introduced mechanism?
  7. What ongoing understanding, synchronization, and maintenance costs does it create?
Do not retain mechanisms by default when these questions cannot be answered.
对每一项新增内容，追问以下问题：
  1. 它直接服务于哪个当前目标？
  2. 有哪些当前证据表明现在就需要它？
  3. 如果移除它，哪些已明确的行为或约束会被破坏？
  4. 是否存在更轻量、更直接或可逆性更强的替代方案？
  5. 它能否推迟到获得更多反馈后再实现？
  6. 它是否只是为了支撑另一个新引入的机制而存在？
  7. 它会带来哪些持续的理解、同步和维护成本？
如果这些问题无法得到解答，不要默认保留该机制。

4. Identify Sources of Entropy

4. 识别熵来源

Check:
  • Scope creep: Does the change solve problems outside the current acceptance scope?
  • Concept proliferation: Do new terms or abstractions add more cognitive cost than value?
  • Needless indirection: Do added layers exceed what the problem requires?
  • Duplicated state: Must multiple representations of one fact remain synchronized?
  • Special cases: Do a few exceptions impose broad, persistent rules?
  • Change amplification: Does a simple change require disproportionate knowledge, steps, or coordination?
  • Speculative generality: Are certain costs paid now for benefits that depend on unverified future assumptions?
Use these dimensions to find problems. Do not turn them into a mechanical score.
检查以下几类问题：
  • 范围蔓延：该变更是否解决了当前验收范围之外的问题？
  • 概念泛滥：新引入的术语或抽象带来的认知成本是否高于其价值？
  • 不必要的间接层：新增的层级是否超出了问题本身的需求？
  • 状态重复：同一事实的多种表示是否需要保持同步？
  • 特殊情况：少数例外是否催生了广泛且持续存在的规则？
  • 变更放大：一次简单的修改是否需要不成比例的知识、步骤或协调工作？
  • 投机性泛化：是否为了依赖未经验证的未来假设的收益，而在当下付出了成本？
从这些维度出发寻找问题，不要将其变成机械的打分项。

5. Distinguish Essential from Accidental Complexity

5. 区分本质复杂度与偶然复杂度

Keep complexity that:
  • Directly supports behavior that must be delivered now.
  • Protects a hard constraint.
  • Prevents a significant loss demonstrated by current evidence.
  • Remains necessary after a smaller solution has been shown to be insufficient.
  • Reduces overall duplication, divergence, or long-term maintenance burden despite being locally complex.
Simplify, defer, or remove complexity that:
  • Is justified mainly by “we may need it later.”
  • Treats completeness, sophistication, or convention as evidence.
  • Builds general capability for one concrete use case.
  • Creates more defenses to explain, verify, or maintain a defense.
  • Solves adjacent problems instead of the current goal.
  • Plans future stages before the first working result exists.
保留符合以下条件的复杂度：
  • 直接支撑当前必须交付的行为。
  • 用于保障某条硬约束。
  • 能避免当前证据已证实的重大损失。
  • 在更轻量的方案被证明不足以解决问题后，仍然必要。
  • 尽管局部复杂，但能减少整体的重复、分歧或长期维护负担。
简化、推迟或移除符合以下条件的复杂度：
  • 主要以「我们以后可能会用到」为理由。
  • 将完备性、精巧性或惯例当作证据。
  • 为单个具体用例搭建通用能力。
  • 为了解释、验证或维护某一个防御机制，又引入了更多防御机制。
  • 解决的是相邻问题而非当前目标。
  • 在第一个可工作的结果产出之前就规划未来阶段。

6. Run the Agility Check

6. 敏捷性检查

Check whether the design, plan, or change:
  • Can deliver observable results in small increments.
  • Obtains feedback about use, operation, or maintenance early.
  • Allows local modification, reversal, or replacement.
  • Makes decisions from current learning instead of trying to enumerate the future in advance.
  • Focuses effort on working results, not support structures or out-of-scope work.
If testing the core judgment requires a long investment, split the work into smaller increments or run an experiment first.
检查设计、方案或变更是否满足以下要求：
  • 能够以小增量交付可观测的结果。
  • 能尽早获得关于使用、运行或维护的反馈。
  • 支持局部修改、回滚或替换。
  • 基于当前的认知做决策，而非试图提前枚举所有未来可能性。
  • 将精力集中在可工作的结果上，而非支撑结构或范围外的工作。
如果验证核心判断需要大量投入，应将工作拆分为更小的增量，或先开展实验。

7. Decide What to Do

7. 确定行动方案

Choose one primary action for each mechanism:
  • Keep: Keep mechanisms that are currently necessary and whose evidence is proportionate to their cost.
  • Simplify: Simplify mechanisms whose goals are valid but whose implementation creates unnecessary obligations.
  • Reuse: Reuse existing capabilities when the need is valid and current capabilities are sufficient.
  • Defer: Defer decisions that may have value but lack current evidence.
  • Remove: Remove mechanisms that drift from the goal or cost substantially more to maintain than their current value.
  • Experiment: Test the key assumption cheaply before deciding whether to build the mechanism.
Do not merely label something “overdesigned.” Provide a smaller alternative that still satisfies the current goal.
为每个机制选择一项主要行动：
  • 保留：保留当前必要、且证据与其成本相匹配的机制。
  • 简化：对于目标合理但实现方式引入了不必要负担的机制，进行简化。
  • 复用：当需求合理且现有能力足够时，复用现有能力。
  • 推迟：对于可能有价值但缺乏当前证据支撑的决策，推迟决定。
  • 移除：移除偏离目标，或维护成本远高于当前价值的机制。
  • 实验：在决定是否构建该机制之前，以低成本验证关键假设。
不要仅仅给某样东西贴上「过度设计」的标签，要提供一个仍然能满足当前目标的更轻量替代方案。

8. Order the Lean Implementation

8. 安排精益实施顺序

Organize the work in this order:
  1. Remove content that drifts from the current goal.
  2. Define the minimum verifiable outcome.
  3. Reuse existing capabilities.
  4. Deliver the smallest end-to-end slice.
  5. Obtain feedback and test key assumptions.
  6. Add the next layer of complexity only after evidence appears.
Stop expanding when the current goal is satisfied and the next step is driven only by future assumptions.
按以下顺序组织工作：
  1. 移除偏离当前目标的内容。
  2. 定义最低可验证结果。
  3. 复用现有能力。
  4. 交付最小的端到端切片。
  5. 获取反馈并验证关键假设。
  6. 仅在有证据支撑时，再增加下一层复杂度。
当当前目标已满足，且下一步仅由未来假设驱动时，停止扩展。

Output Contract

输出规范

Provide:
  1. Verdict: Choose Keep, Simplify, or Remove. Explain the primary basis in one paragraph.
  2. Current goal and minimum sufficient solution: State the problem, observable completion outcome, hard constraints, and minimum sufficient solution.
  3. Review findings: For each actionable finding, state the mechanism, goal relationship, evidence, entropy cost, action, and a smaller alternative that preserves the same goal.
  4. Essential complexity: Identify what must remain and why.
  5. Lean implementation order: Provide independently verifiable steps with fast feedback.
  6. Assumptions to test: List unsupported assumptions and the cheapest way to test each one.
Report only findings that can change a decision or implementation approach. If no substantive issue exists, return Keep and stop; do not manufacture findings to fill the format.
评审需提供以下内容：
  1. 结论：从「保留」「简化」「移除」中选择一项，用一段话说明主要依据。
  2. 当前目标与最低足够方案：说明问题、可观测的完成结果、硬约束以及最低足够方案。
  3. 评审发现：针对每一项可落地的发现，说明机制、与目标的关联、证据、熵成本、行动建议，以及能达成相同目标的更轻量替代方案。
  4. 本质复杂度：明确哪些内容必须保留，以及原因。
  5. 精益实施顺序：提供可独立验证、能快速获取反馈的步骤。
  6. 待验证假设：列出无支撑的假设，以及验证每个假设的最低成本方式。
仅报告能够改变决策或实现方式的发现。如果不存在实质性问题，直接返回「保留」即可，不要为了填充格式而编造发现。

Boundaries

边界说明

  • Preserve essential complexity and required checks. To simplify either one, first reduce or postpone what the design is expected to do.
  • Treat architecture findings as advice. Leave approval, next steps, and changes to the agreed design to the designated human decision owner.
  • When reviewing architecture, first clarify what the design must do and how it will be checked. Then compare its cost with simpler options.
  • Do not use agility as a reason to ignore known risks, safety, integrity, or hard constraints.
  • Do not require extra artifacts merely to prove that the review occurred.
  • Do not expand this into a comprehensive correctness, security, or style review, or redesign the whole system unless the current goal requires it.
  • Do not let the review cost exceed the scale of the decision being reviewed.
  • 保留本质复杂度和必要的检查项。若要简化其中任何一项，需先减少或推迟设计预期要实现的功能。
  • 架构相关的发现仅作为建议。审批、后续步骤以及对已约定设计的修改，交由指定的人类决策负责人处理。
  • 评审架构时，首先明确设计必须实现的功能，以及验证方式，再将其成本与更简单的方案进行对比。
  • 不要以敏捷为理由忽视已知风险、安全性、完整性或硬约束。
  • 不要为了证明评审已开展而要求额外的产出物。
  • 除非当前目标有要求，否则不要将评审扩展为全面的正确性、安全性或风格评审，也不要重新设计整个系统。
  • 不要让评审成本超过被评审决策的规模。