前言
- 总有吹嘘的人说：“我可以编写控制航空运输、导弹拦截、管理银行账户的系统。”对这些人，回答很简单，“我也可以，任何人都可以，但当你真的写了，你就会成功吗？”
- 如何测试？如何集成？如何开发一个可依赖的系统？这些问题需要思考。
剔除bug的设计
- 系统各个组成部分的开发者都会做出一些假设，而这些假设之间的不匹配是大多数致命且隐蔽的bug的主要来源。第4、5、6章所讨论的概念完整性，正是直面这些问题，使得bug更不容易产生。
- 详尽、艰苦的体系设计正是出于这种目的。关键的工作是产品定义，许许多多的失败完全是因为那些产品未精确定义的地方而导致的。细致的功能定义、仔细的规格说明、规范化的功能描述以及科学的实施方法，大大减少了系统中需要寻找的bug数量。
体系设计评审
- 在编写任何代码之前，规格说明必须提交给外部的评审小组，以详细的检查说明的完整性和明确性。开发人员自己无法完成这项工作，他们不会承认自己看不懂，反而乐于摸索澄清疑惑的办法。
自上而下的设计
- 最优秀的编程人员将系统开发划分为体系结构设计、设计实现和物理编码实现，每个步骤都可以使用自上而下的方法很好的实现。
- 设计是逐步精细化的过程。首先通过粗略的任务定义和大概的解决方案得到主要结果。然后对方案仔细检查，判断结果与预期之间的差距。同时将方案分解为更详细的步骤，精细化直到算法或者数据表达方式。
- 尽可能地使用级别较高的表达方式来表现概念和隐藏细节，只要有必要进行进一步细化。
自上而下的设计从几个方面避免了bug：
- 清晰的结构和表达方式更容易对需求和模块功能进行精细地描述
- 模块分割和模块独立性避免了系统级别的bug
- 细节的抑制使结构上的缺陷更加容易识别
- 设计在每个精细化步骤上都是可以测试的
有时必须回退，推翻顶层设计，重新开始。一些糟糕的系统往往就是试图挽救一个基础很差的设计，而对它添加了各种便面装饰般的补丁。自上而下的设计让我们更加容易判断什么时候应该选择抛弃。
结构化编程
将系统结构作为控制结构来考虑，而不是独立的分支语句（GO TO跳转）。这种思考方法是程序设计发展史上向前迈进的一大步。
构建单元测试
（不再具有参考性）
系统集成测试
- 使用经过调试的构件单元做集成测试，实际情况不一定满足，至少在每个部分都正常运行之后开始集成。这样比先集成后测试要节省时间。
- 开发大量辅助调试平台和测试代码是很值得的。
- 必须有人对变更和版本进行控制和文档化，团队成员应该使用开发库的各种受控拷贝来工作。
- 系统测试期间，一次只添加一个构建。
- 变更的阶段要么很大，间隔很宽；要么小且频繁。后者很容易变得不稳定。
以上就是《人月神话》第13章——整体部分的所有内容
在本章中作者强调了整体设计以及测试的重要性，自上而下的设计是保证“概念完整性”的一种具体实施方式。
书中描述开发流程是这样的：
需求描述-》体系设计-》评审-》精细化设计-》编码-》构件测试-》集成测试-》发布
实际的流程多数是这样的：
需求描述-》平面设计-》评审-》编码-》精细化设计-》编码-》集成测试-》发布
实际流程的合理性在于：
- 设计图比体系设计更加直观，更容易被人接受
- 有经验的开发者可以在编码过程中进行细化，节省开发时间
- 大部分项目达不到构建测试的条件，或是底层不支持或是功能简单
不合理的地方在于：
- 仅通过设计图隐含的问题不容易被察觉
- 平面设计师对于系统的理解可能会存在偏差
- 缺乏顶层设计容易导致项目开发过程中出现完整性方面的重大问题
我本身是一直坚持在做自上而下的体系设计的，但流程似乎并不是特别大的问题，只要关注好概念完整性，流程是灵活的。
所以，什么才是真正规范的流程？规范流程所带来的开发收益能有多大？在有合理进度安排的情况下，真正导致项目延期或者失败的原因究竟是什么？
这些问题可能得等到下一章或着读完整本书才能回答了。
