[人月神话]读书笔记6--永恒的变化&&开发工具效用

未雨绸缪（Plan to Throw One Away）

不变只是愿望， 变化才是永恒。普遍的做法是，选择一种方法，试试看：如果失败了，没关系，再试试别的。不管怎么样，重要的是先去尝试。

□试验性工厂和增大规模
对于大多数项目，第一个开发的系统并不合用。它可能太慢、太大，而且难以使用，或者三者兼而有之。要解决所有的问题，除了重新开始以外，没有其他的办法。
系统的丢弃和重新设计可以一步完成，也可以一块块地实现。所有大型系统的经验都显示，这是必须完成的步骤。
“是否预先计划抛弃原型的开发，或者是否将该原型发布给用户？”从这个角度看待问题，答案更加清晰。
将原型发布给用户，可以获得时间，但是它的代价高昂——对于用户，使用极度痛苦；
对于重新开发的人员，分散了精力；对于产品，影响了声誉，即使最好的再设计也难以挽回名声。

为舍弃而计划，无论如何，你一定要这样做。

□唯一不变的就是变化本身
一旦认识到实验性的系统必须被构建和丢弃，具有变更思想的重新设计不可避免，从而直面整个变化现象是非常有用的。
变化是与生俱来的，不是不合时宜和令人生厌的异常情况。
开发人员交付的是用户满意程度，而不仅仅是实际的产品。用户的实际需要和用户感觉会随着程序的构建、测试和使用而变化。
我从不建议顾客目标和需求的所有变更必须能够，或者应该整合到设计中。项目开始时建立的基准，肯定会随着开发的进行越来越高，甚至开发不出任何产品。
软件产品易于掌握的特性和不可见性，导致它的构建人员面临永恒的需求变更。
变化是与生俱来的，不是不合时宜和令人生厌的异常情况。
目标上的一些变化无可避免，事先为它们做准备总比假设它们不会出现要好得多。

□为变更计划系统
为变更计划系统讨论得比实践还要多得多。他们包括细致的模块化，可扩展的函数，精确完整的模块间接口设计，完备的文档。还可能会采用包括调用队列和表驱动的一些技术。
最重要的措施是使用高级语言和自文档技术，以减少变更引起的错误。
变更的阶段化是一种必要的技术。每个产品都应该有数字版本号，每个版本都应该有自己的日程表和冻结日期，在此之后的变更属于下一个版本的范畴。

□为变更计划组织架构
把所有计划、里程碑、日程安排都当作是尝试性的，以方便进行变化。这似乎有些走极端——现在软件编程小组失败的主要原因是管理控制得太少，而不是太多。
不愿意为设计书写文档的原因，不仅仅是由于惰性或者时间压力。相反设计人员通常不愿意提交尝试性的设计决策，在为他们进行辩解。
为变更组建团队比为变更进行设计更加困难。每个人被分派的工作必须是多样的、富有拓展性的工作，从技术角度而言，整个团队可以灵活地安排。在大型的项目中，项目经理需要有两个和三个顶级程序员作为技术轻骑兵，当工作繁忙最密集的时候，他们能急驰飞奔，解决各种问题。
当系统发生变化时，管理结构也需要进行调整。使管理人员和技术人才具有互换性。

図11.1
从技术线向管理同级调动时，不能伴随着待遇的提升，而且应该以“调动”，而不是“晋升”的名义。相反的调整则应该伴随着待遇的提高，对于传统意识进行补偿是必要的。
管理人员需要参与技术课程，高级技术人才需要进行管理培训。
只要能力允许，高层人员必须时刻做好技术和情感上的准备，以管理团队或者亲自参与开发工作。

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

□前进两步，后退一步
在程序发布给顾客使用之后，它不会停止变化。发布后的变更被称为“程序维护”
软件维护它主要包含对设计缺陷的修复。和硬件维护相比，这些软件变更包含了更多的新增功能，它通常是用户能察觉的。
对于一个广泛使用的程序，其维护总成本通常是开发成本的40％或更多。令人吃惊的是，该成本受用户数目的严重影响。用户越多，所发现的错误也越多。
缺陷修复总会以（20－50）%的机率引入新的bug。所以整个过程是前进两步，后退一步。
看上去很轻微的错误，似乎仅仅是局部操作上的失败，实际上却是系统级别的问题，通常这不是很明显。
作为引入新bug的一个后果，程序每条语句的维护需要的系统测试比其他编程要多。理论上在每次修复之后，必须重新运行先前所有的测试用例，从而确保系统不会以更隐蔽的方式被破坏。回归测试必须接近上述理想状况，所以它的成本非常高。
设计实现人员越少，接口越少，产生的错误也就越少。

