第五章 画蛇添足
普遍倾向: 过分设计第二个系统，向系统添加很多修饰功能和想法， 如：OS 360。
但开发第二个系统与纯粹的功能修饰和增强明显不同，也就是说存在对某些技术进行细化、精炼的趋势。由于基本系统设想发生了变化，这些技术已经显得落后。
结构师如何避免画蛇添足——开发第二个系统所引起的后果？ 他无法跳过二次系统，但他可以有意识关注那些系统的特殊危险，运用特别的自我约束准则，来避免那些功能上的修饰；根据系统基本理念及目的变更，舍弃一些功能。
项目经理如何避免画蛇添足（second-system effect）？他必须坚持至少拥有两个系统以上开发经验结构师的决定。同时，保持对特殊诱惑的警觉，他可以不断提出正确的问题，确保原则上的概念和目标在详细设计中得到完整的体现。
第六章 贯彻执行
- 文档化的规格说明——手册
- 形式化定义
- 直接整合
- 会议和大会
- 多重实现
- 电话日志
- 产品测试
第七章 为什么巴比伦塔会失败
失败原因： 两个方面——交流，以及交流的结果——组织。
团队之间如何进行相互之间的交流沟通呢？
- 非正式途径 电话
- 会议
- 工作手册
项目工作手册
- 是什么？ 项目工作手册不是独立的一篇文档，它是对项目必须产出的一系列文档进行组织的一种结构。项目所有的文档都必须是该结构的一部分。
- 为什么？
-
- 技术说明是必不可少的。
- 控制信息发布。 确保信息能到达所有需要它的人的手中。
大型编程项目的组织架构
团队组织的目的是减少不必要交流和合作的数量，因此良好的团队组织是解决上述交流问题的关键措施。
减少交流的方法： 人力划分和限定职责范围 ——树状管理结构
每棵子树所必须具备的基本要素：
产品负责人与技术主管之间的关系：
- 产品负责人和技术主管是同一个人 很小型的队伍（三个或六个开发人员）
- 产品负责人作为总指挥，技术主管充当其左右手 前者必须支持后者的技术决定，注意体现技术主管的威信（很少被应用）
- 技术主管作为总指挥，产品负责人充当其左右手 （对小型的团队是最好的安排，而对于真正大型项目的一些开发队伍，笔者认为产品负责人作为管理者是更合适的安排。）
第九章 削足适履
规模是软件系统产品用户成本中很大的一个组成部分，开发人员必须设置规模的目标，控制规模，考虑减小规模的方法。同任何开销一样，规模本身不是坏事，但不必要的规模是不可取的。
规模控制
OS/360 给我们的道理 ：
- 和制定驻留空间预算一样，应该制定总体规模的预算；和制定规模预算一样，应该制定后台存储访问的预算。
- 在指明模块有多大的同时，确切定义模块的功能（防止程序员在规模上遇到问题就把其中的一部分扔给别人，影响系统的稳定和安全性）
- 项目规模本身很大，缺乏管理和沟通，此时系统结构师必须保持持续的警觉，确保连贯的系统完整性。同时，培养开发人员从系统整体出发、面向用户的态度是软件编程管理人员的最重要的职能。
空间技能
用功能交换尺寸
空间——时间的折衷：（项目经理）
1. 确保他们在编程技能上得到培训，而不仅仅是依赖他们自己掌握的知识和先前的经验
- 认识到编程需要技术积累，需要开发很多公告单元构件。
数据的表现形式是编程的根本。缺乏空间时，不妨从代码中挣脱出来，回顾、分析实际情况，仔细考虑程序的数据。
第十章 提纲挈领
计算机产品的文档： 目标，技术说明，进度、时间表，预算，组织机构图，工作空间的分配，报价、预测、价格
大学科系的文档：目标，课程描述，学位要求，研究报告，课程表和课程的安排，预算，教师分配，教师和研究生助手的分配
通过对比，我们可以得出，任何管理任务的关注焦点都是时间、地点、人物、做什么、资金
软件项目的文档：
- 时间：进度表
- 地点：工作空间分配
- 人物：组织图
- 做什么： 目标；产品技术说明书
- 资金：预算
为什么要有正式的文档？
- 书面记录决策是必要的
- 文档能够作为同其他人的沟通渠道
- 项目经理的文档可以作为数据基础和检查列表
第十一章 未雨绸缪
实验性的系统必须被构建和丢弃，变化是与生俱来的，具有变更思想的重新设计是不可避免的。因此，我们需要为变更而设计系统，其中最重要的措施是使用高级语言和自文档技术，以减少变更引起的错误。同时，变更的阶段化是一种必要的技术，每个产品都应该有数字版本号，每个版本都应该有自己的日程表和冻结日期，在此之后的变更属于下一个版本的范畴。除此之外，我们还需要为变更计划组织架构。
第十三章 整体部分
我们可以通过编写测试规格说明和进行自顶向下的设计，结构化编程等方式来减少bug的数量。
构建单元调试的四个步骤：本机调试，内存转储，快照和交互式调试。
进行了单元调试后，我们再对系统进行集成测试。集成测试的内容包含：使用经过调试后的构建单元，搭建充分的测试平台，控制变更，一次添加一个构件，阶段（量子）化、定期变更