第3章：三思而后行：前期准备

先把未知项挡在编码之前

想象一支施工队：地基边界、承重约束和验收方式都没有写下，就直接把墙砌起来。墙也许能站住，但一次改门的位置就可能牵动整面墙。本章讨论的就是软件里的同一类风险：在实现规模变大前，先把最贵、最难回退的未知项暴露出来。

前期准备不是要求所有答案一开始就完美，而是要求每个暂时的答案都有范围、证据和重审时机。没有这层准备，需求变化会被误认为“只是加一行代码”，架构假设也会在集成阶段才第一次接受检验。

核心模型：从不确定性到开工门槛

本章把 不确定性 当作待处理的工程对象。先列出对象、边界、变化热点和失败代价，再用一次只改变一个条件的探针回答问题。探针不等于完整实现，它只需要足够小，能让团队决定继续、复核或停止。

一个实用的判断式是：返工风险会随着歧义和变更代价一起增大。它不是精确的数学定律，而是提醒我们把准备投入放到“最难回退的未知项”上，而不是平均撒在所有文档上。

3.1 前期准备的重要性

是准备工作的第一个可检查产物。它至少写出使用者要完成的结果、输入输出、不可接受的行为和两个验收例子。这样做的价值不在于冻结世界，而在于让下一次变化有可比较的起点。

如果一个决定会影响多个模块、数据格式或外部服务，就先记录它的假设和触发重审的条件。小项目也需要这样的轻量记录，只是可以是一页决策表；准备的厚度应随不确定性和回退成本变化，而不是随团队仪式感变化。

前期准备适用于现代软件项目吗

现代团队可能采用持续交付、短迭代和在线实验，但这些做法并没有消除准备问题，只是把准备拆进更短的反馈循环。每次发布前仍需要明确目标、影响范围、观测指标和回退办法；“先上线再看”本身也是一种需要承担后果的决策。

准备可以是最小化的：用一个可运行的接口样例验证外部约束，用一条数据迁移验证容量假设，用一个失败测试验证边界。只要它能在扩大实现前减少高代价未知项，就符合本章的前期准备原则。

准备不周全的诱因

最常见的诱因不是懒惰，而是把准备误解成低价值的文档工作。团队在时间压力下会先选择熟悉的工具、先写看得见的代码，或把尚未决定的内容留成“以后再说”；这些选择都让未知项悄悄进入实现。

另一个诱因是把所有需求都假设成同样稳定。真正需要优先准备的，是变化后会穿透接口、数据、部署或安全边界的部分。对这类变化先做影响分析，通常比写更多通用代码更快得到可靠反馈。

关于开始构建之前要做前期准备的绝对有力且简明的论据

最简明的论据是：编码会放大错误假设的传播范围，而准备可以用更小的成本验证假设。只要一个小时的探针能避免一周的错误集成，它就已经完成了准备工作的经济目标；若探针不能改变任何决定，就应停止继续堆文档。

因此，开工前不是追求“信息最多”，而是追求“关键未知项已经有裁决路径”。构建就绪 表示可以继续，也表示团队知道什么情况下必须停下来复核。

3.2 辨明你所从事的软件的类型

项目类型会改变准备的节奏。面向明确法规、固定接口或高代价迁移的系统，需要更完整的前置合同；探索性产品可以用短探针和小批量实现快速收集反馈，但不能把反馈本身当作无边界的许可。

的选择应回答三个问题：未知项能否在一轮内被验证，错误决定的回退成本有多高，以及谁能在下一轮提供独立反馈。答案比“团队习惯哪种方法”更重要。

迭代开发法对前期准备的影响

迭代开发把准备从一次性的长阶段分散到多轮。每轮开始时仍要更新需求基线，挑选一个高风险问题做探针，并在结束时记录实际反馈与下一轮的变化热点。这样可以缩短等待时间，但也要求每轮都有明确的退出条件。

迭代并不意味着“无需架构”。它更像是在有限范围内逐步验证架构假设：先选择最能暴露风险的纵向切片，再根据证据扩大范围。若每轮只增加功能、不复核跨模块合同，隐性返工仍会累积。

在序列式开发法和迭代式开发法之间做出选择

序列式方法适合前置约束强、变更昂贵且验收边界较稳定的场景；迭代式方法适合需要快速学习、能够隔离实验并且允许逐步交付的场景。两者不是道德偏好，而是对反馈和回退条件的回应。

