principle-sequence-verifiable-units

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Sequence work into verifiable units

将工作拆分为可验证的单元

Order work as a sequence of small units, each ending in a state you can check, and don't advance until the current one is green. The same discipline runs at two altitudes, how you execute and how you deliver.

Why: A break caught at the unit that caused it is cheap to localize. A break caught after a batch is buried, and you have already built further on a broken base. Sequencing those same units into a delivery a reviewer can replay turns "trust me" into "watch it go red, then green."

Execution. In a sweep, migration, or any run of similar edits, verify each change before starting the next. Never batch the edits and verify once at the end. Each unit is a before/after bracket: known-good state, one change, run the check, then proceed. Rebase onto clean trunk first so every check measures against the real baseline. When a lever does the edits, the per-unit check is nearly free; run it anyway.

Delivery. Stack commits and PRs in the order that proves the work. The canonical shape is the failing test first, then the fix on top. The first unit shows the bug is real (red), the next shows it resolved (green), so a reviewer sees both the problem and the proof. Other story orders are a subtraction before the reshape, a baseline capture before the treatment, the scaffold before the feature. Each commit lands on its own and the sequence reads as an argument.

Pattern:

Pick the smallest unit that ends in a check: an edit plus its test, or a commit that stands alone.
Verify before advancing. Red to green per unit, never deferred to a final batch.
Order the units so the sequence builds confidence on its own, for you while executing and for a reviewer reading the stack.

The sequencing complement to the prove-it-works principle skill, which keeps each check real, and the build-the-lever principle skill, which makes the per-unit check cheap.

将工作安排为一系列小型单元的序列，每个单元都以可检查的状态收尾，在当前单元验证通过（状态正常）前不要推进后续工作。这一准则适用于两个层面：工作执行层面和交付层面。

原因： 在引发问题的单元阶段发现错误，定位成本很低。而在批量操作完成后才发现错误，问题会被掩盖，且你已经在错误的基础上进行了更多开发。将这些单元按顺序交付，让评审者可以复现整个过程，能将“相信我”转变为“看它从失败到成功的全过程”。

执行层面： 在批量修改、迁移或任何同类编辑操作中，在开始下一个修改前先验证当前修改。绝不要先批量完成所有编辑再一次性验证。每个单元都是一个“前后对比”的闭环：从已知的良好状态开始，进行一处修改，运行检查，然后再继续。首先要基于干净的主干（trunk）进行变基（rebase），这样每次检查都是基于真实的基准线。如果是用工具自动完成编辑，每个单元的检查成本几乎为零，但仍要执行检查。

交付层面： 按照能证明工作合理性的顺序堆叠提交（commit）和拉取请求（PR）。标准流程是先提交失败的测试，再在其之上提交修复代码。第一个单元证明bug确实存在（失败状态），下一个单元证明问题已解决（成功状态），这样评审者既能看到问题，也能看到修复的证据。其他合理的顺序包括：重构前先做减法、处理前先捕获基准线、先搭建框架再开发功能。每个提交都能独立成立，整个序列就像一个论证过程。

模式：

选择最小的、能以可检查状态收尾的单元：比如一处编辑加上对应的测试，或者一个能独立存在的提交。
推进前先验证。每个单元都要从失败到成功，绝不要推迟到最终批量验证。
合理安排单元顺序，让整个序列能自行建立可信度——无论是对你执行工作时，还是对评审者查看整个提交栈时。

这是“证明可行”原则技能的补充，后者确保每次检查都是真实有效的；同时也是“构建工具”原则技能的补充，后者让每个单元的检查成本变得低廉。