□前进一步，后退一步
模块数量随版本号的增加呈线性增长，但是受到影响的模块以版本号指数的级别增长。所有修改都倾向于破坏系统的架构，增加了系统的混乱程度。随着时间的推移，系统变得越来越无序，修复工作迟早会失去根基。每一步前进都伴随着一步后退。尽管理论上系统一直可用，但实际上，整个系统已经面目全非，无法再成为下一步进展的基础。
而且机器在变化，配置在变化，用户的需求在变化，所以现实系统不可能永远可用。崭新的基于原有系统的重新设计是完全必要的。
系统软件开发是减少混乱度（减少熵）的过程，所以它本身是处于亚稳态的。软件维护是提高混乱度（增加熵）的过程，即使是最熟练的软件维护工作，也只是放缓了系统退化到非稳态的进程。

干将莫邪（Sharp Tools）

项目的关键问题是沟通，个性化的工具妨碍——而不是促进沟通。其次，当机器和语言发生变化时，技术也会随之变化，所有工具的生命周期是很短的。毫无疑问，开发和维护公共的通用编程工具的效率更高。

为每个团队配备一个工具管理人员。 
工具管理人员:这个角色管理所有通用工具，能指导他的客户－老板使用工具。
 同时，他还能编制老板需要的专业工具。建议为每个团队配备一名工具管理人员。
项目经理应该制订一套策略，并为通用工具的开发分配资源。与此同时，他还必须意识到专业工具的需求，对这类工具不能吝啬人力和物力。

□计算机设施
需要硬件和使用安排策略，需要操作系统，提供服务的方式必须明了，需要语言，语言的使用方针必须明确。
项目经理必须考虑，计划，组织的工具到底有哪些：操作系统，实用程序，调试辅助程序，测试用例生成工具和处理文档的字处理系统。

□目标机器
机器支持可以有效地划分成目标机器和辅助机器。
目标机器的类型有哪些？
目标机器系统会需要若干操作员和一两个系统编程人员，以保证机器上的标准支持是即时更新和实时可用的。
计划安排。
当目标机器刚刚被研制，或者当它的第一个操作系统被开发时，机器时间是非常匮乏的，时间的调度安排成了主要问题。目标机器时间需求具有特别的增长曲线。
应该要把机器时间分配成连续的时间块。尽管机器的利用程度可能会有些降低，但是生产率却提高了。因为持续的精力集中能减少思考时间。在这样的冲刺之后，提出下一个时间块要求之前，小组通常需要一到两天的时间来从事书面文档工作。

目标机器6小时中连续10次操作的生产率，比间隔3小时的10次操作要高许多。因为持续的经历集中能减少思考时间。在这样的冲刺之后，提出下一个时间块要求之前，小组通常需要一到两天的时间来从事书面文档工作。并且，通常3人左右的小组能卓有成效地安排和共享时间块。在调试新操作系统时，这似乎是一种使用目标机器的最好方法。

□辅助机器和数据服务
1.仿真装置
在生产出新机器之前，就有辅助的调试平台可供使用。可靠并不等于精确。在某些方面，仿真机器肯定无法精确地达到与新型机器一致的实现。但是至少在一段时间内，它的实现是稳定的，新硬件就不会。
不确定性是所有情况中最糟糕的，因为它剥夺了开发人员查找BUG的动力--可能根本就没有问题。所以，一套运行在稳定平台上的可靠仿真装置，提供了远大于我们所期望的功用。

2.编译器和汇编平台
高级语言的编程开发中，在目标机器上开始全面测试目标代码之前，编译器可以在辅助机器上完成很多目标代码的调试和测试工作。这为直接运行提供了支持，而不仅仅是稳定机器上的仿真结果。

3.程序库和管理
一个非常成功的重要辅助机器应用是维护程序库。

4.编程工具
如果一开始就任命了项目的工具操作和维护人员，那么这些工作可以一次完成，并且随时处在待命状态。
5.文档系统
在所有的工具中，最能节省劳动力的，可能是运行在可靠平台上的、计算机化的文本编辑系统。
6.性能仿真装置
性能仿真器、逻辑仿真装置和产品。尽可能早地开始这项工作。

□高级语言和交互式编程
交互式编程的生产率至少是原来的两倍。使用高级语言的主要原因是生产率和调试速度。
由于远程键盘终端无法用于内存转储的调试，大多数交互式工具的有效使用需要采用高级语言来进行开发。有了高级语言，可以很容易地修改代码和选择性地打印结果。实际上，它们组成了一对强大的工具。