第十一章 未雨绸缪
开发人员交付的是用户满意度,而不仅仅是有形的产品。用户的实际需要和用户感觉会随着程序的构建、测试和使用而变化。
项目目标上的一些变化无可避免,事先为它们做准备总比假设它们不会出现要好很多。不但目标上的变化不可避免,而且设计策略和技术上的变化也不可避免。
对于大多数项目,第一个开发的系统并不合用。它可能太慢、太大,而且难以使用,或者三者兼而有之。要解决所有的问题,除了重新开始以外,没有其他的办法(也就是我们现在常说的重构)。
这一块我是深有体会,曾经做过一套停车服务的系统,因为是首次接触这个领域,业务都技术层面都比较新颖和复杂。因此在开发过程中,需求和系统设计都在不断地发生变化,在这种需要不断去适应新变化,又缺乏经验的情况下,我们的代码显得很臃肿,系统慢慢地也变得难以维护。后来在系统上线稳定运行一段时间之后,我果断开始组织团队对系统进行重构,剔除掉了由于经验不足而加入的很多不必要的功能,优化了很多由于时间紧急而没有去认真整理的代码。系统因此变得易于维护和简洁。正是验证了书中说到的那句“为了舍弃而计划,无论如何,你一定要这样做”。
在程序发布给顾客使用之后,并不会停止变化。发布后的变更被称为“程序维护”。
对于一个广泛使用的程序,其维护总成本通常是开发成本的40%或更多。这个成本受用户数目的影响很大。用户越多,所发现的错误也就越多。
程序维护中的一个基本问题是——缺陷修复总会以固定(20%-50%)的几率引入新的bug。看上去很微小的错误,似乎仅仅是局部操作上的失败,实际上却是系统级别的问题。修复局部问题的工作量一般都不大而且很清晰,但是,更大范围的修复工作常常会被忽视。因此,在每次修复之后,理论上必须重新运行先前所有的测试用例,从而保证系统不会以更隐蔽的方式被破坏,这就是常说的回归测试。
当然,如果软件系统的结构越简单、文档越详细、设计实现的人员越少、接口越少,产生的错误也就越少。
系统软件开发是减少混乱度的过程,所以它本身是处于亚稳态的。软件维护是提高混乱度的过程,即使是最熟练的软件维护工作,也只是放缓了系统退化到非稳态的进程。
随着时间的推移,程序维护工作也会使系统变得面目全非。理论上系统是一直可用,但是实际上,机器在变化,配置在变化,用户的需求在变化,现实中的系统是不可能永远可用的。因此崭新的、基于原有系统的重新设计是完全必要的。同样还是那句话“为了舍弃而计划,无论如何,你一定要这样做”。