维护与演化
复习
- 分解、模块与接口：低耦合便于修改
- 单元测试：修改不破坏既有功能
- 版本控制：保存变更历史
TL;DR
- 软件的大部分成本，花在它上线之后的维护上
- 需求与环境会不断变化，软件必须随之演化
- 可读、低耦合、有测试，是能被维护的前提
- 好的设计，是为了让将来的修改更容易
正文
很多人以为软件开发到“上线”就结束了。实际上，上线只是它漫长生命的开始。此后它要被使用、被修改、被适应新的需求，这段过程叫维护与演化（maintenance and evolution）。
维护，才是大头
一个常被提到的观察是：软件生命周期里，大部分成本花在上线之后的维护上，而不是最初的开发。
为什么？因为软件所处的世界一直在变：
- 用户想要新功能
- 环境变了（依赖升级、平台更替）
- 发现了 bug
- 业务规则调整了
于是代码必须不断被修改。而“改得动”本身，就是一种能力。
什么样的软件“改得动”
回头看前面几章，你会发现它们其实都在为“可维护”服务：
- 模块化、低耦合：改一处，不会牵动全身
- 清晰的接口：内部可以换，外部不受影响
- 单元测试：改完能立刻验证有没有弄坏别的
- 版本控制：改坏了能回退，历史可追溯
这些实践，在开发时也许显得“多此一举”，但正是它们，让软件在几年后还有人敢改、改得动。可维护性，是设计时埋下的种子。
为变化而设计
所以，写代码时多花的那点心思——起清楚的名字、划清模块、写好测试——并不是浪费。它们是在为未来的自己和同事铺路。
这也回到最初的一句话：算法解决“怎么算对”，而软件构造解决“怎么让它长久地用下去”。 一个“能跑”的程序，和一个“能一直改下去”的软件之间，隔着这几章讲的这一切。
接下来是最后一章。我们将把需求、程序、编译器、操作系统、网络、算法和硬件全部串起来，走完从“一个问题”到“一个软件系统”的完整闭环。
思考题 1
为什么说软件的大部分成本在“维护”上？
思考题 2
模块化、测试、版本控制等实践，是怎样帮助“以后更容易修改”的？
小结
知识点
- 软件的大部分成本在上线后的维护
- 需求与环境变化迫使软件持续演化
- 可读、低耦合、有测试是易维护的前提
- 好设计是为将来的修改铺路
参考资料
- Wikipedia(zh)：软件维护：软件交付后的修改与演进
- Wikipedia(zh)：可维护性：软件被修改的容易程度
思考题答案（仅供参考）
思考题 1
因为软件上线后还要长期被使用和修改：用户要新功能、环境会变化、bug 要修、业务规则会调整。这些持续发生的改动，累积起来占用了软件生命周期中的大部分成本。
思考题 2
模块化与低耦合让改动局限在一处、不易牵连全局；清晰的接口让内部实现可替换；单元测试让改动后能立刻验证旧功能未被破坏；版本控制让改坏可回退。这些共同使软件在将来“敢改、改得动”。
协议
本作品采用知识共享署名-非商业性使用-相同方式共享 4.0 国际许可协议进行许可。
封面图
设计师 | 南国微雪