第9章 削足适履
9.1 程序有多大？除了运行时间以外，它所占据的空间也是主要开销。
当系统设计者认为对用户而言，常驻程序内存的形式比加法器、磁盘等更加有用时，他会将硬件实现中的一部分移到内存上。相反的，其他的做法是非常不负责任的。
由于规模是软件系统产品用户成本中如此大的一个组成部分，开发人员必须设置规模的目标，控制规模，考虑减小规模的方法，就像硬件开发人员会设立元器件数量目标，控制元器件的数量，想出一些减少零件的方法。同任何开销一样，规模本身不是坏事，但不必要的规模是不可取的。
9.2 对项目经理而言，规模控制既是技术工作的一部分，也是管理工作的一部分。
他必须研究用户和他们的应用，以设置将开发系统的规模。接着，把这些系统划分成若干部分，并设定每个部分的规模目标。
首先，仅对核心程序设定规模目标是不够的，必须把所有的方面都编入预算。
在为每个单元设立核心规模的同时，我们没有同时设置访问的目标。
项目规模本身很大，缺乏管理和沟通，以至于每个团队成员认为自己是争取小红花的学生，而不是构建系统软件产品的人员。为了满足目标，每个人都在局部优化自己的程序，很少会有人停下来，考虑一下对客户的整体影响。
9.3 空间预算的多少和控制并不能使程序规模减小，为实现这一目标，它还需要一些创造性和技能。
其中的一个技巧是用功能交换尺寸：
在内存大小一定的情况下进行系统设计时，会出现另外一个基本问题。内存受限的后果是即使最小的功能模块，它的适用范围也难以得到推广。临时空间的尺寸，以及每次磁盘访问的程序数量是很关键的决策，因为性能是规模的非线性函数。
第二个技能是考虑空间——时间的折衷：
对于给定的功能，空间越多，速度越快。这一点在很大的范围内都适用。也正是这一点使空间预算成为可能。
项目经理可以做两件事来帮助他的团队取得良好的空间——时间折衷。一是确保他们在编程技能上得到培训，而不仅仅是依赖他们自己掌握的知识和先前的经验。另外一种方法是认识到编程需要技术积累，需要开发很多公共单元构件库。库中的每个组件需要有两个版本，运行速度较快和短小精炼的。
9.4 精炼、充分和快速的程序，往往是战略性突破的结果，而不仅仅技巧上的提高。这种突破常常是一种新型算法。
更普遍的是，战略上突破常来自于数据或表的重新表达。实际上，数据的表现形式是编程的根本。
第10章 提纲挈领
在一片文件的汪洋中，少数文档形成了关键的枢纽，每件项目管理的工作都围绕着它们运转。它们是经理们的主要个人工具。
10.3 软件项目的文档
做什么：目标。定义了待完成的目标、迫切需要的资源、约束和优先级。
做什么：产品技术说明。以建议书开始，以用户手册和内部文档结束。速度和空间说明是关键的部分。
时间：进度表
资金：预算
地点：工作空间分配
人员：组织图。它与接口说明是相互依存的，如果系统设计能自由地变化，则项目组织架构必须为变化做准备。
10.4 为什么要有正式的文档？
首先，书面记录决策是必要的。
第二，文档能够作为同其他人的沟通渠道。
最后，项目经理的文档可以作为数据基础和检查列表。
只有一小部分管理人员的时间——可能只有20%——用来从自己头脑外部获取信息。其他的工作是沟通：倾听、报告、讲授、规劝、讨论、鼓励。不过，对于基于数据的部分，少数关键的文档是至关重要的，它们可以满足绝大多数需要。
项目经理的任务是制订计划，并根据计划实现。但是只有书面计划是精确和可以沟通的。计划中包括了时间、地点、人物、做什么、资金。这些少量的关键文档封装了一些项目经理的工作。