首先这章把项目的实施人员分成了两拨，一波负责顶层设计，另一波则负责具体实现，且体系结构同实现必须仔细地区分开来。如同 Blaauw 所说的，“体系结构陈述的是发生了什么，而实现描述的是如何实现。”

我主张在系统设计中，概念完整性应该是最重要的考虑因素。也就是说为了反映一系 列连贯的设计思路，宁可省略一些不规则的特性和改进，也不提倡独立和无法整合的系统， 哪怕它们其实包含着许多很好的设计

概念的完整性

编程系统（软件）的目的是使计算机更加容易使用。

对于给定级别的功能，能用最简洁和直接的方式来指明事情的系统是最好的。

因此，易用性实际上需要设计的一致性和概念上的完整性。

一言堂还是集思广意

一言蔽之，顶层设计一言堂；具体实现集思广益（确立里程碑和OKR下）。

概念的完整性要求设计必须由一个人，或者非常少数互有默契的人员来实现。而进度压力却要求很多人员来开发系统。有两种方法可以解决这种矛盾。

• 第一种是仔细地区分设计方法和具体实现。
• 第二种是前一章节中所讨论的、一种崭新的组建编程开发团队的方法。

系统的体系结构（architecture）指的是完整和详细的用户接口说明。对于计算机，它是编程手册；对于编译器，它是语言手册；对于控制程序，它是语言和函数调用手册；对于整个系统，它是用户要完成自己全部工作所需参考的手册的集合。

• 这部分工作常由PM、PD完成，但小厂基于一系列原因，很难出到详尽的用户手册，我们的解决方案是PM与外科医生和副手一起确定顶层设计，然后外科医生负责实现的顶层架构，副手负责具体实现的切割。

我当然不认为只有结构师才有好的创意。新的概念经常来
自实现者或者用户。然而，我一直试图表达，并且我所有的经验使我确信，系统的概念完整
性决定了使用的容易程度。不能与系统基本概念进行整合的良好想法和特色，最好放到一边，
不予考虑。如果出现了很多非常重要但不兼容的构想，就应该抛弃原来的设计，对不同基本
概念进行合并，在合并后的系统上重新开始。

这段话的理解是，尽可能给实现人员放权，这样可以得到更好的创意和实现，但是顶层设计师为了保持一致性仍有“一票否决权”。

具体实现

整个创造性活动包括了三个独立的阶段：体系结构（architecture）、设计实现（implementation）、物理实现（realization）。在实际情况中，它们往往可以同时开始和并发地进行。

• 问题是三个阶段要按照顺序进行，所以需要粮草先行

只要顶层设计有模糊的概念，开发人员就可以有所行动，但需要注意的是

• 首先，必须设定良好定义的时间和空间目标，了解产品运行的平台配置。 （里程碑OKR的确认）
• 接着，他可以开始设计模块的边界、表结构、算法以及所有的工具。（具体实现不要过多干预）
• 另外，还需要花费一些时间和体系结构师沟通。（多沟通）

重点还是在谋不可众上

好处

同工作的水平分割相比，垂直划分从根本上大大减少了劳动量，结果是使交流彻底地简化，概念完整性得到大幅提高。