《修改代码的艺术》：先获得安全感，再改变遗留系统

先用特征测试和接缝建立安全边界，再改变缺乏测试的遗留代码。

笔记状态：结构化初读｜作者：Michael Feathers

版本与阅读范围

本地中文版共 360 页，有文本层但没有目录书签。报告依据本书围绕“修改原因、反馈、接缝、打破依赖、特征测试”的问题式结构整理。

一句话结论

面对没有测试的代码，第一目标不是设计得漂亮，而是用最小改动建立可观察、可控制的反馈边界，然后再安全改变行为。

核心论点一：遗留代码的关键问题是缺少可靠反馈

Feathers 用“没有测试的代码”重新定义 legacy code，意图不是否定年龄或作者，而是指出修改时无法快速知道破坏了什么。

这个定义有意简化：生产监控、类型系统和集成测试也能提供反馈，测试覆盖同样可能虚假。但它非常有效地把情绪化标签转成行动问题——下一步如何建立保护。

核心论点二：特征测试先记录现状，不急于规定理想

当真实行为不清楚时，先运行代码、观察输出并把当前行为固定下来，包括一些暂时不能改变的怪异之处。特征测试的目标是发现系统现在做什么，为后续修改提供报警器。

论证链是：没有可信规格 → 代码本身成为事实来源 → 用测试捕获可观察事实 → 小范围改变 → 根据业务目标区分应保留和应修复的行为。必须避免把真实缺陷永久神圣化；测试名称应标出“现状保护”还是“需求规格”。

核心论点三：接缝让行为可以在不直接修改目标代码时改变

接缝是可以改变行为而无需在该处编辑代码的位置。对象、多态、链接和预处理等接缝可用于替换难控制的依赖。书中的大量技术是在受限语言和旧代码中创造测试入口。

出版社公开章节指出，现有代码通常天然不利于测试，并介绍接缝及其类型。InformIT 官方章节

当代对照与不同观点

• 现代依赖注入、模块系统、容器化测试和运行时替换降低了部分操作难度，但数据库、全局状态和静态边界仍然常见。
• Fowler 的 Strangler Fig 模式从系统边界逐步替换旧能力，适合单体无法安全内部重构时使用；它把本书的增量思想扩展到架构迁移。Strangler Fig
• “先加测试”也不是无成本。对即将删除、低风险且稳定的代码建立细粒度测试可能浪费投入；测试深度应由变更风险、可逆性和寿命决定。

实践顺序

1. 明确这次修改要改变的可观察行为。
2. 找到最小可用接缝，加入特征测试。
3. 只打破阻挡测试的依赖，不先重写整个模块。
4. 在保护下重构，再实现行为变化。
5. 用生产监控和逐步发布补足测试未知区。

最终评价

它不是优雅设计目录，而是高风险现场的急救手册。最成熟的地方在于接受现实约束：先建立一小块确定性，再扩展可安全修改的区域。