第十一章 未雨绸缪

开发人员交付的是用户满意度，而不仅仅是有形的产品。用户的实际需要和用户感觉会随着程序的构建、测试和使用而变化。

项目目标上的一些变化无可避免，事先为它们做准备总比假设它们不会出现要好很多。不但目标上的变化不可避免，而且设计策略和技术上的变化也不可避免。

对于大多数项目，第一个开发的系统并不合用。它可能太慢、太大，而且难以使用，或者三者兼而有之。要解决所有的问题，除了重新开始以外，没有其他的办法（也就是我们现在常说的重构）。

这一块我是深有体会，曾经做过一套停车服务的系统，因为是首次接触这个领域，业务都技术层面都比较新颖和复杂。因此在开发过程中，需求和系统设计都在不断地发生变化，在这种需要不断去适应新变化，又缺乏经验的情况下，我们的代码显得很臃肿，系统慢慢地也变得难以维护。后来在系统上线稳定运行一段时间之后，我果断开始组织团队对系统进行重构，剔除掉了由于经验不足而加入的很多不必要的功能，优化了很多由于时间紧急而没有去认真整理的代码。系统因此变得易于维护和简洁。正是验证了书中说到的那句“为了舍弃而计划，无论如何，你一定要这样做”。

在程序发布给顾客使用之后，并不会停止变化。发布后的变更被称为“程序维护”。

对于一个广泛使用的程序，其维护总成本通常是开发成本的40%或更多。这个成本受用户数目的影响很大。用户越多，所发现的错误也就越多。

程序维护中的一个基本问题是——缺陷修复总会以固定（20%-50%）的几率引入新的bug。看上去很微小的错误，似乎仅仅是局部操作上的失败，实际上却是系统级别的问题。修复局部问题的工作量一般都不大而且很清晰，但是，更大范围的修复工作常常会被忽视。因此，在每次修复之后，理论上必须重新运行先前所有的测试用例，从而保证系统不会以更隐蔽的方式被破坏，这就是常说的回归测试。

当然，如果软件系统的结构越简单、文档越详细、设计实现的人员越少、接口越少，产生的错误也就越少。

系统软件开发是减少混乱度的过程，所以它本身是处于亚稳态的。软件维护是提高混乱度的过程，即使是最熟练的软件维护工作，也只是放缓了系统退化到非稳态的进程。

随着时间的推移，程序维护工作也会使系统变得面目全非。理论上系统是一直可用，但是实际上，机器在变化，配置在变化，用户的需求在变化，现实中的系统是不可能永远可用的。因此崭新的、基于原有系统的重新设计是完全必要的。同样还是那句话“为了舍弃而计划，无论如何，你一定要这样做”。