第九章 削足适履
1. 系统的空间规模：规模是软件系统产品用户成本中如此大的一个组成部分，开发
人员必须设置规模的目标，控制规模，考虑减小规模的方法。同任何开销一样，规模
本身不是坏事，但不必要的规模是不可取的。
2. 对项目经理而言，规模控制既是技术工作的一部分，也是管理工作的一部分。必
须研究用户和他们的应用，以设置将开发系统的规模。接着，把这些系统划分成若干
部分，并设定每个部分的规模目标。由于规模--速度权衡方案的结果在很大的范围内
变化，规模目标的设置是一件颇具技巧的事情，需要对每个可用方案有深刻的了解。
聪明的项目经理还会给自己预留一些空间，在工作推行时分配。
仅对核心程序设定规模目标是不够的，必须把所有的方面都编入预算。
在指明模块有多大的同时，确切定义模块的功能。
培养开发人员从系统整体出发，面对用户的态度。
3. 在速度不变的情况下，更多的功能意味着需要更多的空间。其中一个技巧是用功
能交换尺寸。设计人员必须决定用户可选项目的精细程度。
4. 考虑空间--时间的折衷。对于给定的功能，空间越多，速度越快。
项目经理可以做两件事来帮助他的团队取得良好的空间--时间折衷。一是确保他们在
编程技能上得到培训，而不仅仅是依赖他们自己掌握的知识和先前的经验。特别是使
用新语言或者新机器时，培训显得尤其重要。另一种方法是认识到编程需要技术积累，
需要开发很多公共单元构件。
5. 战略上的突破常来自数据或表的重新表达--这是程序的核心所在。数据的表现形
式时编程的根本。
第十章 提纲挈领
1. 文档的跟踪维护是项目监督和预警的机制。文档本身可以作为检查
列表、状态控制，也可以作为汇报的数据基础。
2. 软件项目文档的内容：
目标。待完成的目标、迫切需要的资源、约束和优先级。
产品技术说明。
进度表。
资金预算。
工作空间分配。
人员组织。
3. 为什么要有正式的文档
首先，书面记录决策是必要的。人们能从令人迷惑的现象中得到清晰、确
定的决策。
第二，文档能作为同其他人沟通的渠道。项目经理的基本职责是使每个人
都向着相同的方向前进，所以他的工作主要是沟通，而不是做出决定。文
档能极大地减轻他的负担。
最后，文档可以作为数据基础和检查列表。通过周期性的回顾，他能清楚
项目所处的状态，以及哪些需要重点进行更改和调整。
项目经理的任务是制订计划，并根据计划实现。只有书面计划是精确和可
以沟通的。通过遵循文档开展工作，项目经理能更清晰和快速地设定自己
的方向。
第十一章 未雨绸缪
1. 对于大多数项目，第一个开发的系统并不合用。可能太慢、太大，而且难以
使用，或者三者兼而有之。要解决所有的问题，除了重新开始以外，没有其他的
办法--即开发一个更灵巧或者更好的系统。系统的丢弃和重新设计可以一步完成
，也可以一块块地实现。所有大型系统的经验都显示，这是必须完成的步骤。
-- 构建一个试验性的系统，然后抛弃它。
2. 一旦认识到实验性的系统必须被构建和丢弃，具有变更思想的重新设计不可
避免。
3. 为变化设计系统，包括细致的模块化、可扩展的函数、精确完整的模块间接
口设计、完备的文档。另外，还可能会采用包括调用队列和表驱动技术。
最重要的措施是使用高级语言和自文档技术，以减少变更引起的错误。采用编译
时的操作来整合标准说明，在很大程度上帮助了变化的调整。
变更的阶段化是一种必要的技术。每个产品都应该有数字版本号，每个版本都应
该有自己的日程表和冻结日期。在此之后的变更属于下一个版本的范畴。
4. 为变更计划组织架构和团队。
5. 程序维护中的一个基本问题是 -- 缺陷修复总会以(20%--50%)的机率引入新
的bug。整个过程是前进两步，后退一步。作为引入新bug的一个后果，程序每条
语句的维护需要的系统测试比其他编程要多，成本非常高。
缺陷不能被彻底修复的原因：
首先，看上去很轻微的错误，似乎仅仅是局部操作上的失败，实际上却是系统级
别的问题。其次，维护人员通常不是编写代码的开发人员。
5. 使用能消除、至少是能指明副作用的程序设计方法，会在维护成本上有很大
的回报。设计实现的人员越少、接口越少，产生的错误也就越少。
6. 维护工作破坏系统的架构，增加了系统的混乱程度。随着时间的推移，系统
变得越来越无序，无法再成为下一步进展的基础。这时，系统的重新设计完全是
必要的。
系统软件开发是减少混乱度的过程，软件维护是提高混乱度的过程，即使是最熟
练的软件维护工作，也只是放缓了系统退化的进程。
