开发阶段的努力是维护阶段的杠杆

软件一旦交付，就进入一个会持续到软件生命结束的使用与维护周期，维护阶段的工作往往不是原作者来做，因此接手者必须先把底层程序和文档理解清楚，否则任何修改都可能带来比它解决的问题更多的新问题——这也是”重写一个新系统”常常比”成功修改现有系统”看起来更容易的根源。正因为理解成本才是维护阶段真正的瓶颈，在开发阶段多花一点心思（比如用命名清晰的常量代替字面量、写清楚为什么这样设计而不只是做了什么），能在未来维护阶段省下不成比例的巨大代价，这也是软件工程研究大多集中在开发阶段而非维护阶段本身的原因——收益要在开发阶段的选择里预埋。发散：这是一种典型的”现在多付一点小成本，换未来少付一大笔隐性成本”的杠杆结构，与代码可读性、文档质量这类”当下看起来是额外负担”的实践之所以值得坚持，道理完全相通——它们的收益不会体现在写下它们的那一刻，而是体现在很久以后某个陌生人试图理解这段代码的那一刻。