用户每天都在体验昨天的决定
维护经常被描述成“产品完成以后”的工作。事实上，用户每天感受到的，正是过去许多决定积累起来的质量。一个改名后没有完成迁移的字段、一项已经过期的集成，或者只存在于某个人记忆中的恢复流程，最终都会变成可见的产品行为。 一个容易维护的系统，通常会产生直接收益：
- 内容错误能够更快修正。
- 难以解释的不一致更少。
- 故障持续时间更短，恢复更安全。
- 小型改进能够更频繁地发生。
- 不同设备和 locale 上的行为更可预测。
内部的清晰，经过时间积累后会变成外部的可靠。
五个维护表面
| 表面 | 被忽略时的样子 | 健康实践 |
|---|---|---|
| 命名 | 同一概念有多套说法 | 共享词汇和迁移路径 |
| 依赖 | 突然被迫大升级 | 定期完成小型更新 |
| 可观察性 | 只能说“好像坏了” | 记录具体事件和系统边界 |
| 删除 | 死路径永久保留 | 根据证据安全移除 |
| 恢复 | 依赖临场英雄主义 | 验证过的回滚与恢复步骤 |
维护工作分成两种节奏后，更容易持续：
- 持续照料
- 检查日志和内容完整性错误。
- 把依赖更新限制在清晰切片内。
- 移除过期开关与临时代码。
- 让说明文档靠近它解释的行为。
- 周期更新
- 重新检查架构假设。
- 在干净环境里执行备份恢复。
- 退出已经不再值得其复杂度的集成。
- 对比当前流程与产品真实使用方式。
每月一次的维护时间
- 找出一个看似很小、却意外令人害怕的修改。
- 说清不确定性属于责任、数据形状、部署还是恢复。
- 先收集一条证据，而不是立即重做整个系统。
- 用测试、删除、说明或边界减少这部分不确定性。
- 在修改仍然容易审阅时停止。 这种节奏能够防止维护变成没有边界的大扫除。目标不是让系统完美，而是阻止理解成本在看不见的地方持续增长。 一个很有用的信号，是新协作者回答基础问题所需的时间：内容从哪里来？哪些字段必填？生产环境怎样部署？哪些东西可以安全删除？如果每个答案都依赖口述历史，维护债务已经开始影响产品推进速度。
所有旧代码都是维护债务吗？
不是。仍然符合契约的稳定代码可能是资产。只有当修改成本和风险被隐藏、责任不清楚，或者实现已经与当前行为矛盾时，才真正形成债务。年龄只是很弱的信号，无法解释的耦合才更值得警惕。
质量不只是产品今天能做什么，也包括明天的版本能否被安全地做出来。