第9章 管理软件生命周期

为什么不能等到最后才拼装

盖一栋楼，不会等所有材料到齐才第一次拼起来。地基、结构和管线在施工中就要反复核对，越晚发现对不上，返工代价越大。

写软件也一样。如果设计、编码、测试和上线各干各的，直到要交付那天才把所有零件第一次组装，对不上的地方会集中爆发，而且没人说得清是谁的问题。

这一章讲怎样把整个过程拆成一段段可验收的步骤，每段结束都留下证据，让另一个人能照着证据重放一遍结论。没有这套规矩，"在我机器上能跑"就成了唯一的担保。

原书骨架与现代迁移

官方章节围绕生命周期模型、迭代式计划与开发、全局调试与发布、Trac跟踪系统、关闭与复盘展开。原书出版于Python 2.5与早期敏捷工具生态，本章保留它解释"为什么"的结构；命令和安全默认按当前Python、标准库与PyPA维护文档迁移，不把EasyInstall、distutils安装命令、旧CI或旧项目平台直接当成新项目默认。

承接前两项，把局部语法或工具放回应用数据流。阅读时沿输入、协议、状态、输出和证据追踪，避免只背API名称。

机制一：生命周期模型与可验收增量

瀑布、螺旋和迭代模型对反馈时机与风险暴露方式不同；所谓生命周期模型，选择应由不确定性、法规和交付成本决定，而不是把某种流程当成仪式。把目标拆成可验收增量，每次迭代包含设计、实现、测试和反馈；任务完成定义必须包含文档、迁移与运行证据。先写出公共行为和失败类型，再选择语法或工具。这样即使实现从原书工具迁到当前生态，调用者仍能依据相同契约判断结果。

工单状态是生命周期模型的直接体现，下面两种视角对比同一段状态契约：

from enum import Enum
 
class IssueState(Enum):
    PLANNED = "planned"
    ACTIVE = "active"
    VERIFIED = "verified"
    RELEASED = "released"

PLANNED  计划已立项 —— 明确验收条件，未开始实现
ACTIVE   正在实现 —— 含设计、编码、测试与反馈
VERIFIED 已验证 —— 跨模块契约与边界实验通过
RELEASED 已发布 —— 冻结输入与候选制品已提升

提醒我们：抽象不能消除成本，只会改变成本出现的位置。包装、生成器、构建系统、CI或缓存都必须说明资源、顺序和异常传播。

目标 -> 验收条件 -> 实现与测试 -> 候选制品
     -> 集成验证 -> 发布 -> 监控 -> 复盘行动

机制二：全局调试与发布

集成阶段检查跨模块契约、性能和部署环境，发布使用冻结输入与候选制品；在发布当天首次组合系统会把未知风险集中爆发。原书用Trac串联ticket、里程碑、版本库和Wiki；现代平台可以替代工具，但需求、变更、决策和证据的双向链接不可丢失。边界实验至少包含正常、空输入、上限附近、依赖失败和重复执行。涉及网络、并发或外部制品时，再加入超时、取消、部分完成与摘要校验。

发布制品的元数据把不变量固化下来，下面两种视角对比同一段发布逻辑：

release:
  commit: "<immutable-sha>"
  migrations: verified
  rollback: rehearsed
  owner: release-manager

commit     不可变 SHA —— 从冻结输入构建，可重放
migrations 迁移已验证 —— 向前向后都跑过
rollback   回滚已演练 —— 不是首次在故障时才试
owner      发布负责人 —— 出问题能找到人

历史工具不等于无价值。正确迁移是先提取声明式配置、隔离、持续反馈和可回滚发布等不变量，再用维护中的接口重写；错误做法是机械替换命令却保留隐式环境和不可追踪副作用。

机制三：关闭与复盘

负责收束验收。迭代结束要关闭或重排未完成项、记录偏差和行动负责人；复盘关注系统条件而非个人归罪，并验证改进是否在下一迭代执行。保存解释器、依赖锁定、输入、命令、退出状态、关键输出和制品摘要，才能让另一台干净机器重放同一结论。

动手：追踪一条需求的生命周期

下面把本章五个环节排成一条流水线。点击每个节点看它的责任和失败模式，再打开"注入常见故障"对照翻车现场。

猜一猜：打开"注入常见故障"后，哪个环节的失败会直接波及发布？

实战验收清单

1. 在隔离环境运行三段示例，记录解释器实现、版本和依赖来源。
2. 为核心行为增加正常、空输入、失败和重复执行测试，先看到失败再修改实现。
3. 清理缓存和临时文件后重跑，证明结果不依赖工作区残留。
4. 对历史命令写出当前替代路径，并说明保留的架构不变量与不再采用的安全默认。

容易踩的坑

误区 1

现象 → 把某种流程当仪式，走完流程却无价值 原因 → 盲目套用生命周期模型，未按不确定性、法规和交付成本选择 修法 → 先评估反馈时机与风险暴露方式，再选模型

误区 2

现象 → 迭代结束交付不完整，文档、迁移和运行证据缺失 原因 → 完成定义不含可验收条件，只看代码是否写完 修法 → 完成定义须含文档、迁移与运行证据，每次迭代可独立验收

误区 3

现象 → 发布当天首次组合系统，未知风险集中爆发 原因 → 未用冻结输入和候选制品预先集成验证 修法 → 集成阶段检查跨模块契约，发布用候选制品先验证再提升

误区 4

现象 → 需求改了却追不到决策和证据 原因 → 工具之间无双向链接，变更只记一头 修法 → 需求、变更、决策与证据建立双向链接，缺一端即断链

小结

本章方法是用可读接口表达责任，用边界测试证明失败语义，再以可重建环境和制品证据完成闭环。

• 生命周期模型选择由不确定性、法规和交付成本决定，不是仪式
• 拆成可验收增量，完成定义须含文档、迁移与运行证据
• 集成阶段检查跨模块契约，发布用冻结输入与候选制品
• 需求、变更、决策与证据须双向链接，工具可替代
• 迭代结束关闭未完成项，复盘关注系统条件而非个人归罪

名词解释