全书总复习

为什么做一次总复习

学完一本书，最容易掉进一个坑：每章单独看都懂，合起来却说不出这书到底教了什么。总复习不是把目录再念一遍，而是把散在各章的做法拧成一条能从头走到尾的路。

想象盖一栋房子：有人负责砌墙，有人负责接水电，有人负责验收。如果只盯着自己那一摊，墙砌得再好也可能漏接水管。总复习做的事，是把每个工种的活儿摆到一张图上，看它们怎么接、在哪接、谁先谁后。

所以这一章不教新东西，只确认一件事：从写下第一行代码到把成品交出去，中间每一步是不是都能说清楚"为什么这么做、失败了怎么办、换台机器还能不能跑出同样结果"。

先做预测

先预测：一个示例在作者机器上运行成功，是否足以证明它可维护？不能。还要明确解释器与依赖、输入边界、失败路径、可观察结果和重建步骤。给出本章的第一个契约，把它放进可重复流程。

原书骨架与现代迁移

官方章节围绕可读语法、可分发系统、可追踪生命周期、测量后优化、Python化设计展开。原书出版于Python 2.5与早期敏捷工具生态，本章保留它解释"为什么"的结构；命令和安全默认按当前Python、标准库与PyPA维护文档迁移，不把EasyInstall、distutils安装命令、旧CI或旧项目平台直接当成新项目默认。

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

把全书从输入走到发布的证据链用一张图固定下来：

输入 -> 协议/API -> 包与应用 -> CI/测试/文档
     -> 性能证据 -> 优化与模式 -> 发布

输入          起点 —— 明确边界与失败路径
协议/API      契约 —— 调用者据此判断结果
包与应用      可分发系统 —— 可安装可复现
CI/测试/文档  可追踪生命周期 —— 每步留证据
性能证据      测量后优化 —— 基线与剖析先行
优化与模式    Python化设计 —— 协议组合优先
发布          闭环 —— 制品摘要收束验收

机制一：责任与数据流

迭代器、装饰器、上下文管理器和类机制应让资源与协议更清楚，而不是追求技巧密度。用让资源与协议一眼可见的可读语法表达责任，包元数据、模块边界、可重建环境和发布制品把脚本提升为带依赖锁定的可分发系统。先写出公共行为和失败类型，再选择语法或工具。这样即使实现从原书工具迁到当前生态，调用者仍能依据相同契约判断结果。

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

三条命令分别产出测试、文档和制品三类证据，缺一不可：

python -m unittest discover -s tests
python -m doctest docs/examples.txt
python -m build

python -m unittest  测试证据 —— 行为是否正确
python -m doctest   文档证据 —— 示例是否可运行
python -m build     制品证据 —— 可安装可分发包

机制二：失败与边界

版本、任务、CI、文档和测试把需求到发布证据串成可重放的可追踪生命周期。靠测量后优化让用户目标、基线和回归测试先于数据结构、并发与缓存方案。边界实验至少包含正常、空输入、上限附近、依赖失败和重复执行。涉及网络、并发或外部制品时，再加入超时、取消、部分完成与摘要校验。

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

用一道发布函数把三道证据门固化下来，全过才放行：

def release(evidence):
    assert evidence.tests_passed
    assert evidence.docs_built
    assert evidence.artifact_sha256
    return evidence.artifact

tests_passed      测试通过 —— 行为正确
docs_built        文档构建 —— 示例可运行
artifact_sha256   制品摘要 —— 可校验可回溯
return artifact  全部满足才放行

机制三：证据闭环

负责收束验收。以Python化设计让协议、组合和函数成为一等选择，只有扩展轴确实稳定时才引入更重的模式。保存解释器、依赖锁定、输入、命令、退出状态、关键输出和制品摘要，才能让另一台干净机器重放同一结论。

实战验收清单

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

迁移决策题

设想团队正在维护一个已经运行多年的Python服务：它仍依赖本章对应的历史工具，但业务不能停机。先不要直接重写。第一步列出可读语法承担的真实输入和输出，再用可分发系统识别构建或运行时依赖；第二步把可追踪生命周期放进隔离实验，证明当前行为与失败类型；第三步用测量后优化设计兼容层，让旧入口和新入口在同一组契约测试下运行；最后以Python化设计保存制品摘要、性能或行为差异与回滚条件。只有新路径在正常、边界和故障输入上都达到既定条件，才逐步切换流量或调用者。这样迁移的是可验证契约，而不是把一个旧命令盲目替换为一个新命令。

常见误区

误区 1

现象 → 看到原书用 EasyInstall、distutils 等旧工具，直接全部推倒重写 原因 → 把"工具过时"当成"做法过时"，丢掉了声明式配置、可回滚发布等仍成立的不变量 修法 → 先提取不变量，再用维护中的接口重写；迁移的是可验证契约，不是命令名

误区 2

现象 → 把 easy_install 换成 pip 后，部署依然依赖某个隐藏的本地环境 原因 → 只替换了命令，却保留了隐式环境与不可追踪副作用，换皮没换骨 修法 → 锁定依赖、隔离环境、记录解释器与来源，让另一台干净机器能重放同一结论

误区 3

现象 → 示例在自己机器上跑通，就认为它可维护 原因 → 没有记录解释器实现、版本、依赖来源与重建步骤，换台机器就跑不出来 修法 → 至少保存解释器、依赖锁定、输入、命令、退出状态与制品摘要，做到可重放

误区 4

现象 → 没测就凭感觉把 list 换成 set、把串行改成并行 原因 → 跳过基线与剖析，建结构、启动或序列化成本可能超过节省 修法 → 先有基线和剖析数据再动手，换完用边界输入与重复执行验证收益为正

本章回顾

本章逐项覆盖可读语法、可分发系统、可追踪生命周期、测量后优化、Python化设计。方法是用可读接口表达责任，用边界测试证明失败语义，再以可重建环境和制品证据完成闭环。

小结

• 语法让资源与协议更清楚，而非追求技巧密度
• 包元数据与模块边界把脚本提升为可安装系统
• 版本、任务、CI、文档与测试串成可重放链
• 用户目标与基线先于数据结构、并发与缓存方案
• 协议与组合优先，扩展轴稳定时才引入重模式

练习与验收

名词解释