第九章削足适履

该如何去节省程序所需要的存储空间。

但是相对的，现在的电脑可用的资源变多，所以其实在 Heresy 来看，并没有必要像以前一样为了一点点的记忆体使用而斤斤计较，与其想办法去省 1k、1m 的记忆体，倒不如把精力放在想办法让程式跑更快上面（不过这也取决于开发的环境、以及要开发的程式种类）。

规模控制

1. 和制定驻留空间预算一样，应该制定总体规模的预算；和制定规模预算一样，应该制定后台存储访问的预算。
2. 指明模块的大小的同时，确切定义模块的功能。
3. 每个小组倾向于为了自己的目标，只求局部上的最佳化，而不会思考呈现给客户的整体效果

空间技能

• 空间——时间折衷，开发团队就必须在程式设计的技术上受过训练，求其在面对一个新语言或新型机器的时候。
• 编程需要技术积累，需要开发很多公共单元构件。

数据的表现形式是编程的根本

• 又小、又快、又好的程式，几乎源自于策略上的突破，而非技术上的取巧。
• 更常发生策略突破是来自于重新思考数据或表结构，数据的呈现方式是程序设计的本质。

第十章提纲挈领（THE DOCUMENTARY HYPOTHESIS）

所谓的文件假说，就是：「在成堆的书面资料中，有一小部分关键性文件记录着项目管理的核心工作，而这些文件就是身为管理者最重要的工具」。而在维护这些文件的同时，就是在执行监督和预警机制的工作，也可以直接拿来当作检查列表、状态监控之用。

三种文件的需求例子：

规划计算机产品的文档

• 目标、规格说明、进度、预算、组织结构图、工作空间配置
• 预估、预测、定价，这三者会循环影响，也决定了项目的成败

规划大学科系的文档

• 目标、课程说明、学位要求、研究报告、课程与教学计划、预算、场地分配、师资与研究生助手配置

软件项目的文档

• 目标（内容）：待完成目标，迫切需要的资源，约束和优先级。
• 产品技术说明（内容）：以建议书开始，以用户手册和内部文档结束。速度和空间说明是关键部分。
• 进度（时间）
• 工作空间配置（地点）
• 组织图（人员）

任何管理任务的焦点：时间，地点，人员，项目内容，资金。

为什么要有正式文档？

• 只有真正写下来，遗漏和矛盾之处才会显露出来；也只有写出来，才能导引出更多的细节决定。
• 沟通的渠道。
• 提供管理者一个资料库和检查列表。

第十一章未雨绸缪（PLAN TO PHROW ONE AWAY）

本章的一个重点，是「把必然的第一次失败纳入正式计划之中」；

作者在本书的第十九章，则是又提出了他认为这样是错的，因为这个说法过度地简化了问题；因为这个说法隐含了一个前提，那就是软件的创作是采用传统的循序式、或「瀑布模型」的方式。

把真正的产品交付出去前，先试做一个系统，也就是所谓的 Beta 版、甚至是有限功能的原型 Alpha 版。此外，软件开发也常常会面临客户在目标和需求上的改变，要接受多少变化是很难决定的，但是定义出一个底线是必须的，而且随着项目的进行，这项限制应该要越来越严格，否则没有任何一项产品会完成。

为变更计划系统

• 采用结构化程式设计、加上模组的详细说明、使用 table-driven 的技术（将参数存在表格裡，而不写死在程式中）。
• 把改变量化，使产品具有明确的版本编号、冻结日期。

为变更计划组织架构

• 当今软件团队失败的共通原因不是因为太多管理，而是缺乏管理。
• 在大型项目中，通常要保留两到三位顶尖的程式设计师来当机动部队。
• 管理和技术人员能力许可的话，就应该保持这两种不同的脚色的职位互换。
• IBM 建立的双梯式（dualladder）的晋升架构，让管理和技术两种对应的职位在制度上位阶是平等的。

  

• 采用第三章所提的「外科手术团队」的概念。

软件维护：前进两步，后退一步

• 上一个版本的缺陷修复总会以固定（20％～50％）的几率引入新的bug。
• 软件维护的主要目的是修正错误、增加新功能、因应环境和组态的变化而调整。
• 要维护一个广为使用的软件，起码要付出开发成本 40%的代价；使用者越多，维护成本就越高。
• 维护软件最大的问题，就是因为修正错误而导致其他错误的可能性相当高（30% –50%）。因此，每修正一个错误后，都应该要把之前的测试桉例（test case）都拿来测一次，进行回归测试（regression test）。
• 用较少的人、较少的接口，错误也会比较少。

软件维护：前进一步，后退一步

• 模组的数量会随着版本编号呈线性递增，但是模组间的牵连程度却是成指数递增。
• 任何动作都有破坏原有软件结构的倾向，并且会增加系统的混乱程度；到最后会变成无法再进行修改，只能重新设计。
• 软件开发是减少混乱度的过程，本身是亚稳态的；
• 软件维护是提高混乱度的过程，只是放缓了系统退化到非稳态的过程。

第十二章干将莫邪（SHAPP TOOLS）

这章主要是在讨论工具的重要性。作者认为，项目经理必须要建立一套运作哲学，不但要配置资源已建立共用工具，也要认知到特殊化工具的需要，不吝于他的团队建立属于自己的工具。

目标机器

「目标机器」（target machine）：要执行最后结果的机器

「工具机器」（vehicle machine）：开发阶段要用的机器

• 不过以目前一般的软体开发来说，目标机器和工具机器在很多状况下，应该是同一台。
• 但是如果目标机器比较特别，有数量限制、而又有许多团队要使用的话，就需要想办法共用了。而在这种情况下，比较好的分配办法，应该是切割较长的使用时间，给每个团队各自的使用权限，这样会是比较有效率的方法。

辅助机器和数据服务

• 仿真装置：如果是新机种的话，最好还能有他的逻辑模拟器（logical simulator），在真正的机器前，当作除错用的工具。即使在新的机器已经准备好的情况下，逻辑模拟器应该也会是个相对可靠的除错工具。

在程序库的部分，应该要分为三个区块：

• 局部自由区块（playpen）：个人任意使用
• 系统整合子程式库（system integration sublibrary）：需要整合管理员同意方可变动，做为系统测试之用
• 现行版本子程式库（current version sublibrary）：除非有重大错误，不然不轻易修改。

这裡的概念，主要是「控制」（由管理者来控制异动）和「区隔」（将正式、整合、局部自由区块三者做区隔）。

高阶程式语言（high-level language）和交谈式程式编写（interactive programming），这两者都可以有效地提高生产力。而实际上，在现在的环境裡，这两种东西也都已经算是广被接受了。