试验性工厂和增大规模
开发一个更灵巧或者更好的系统。系统的丢试图和重新设计可以一步完成,也可以一块块地实现。
为舍弃而计划,无论如何,你一定要这样做。
唯一不变的就是变化本身
目标上的一些变化无可避免,事先为它们做准备总比假设它们不会出现在好得多。不但目标上的变化不可避免,而面设计策略和技术上的变化也不可避免。
为变更设计系统
细致的模块化、可扩展的函数、精确完整的模块间接口设计和完备的文档。
变更的阶段化是一种必要的技术。每个产品都应该有数字版本号,每个版本都应该有自己的日程表和冻结日期,在此之后的变更属于下一个版本的范畴。
为变更计划组织 架构
当系统发生变化时,管理结构也需要进行调整。
管理人员需要参与技术课程,高级技术人才需要进行管理培训。项目、进展和管理问题必须在高级人员整体中得到共享。
只要能力允许,高层人员必须时刻做好技术和情感上的准备,或者队亲自参与开发工作。其工作量很大,但很值得。
前进两步,后退一步
程序维护中的一个基本问题是:缺陷修复总会以固定(20%~50%)的几率引入新的bug,所以,整个过程是前进两步,后退一步。
作为引入新bug的一个后果,程序每语句的维护需要的系统测试比其它编程要多。理论上,在每次修复之后,必须重新运行先前所有的测试用例,从而确保系统不会以更隐蔽的方式被破坏。实际情况中,回归测试必须接近上述理想善,所以它的成本非常高。
前进一步,后退一步
Lehman和Belady发现模块总数量随版本号的增加呈线性增长,但是受到模块数量随版本号的增加呈指数增长。所有修改都倾向于破坏系统 的架构,增加了系统的混乱程度(熵)。