人月神话（五）未雨绸缪、干将莫邪、整体部分

第11章 未雨绸缪

Part 1 实验性工厂和增大规模

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

Part 2 唯一不变的就是变化本身

一旦认识到试验性的系统必须被构建和丢弃，具有变更思想的重新设计不可避免，从而直面整个变化现象是非常有用的开发人员交付的是用户满意程度，而不仅仅是实际的产品。用户的实际需要和用户感觉会随着程序的构建、测试和使用而变化。

软件产品易于掌握的特性和不可见性，导致它的构建人员面临永恒的需求变更。

不但目标上的变化不可避免，而且设计策略和技术上的变化也不可避免。抛弃原型概念本身就是对事实的接受—随着学习的过程更改设计。

Part 3 为变更计划系统

如何为上述变化设计系统，是个非常著名的问题，在书本上被普遍讨论——可能讨论得比实践还要多得多。

① 包括细致的模块化、可扩展的函数、精确完整的模块间接口设计、完备的文档。

② 可能会采用包括调用队列和表驱动的一些技术。

③ 最重要的措施是使用高级语言和自文档技术，以减少变更引起的错误。采用编译时的操作来整合标准声明，在很大程度上帮助了变化的调整。

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

Part 4 为变更计划组织架构

当系统发生变化时，管理结构也需要进行调整。这意味着，只要管理人员和技术人才的天赋允许，老板必须对他们的能力培养给予极大的关注，使管理人员和技术人才具有互换性。

这其中的障碍是社会性的，人们必须同顽固的戒心做斗争。首先，管理人员自己常常认为高级人员太“有价值”，而舍不得让他们从事实际的编程工作；其次，管理人员拥有更高的威信。

① 管理人员需要参与技术课程，高级技术人才需要进行管理培训。项目目标、进展、 管理问题必须在高级人员整体中得到共享。

② 只要能力允许，高层人员必须时刻做好技术和情感上的准备，以管理团队或者亲自参与开发工作。

③ 组建外科手术队伍式的软件开发团队，这其结果是当高级人才编程和开发时，不会感到自降身份。

④ 上述组织架构的设计是为了最小化成员间的接口。同样的，它使系统在最大程度上易于修改。当组织构架必须变化时，为整个“外科手术队伍”重新安排不同的软件开发任务，会变得相对容易一些。这的确是一个长期有效的灵活组织构架解决方案。

Part 5 前进两步，后退一步

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

计算机系统的硬件维护包括了三项活动—替换损坏的器件、清洁和润滑、修改设计上的缺陷。（大多数情况下—但不是全部—变更修复的是实现上、 而不是结构上的一些缺陷。对于用户而言，这常常是不可见的。）

软件维护主要包含对设计缺陷的修复。和硬件维护相比，这些软件变更包含了更多的新增功能，它通常是用户能察觉的。

对于一个广泛使用的程序，其维护总成本通常是开发成本的40％或更多。令人吃惊的是，该成本受用户数目的严重影响。用户越多，所发现的错误也越多。

麻省理工学院核科学实验室的 Betty Campbell 指出特定版本的软件发布生命期中一个有趣的循环。

起初，上一个版本中被发现和修复的 bug，在新的版本中仍会出现。新版本中的新功能会产生新的 bug。

解决了这些问题之后，程序会正常运行几个月。接着，错误率会重新攀升。Campbell 认为这是因为用户的使用到达了新的熟练水平，他们开始运用新的功能。这种高强度的考验查出了新功能中很多不易察觉的问题。

 

    程序维护中的一个基本问题是—缺陷修复总会以（20－50）%的几率引入新的bug。所以整个过程是前进两步，后退一步。

为什么缺陷不能更彻底地被修复？

首先，看上去很轻微的错误，似乎仅仅是局部操作上的失败，实际上却是系统级别的问题，通常这不是很明显。修复局部问题的工作量很清晰，并且往往不大。但是，更大范围的修复工作常常会被忽视，除非软件结构很简单，或者文档书写得非常详细。其次，维护人员常常不是编写代码的开发人员，而是一些初级程序员或者新手。

作为引入新 bug 的一个后果，程序每条语句的维护需要的系统测试比其他编程要多。理论上，在每次修复之后，必须重新运行先前所有的测试用例，从而确保系统不会以更隐蔽的方式被破坏。实际情况中，回归测试必须接近上述理想状况，所以它的成本非常高。

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

Part 6 前进一步，后退一步

Lehman 和 Belady 研究了大型操作系统的一系列发布版本的历史。他们发现模块数量随版本号的增加呈线性增长，但是受到影响的模块以版本号指数的级别增长。所有修改都倾向于破坏系统的架构，增加了系统的混乱程度。用在修复原有设计上瑕疵的工作量越来越少，而早期维护活动本身的漏洞所引起修复工作越来越多。随着时间的推移，系统变得越来越无序，修复工作迟早会失去根基。每一步前进都伴随着一步后退。尽管理论上系统一直可用，但实际上，整个系统已经面目全非，无法再成为下一步进展的基础。而且，机器在变化，配置在变化，用户的需求在变化，所以现实系统不可能永远可用。崭新的、基于原有系统的重新设计是完全必要的

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

作者总结

11.1 化学工程师已经认识到无法一步将实验室工作台上的反应过程移到工厂中，需要一个实验性工厂（pilot planet）来为提高产量和在缺乏保护的环境下运作提供宝贵经验。

11.2 对于编程产品而言，这样的中间步骤是同样必要的，但是软件工程师在着手发布产品之前，却并不会常规地进行试验性系统的现场测试。[现在，这已经成为了一项普遍的实践，beta 版本。它不同于有限功能的原型，alpha 版本，后者同样是我所倡导的实践。]

11.3 对于大多数项目，第一个开发的系统并不合用。它可能太慢、太大，而且难以使用，或者三者兼而有之。

11.4 系统的丢弃和重新设计可以一步完成，也可以一块块地实现。这是个必须完成的步骤。

11.5 将开发的第一个系统——丢弃原型——发布给用户，可以获得时间，但是它的代价高昂——对于用户，使用极度痛苦；对于重新开发的人员，分散了精力；对于产品，影响了声誉，即使最好的再设计也难以挽回名声。

11.6 因此，为舍弃而计划&