《人月神话》读书笔记(十二)——未雨绸缪，为变更而计划，程序维护的哲学

1、对于大多数项目，第一个开发的系统并不合用。可能太慢、太大，而且难以使用，或者三者兼而有之。要解决所有的问题，除了重新开始以外，没有其他的办法，即开发一个更灵巧或者更好的系统。系统的丢弃和重新设计可以一步完成，也可以一块块地实现。所有大型系统的经验都显示，这是必须完成的步骤；

2、一旦认识到实验性的系统必须被构建和丢弃，具有变更思想的重新设计不可避免；

3、用户的实际需要和用户感觉，会随着程序的构建，测试和使用而变化；

4、开发人员交付的是用户满意度，而不仅仅是实际的产品。一次一个有有经验的同事这么和我说，我深受启发，的确是这样，既然交付的主要是满意度，那么怎么样提高用户的满意度呢？要么提高您产品的质量来获取高的用户满意度，要么降低用户的期望！vista不好吗？市场反应不怎么样呢？主要原因就是大力的前期宣传，使用户的期望值太高了！

5、  为变化设计系统，包括细致的模块化、可扩展的函数、精确完整的模块间接口设计、完备的文档。另外，还可能会采用包括调用队列和表驱动技术。最重要的措施是使用高级语言和自文档技术，以减少变更引起的错误。采用编译时的操作来整合标准说明，在很大程度上帮助了变化的调整。

6、变更的阶段化是一种必要的技术。每个产品都应该有数字版本号，每个版本都应该有自己的日程表和冻结日期。在此之后的变更属于下一个版本的范畴。

7、为变更计划组织架构和团队，为变更组建团队要比为变更进行设计更加困难。

8、只要管理人员和技术人员的天赋允许，老板必须对他们的能力培养，给于充分的关注，使管理人员和技术人员具有互换性。

9、程序设计人员，不愿意书写文档，不仅仅因为惰性，更多的是来源于设计的踌躇——要为自己尝试性的设计决策作辩解。

10、程序维护中的一个基本问题是 -- 缺陷修复总会以(20%--50%)的机率引入新的bug。整个过程是前进两步，后退一步。作为引入新bug的一个后果，程序每条语句的维护需要的系统测试比其他编程要多，成本非常高。缺陷不能被彻底修复的原因：

首先，看上去很轻微的错误，似乎仅仅是局部操作上的失败，实际上却是系统级别的问题。其次，维护人员通常不是编写代码的开发人员。

11、对于一个广泛使用的产品，其维护成本通常是开发成本的40%或者更多；

12、维护成本与产品的使用人数有很大关系，用户越多，发现的错误也就越多；bug数随着产品的发布时间的推移，先是下降，然后是上升的；

13、每次修改一个bug，必须运行以前所有的测试用例，确保不会以更隐蔽的方式引入新的bug，这其实就是回归测试；

14、 使用能消除、至少是能指明副作用的程序设计方法，会在维护成本上有很大的回报。设计实现的人员越少、接口越少，产生的错误也就越少；

15、维护工作破坏系统的架构，增加了系统的混乱程度。随着时间的推移，系统变得越来越无序，无法再成为下一步进展的基础。这时，系统的重新设计完全是必要的。系统软件开发是减少混乱度的过程，软件维护是提高混乱度的过程，即使是最熟练的软件维护工作，也只是放缓了系统退化的进程。