按评审要求划分任务大小

以下示例与示意结果由本站编写，用于说明方法，不是模型实测结果。

使用场景

一个功能要新增解析器并让 UI 显示结果。教学解析契约是 parseLine(text) 返回 value 或可辨识的解析错误；UI 负责显示成功与错误。拆任务时既不能每行一个，也不能整产品只有一个无法独立判断的任务。

具体做法

用可独立评审的行为划边界，明确输入、交付和覆盖检查。解析任务拥有契约与边界样例，UI 消费已确定契约并拥有交互状态检查；需要同时改的签名和调用保持协调。设置、说明和测试跟随需要它们的交付，不拆成没有独立结果的碎片。最后保留集成检查。

反例

把每个变量和每行解析代码各设一个任务，另把 UI 调用签名改动分散到多个并行任务，谁都不负责完整行为。

改进写法

按教学功能划两项可评审任务：解析器定义 parseLine 的成功/错误契约并验证正常、空输入和非法输入；UI 在该契约上显示结果与错误，验证输入、反馈和恢复。把耦合签名变更与必要调用适配协调到同一交付，注明依赖并加最终集成检查。每项都有独立可接受或拒绝的结果，而不是只按代码行数切分。

为什么这样改

过碎任务缺少完整行为，过大任务又难以归因和独立审阅。行为契约使每项任务有明确判断，同时依赖和集成检查保留跨边界的正确性。

如何验证

示意评审可以接受解析器而拒绝 UI 的错误反馈，说明两项有独立标准；也能发现 UI 调用与解析签名不一致的集成问题。

检查任务包括所需输入、测试和适配，不存在“改一行”却无人负责结果的碎片。任务数多不自动代表拆分合格。

适用边界

横切修改可能需要额外集成任务或更大协调单元。源文件数和时间估计不是通用大小标准；同一契约尚未确定时，不应把紧耦合任务假装成可独立执行。