《人月神话》笔记：未雨绸缪

本章谈及“软件的变更（维护）”。

开始，作者写道：“对于大多数项目，第一个开发的系统并不好用。……要解决所有的问题，除了重新开始之外，没有其他的办法——即开发一个更灵巧或者更好的系统。系统的丢弃和重新设计可以一步完成，也可以一块块地实现。所有大型系统的经验都显示，这是必须完成的步骤。而且，新的系统概念或新技术会不断出现，所以开发的系统必须被抛弃。但即使是最优秀的项目经历，也不能无所不知地在最开始解决这些问题。”

“是否预先计划抛弃原型的开发，或者是否将该原型发布给用户？”

“唯一不变的就是变化本身”（如今，很多人都非常熟悉这句话了）

一旦认识到实验性的系统必须被构建和丢弃，具有变更思想的重新设计不可避免，从而直面整个变化现象是非常有用的。第一步是接受这样的事实：变化是与生俱来的，不是不合时宜和令人生厌的异常情况。

Cosgrove很有洞察力地指出，开发人员交付的是用户满意程度，而不仅仅是实际的产品。（这句话也非常经典，对于任何产品都是如此吧！）用户的实际需要和用户感觉会随着程序的构建、测试和使用而变化。

◆为变更计划系统
如何为变化设计系统呢？它们包括细致的模块化、可扩展的函数、精确完整的模块间接口设计、完备的文档。另外，还可能会采用包括调用队列和表驱动的一些技术。

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

◆为变更计划组织架构
当系统发生变化时，管理结构也需要进行调整。这意味着，只要管理人员和技术人才的天赋允许，老板必须对他们的能力培养给予极大的关注，使管理人员和技术人才具有互换性。
管理人员需要参与技术课程，高级技术人才需要进行管理培训。
项目目标、进展、管理问题必须在高级人员整体中得到共享。

◆程序维护
在程序发布给顾客使用后，也会有变更，这个阶段的变更被称为就“程序维护”。程序维护中的一个基本问题——缺陷修复总会以20%-50%的几率引入新的bug。

作者回答了一个问题将“为什么缺陷不能更彻底地被修复？”
首先，看上去很轻微的错误，似乎仅仅是局部操作上的失败，实际上却是系统级别的问题，通常这不是很明显。修复局部问题的工作量很清晰，并且往往不大。但是，更大范围的修复工作常常会被忽视，除非软件结构很简单，或者文档书写得非常详细（这个貌似非常理想化^_^）。其次，维护人员常常不是编写代码的开发人员，而是一些初级程序员或者新手（确实如此！）。

最后，作者以一段意味深长的话结尾：
系统软件开发是减少混乱度（减少熵）的过程，所以它本身是处于亚稳态的。（大部分时候，）软件维护是提高混乱度（增加熵）的过程，即使是最熟练的软件维护人员，也只是放缓了系统退化到非稳态的过程。