选择时写下“为什么现在用它”和“什么事实会使我们重选”。如果外部接口还没有样例、容量还没有测量或关键使用者还没有确认，就不能用流程名称掩盖未决问题；先把问题缩小，再确定节奏。

3.3 问题定义的先决条件

问题定义先于功能列表：先说清谁遇到什么问题、成功状态是什么、哪些行为明确不在范围内。用一个小例子验证定义是否能被两位读者给出同样判断；如果两人对“完成”有不同解释，问题还没有定义好。

高风险问题应先做 探针。探针必须写出输入、预期输出、失败信号和停止条件，避免实验变成没有结论的原型堆积。

3.4 需求的先决条件

需求先决条件包括角色、触发条件、可观察结果、质量约束和异常路径。每一项都应该能落到一个例子或测试，而不是只有“快速、可靠、易用”这样的形容词。需求条目之间若存在冲突，要在开始构建前指定优先级。

为什么要有正式的需求

正式需求的作用是建立共同的可追踪对象：它让设计、代码、测试和验收可以指向同一条记录。形式不必厚重，一张带版本号的表也可以；关键是变化要能说明影响了哪些假设、例子和责任人。

稳定需求的神话

需求很少绝对稳定，稳定的是处理变化的协议。把变化热点标出来，给高风险条目预留复核点，并区分“改变结果合同”和“改变实现偏好”；前者需要重新评估设计与测试，后者可能只需局部修改。

把需求写成“永远不会变”会让变化变得尴尬且昂贵。更可靠的做法是保留旧基线、记录新基线、重跑受影响的验收例，并明确哪些兼容性承诺仍然有效。

在构建期间处理需求变更

收到变化时先暂停扩展实现，比较新旧基线：影响了输入输出、接口合同、数据迁移、性能目标还是部署约束？再用依赖图和最小探针估计影响范围，最后决定接受、拆分、延后或拒绝。

任何接受的变化都要留下回退点。若没有独立验收例、没有迁移方案或无法隔离失败，就不应把它伪装成普通的局部改动；继续编码只会把不确定性传播到更多构件。

3.5 架构的先决条件

架构准备不是提前决定所有类名，而是找出会跨边界传播的约束：数据所有权、外部依赖、容量、延迟、失败恢复、权限和部署拓扑。先为每个约束写一个可观察的验证方式，再决定需要多少设计。

架构的典型组成部分

典型组成部分包括关键职责、组件边界、接口与数据流、持久化策略、并发与失败处理、部署与运维假设。它们不需要都画成大图，但每一项都要能回答“谁负责、输入是什么、失败后怎样回到安全状态”。

3.6 花费在前期准备上的时间长度

准备投入应由风险驱动，而不是按固定比例分配。一个低风险、边界清楚的修改可能只需要几分钟的基线核对；一个涉及数据迁移、外部接口或不可逆部署的变化，则值得先做一轮可丢弃的探针。

判断“准备够不够”的信号有三个：关键未知项已经有证据或明确阻塞，下一步责任人知道要观察什么，失败时可以回退到一个已知状态。达到这三个条件就可以开工；继续写没有裁决作用的材料只是延迟反馈。

更多资源

本章的范围依据《Code Complete, 2nd Edition》的公开目录与出版社书目信息；软件工程术语和生命周期讨论再用 Microsoft Press 官方书页 与 IEEE Computer Society SWEBOK v4.0a 交叉核对。中文公开试读目录用于确认本章的 18 个正式节点，不代替未公开正文。

关键点

前期准备的核心不是预测所有未来，而是把最贵的未知项变成小而可判定的实验。先定义问题，再建立需求基线，识别架构风险，依据反馈和回退成本选择生命周期模型，最后用探针证据判断是否构建就绪。若一个决定没有预期、失败信号或退出条件，它还不是可以扩大实现规模的决定。

小结

• 准备的目标是降低高代价未知项，而不是堆积文档。
• 需求基线让变化可比较，架构风险让探针有优先级。
• 序列式与迭代式都需要反馈、责任和回退条件。
• 构建就绪意味着关键未知项已有证据或明确阻塞。

练习与独立验收

const readiness = {
  problemDefined: true,
  requirementsVersion: "r3",
  architectureProbe: "pending",
  rollbackPoint: "commit-42",
};