外观
02.外科手术队伍、贵族专制、民主政治和系统设计
第3章 外科手术队伍
如何在有意义的安排内创建大型的系统？
Part 1 问题
- 研究数据：优秀的程序员和较差的程序员之间在生产率上平均为10：1，数据显示，经验和实际的表现没有相互联系。
- 对于效率和概念的完整性来说，最好有少数干练的人员来设计和研发，而对于大型系统，则需要大量的人手，以使产品能在时间上满足要求。如何调和这两方面的矛盾呢？
Part 2 Mills 的建议
Harlan Mills的提议提供了一个崭新的、创造性的解决方案。Mills 面建议大型项目的每一个部分由一个团队解决，但是该队伍以类似外科手术的方式组建，而并非一拥而上。也就是说，同每个成员截取问题某个部分的做法相反，由一个人来完成问题的分解，其他人给予他所需要的支持，以提高效率和生产力。
使用医生作，如果考虑所有可能想到的工作，这样的队伍应该如何运作?
外科医生。Mils称之为首席程序员。他亲自定义功能和性能技术说明书，设计程序，编制源代码，测试以及书写技术文档。他使用例如PL/I 的结构化编程语言，拥有对计算机系统的访问能力；该计算机系统不仅能够进行测试，还能够存储程序的各种版本，以允许简单的文件更新，并对其文档提供文本编辑能力。首席程序员需要极高的天分、丰富的经验和应用数学、业务数据处理或其他方面的大量系统知识和应用知识。
副手。他是外科医生的后备，能完成任何一部分工作，但是相对具有的经验较少。他的主要作用是作为设计的思考者、讨论者和评估人员。外科医生试图和他沟通设计，但不受到他建议的限制。副手经常在与其他团队讨论有关功能和接口问题时代表自己的小组。他需要详细了解所有的代码，研究设计策略的备选方案。显然，他充当外科医生的保险机制。他甚至可能编制代码，但对代码的任何部分，不承担具体的开发职责。
管理员。他是外科医生的老板，必须在人员、薪酬、办公空间等方面具有决定权，但他绝对不能在这些事务上浪费任何时间。因而，他需要一个控制财务、人员、工作地点和办公设备的专业管理人员，该管理员充当与组织中其他管理机构的接口。Baker建议， 仅在项目具有法律、合同、报表和财务方面的需求时，管理员才具有全职责任。否则，一个管理员可以为两个团队服务。
编辑。外科医生负责文档的生成——出于最大透明度的考虑，他必须创建各种文档，无论是对内部描述还是外部描述。而编辑根据外科医生的草稿或者口述，进行分析和重新组织，提供各种参考信息和书目，对多个版本进行维护，并监督文档生成的机制。
两个文秘。管理员和编辑每个人需要一个文秘。管理员的文秘负责非产品文件和使项目协作一致。
程序职员。他负责维护编程产品库中所有团队的技术记录。该职员接受文秘性质的培训，承担机器码文件和可读文件的相关管理责任。
计算机输入汇集到这个职员处。如果需要，他会对它们进行记录或者标识。输出列表会提交给程序职员，由他进行归档和编制索引。另外，他负责将任何模型的最新运行情况记录在状态日志中，而所有以前的结果则按时间顺序进行归档保存。
Mils概念的真正关键是“从个人艺术到公共实践”的编程观念转换。它向所有的团队成员展现了所有计算机的运行和产物，并将所有的程序和数据看做是团队的所有物，而非私人财产。
程序职员的专业化分工，使程序员从文书等杂事中解放出来，同时还可以对那些经常被忽视的杂事进行系统整理，确保了它们的质量，并强化了团队最有价值的财富—工作产品。上述概念显然考虑的是批处理程序。当使用交互式终端，特别是在没有纸张输出的情况下，程序职员的职责并未消失，只是有所更改。他会记录小组程序和私有工作拷见之间的更新，依然控制所有程序的运行，并使用自己的交互式工具来控制产品逐步增长的完整性和有效性。
- 工具维护人员。现在已经有很多文件编辑、文本编辑和交互式调试等工具，因此团队很少再需要自己的机器和机器操作人员。但是这些工具使用起来必须毫无疑问地具备令人满意的反应和可靠性。外科医生则是对这些工具的服务是否充分可用的唯一评判人员。他需要一个工具维护人员，保证所有基本服务的可靠性，以及承担团队成员所需要的特殊工具(特别是交互式计算机服务)的构建、维护和升级责任。即使已经拥有非常卓越的、可靠的集中式服务，每个团队仍然要有自己的工具维护人员。因为他的工作是检查他的外科医生所需要的工具，而不是其他团队的需要。工具维护人员常常要开发一些实用程序，编制具有目录的函数库以及宏库。
- 测试人员。外科医生需要大量合适的测试用例，用来对他所编写的工作片段，以及对整个工作进行测试。因此，测试人员既是为他的各个功能设计系统测试用例的对手，也是为他的日常调试设计测试数据的助手。他还负责计划测试的步骤和为单元测试搭建测试平台。
- 语言专家。随着Algol语言的出现， 人们开始认识到， 在大多数计算机项目中，总有一两个乐于掌握复杂编程语言的人。这些专家是非常有帮助的，大家会向他咨询。这些天才不同于外科医生，外科医生主要是系统设计者以及考虑系统的整体表现。而语言专家则寻找一种简洁、有效的使用语言的方法来解决复杂、晦涩或者棘手的问题。他通常需要对技术进行一些研究(23天)。通常一个语言专家可以为23个外科医生服务。
Part 3 如何运作
文中定义的开发团队在很多方面满足了迫切性的需要。10个人，其中7个专业人士在解决问题，而系统是一个人或者最多两个人思考的产物，因此其在客观上达到了概念的一致性。
- 首先，传统的队伍将工作进行划分，每人负责一部分工作的设计和实现。在外科手术团队中，外科医生和副手都了解所有的设计和全部的代码。这节省了空间分配、磁盘访问等的劳动量，同时也确保了工作概念上的完整性。
- 第二，在传统的队伍中大家是平等的，出现观点的差异时，不可避免地需要讨论和进行相互的妥协和让步。由于工作和资源的分解，不同的意见会造成策略和接口上的不一致，例如谁的空间会被用做缓冲区，而事实上最终它们必须整合在一起。而在外科手术团队中，不存在利益的差别，观点的不一致之处可以由外科医生单方面来统一。这两种团队组建上的差异——对问题不进行分解和上下级的关系使外科手术队伍可以达到客观的一致性。
- 另外，团队中剩余人员职能的专业化分工是高效的关键，它使成员之间采用非常简单的交流模式成为可能，如下图所示。
Part 4 团队的扩建
- 扩建过程的成功依赖于这样一个事实，即每个部分的概念完整性得到了彻底的提高 --- 决定设计的人员是原来的1/7或更少。（所以，可以让200人去解决问题，而仅仅需要协调20个人，即那些“外科医生”的思路。)
- 对于协调的问题，还是需要使用分解的技术，可以认为整个系统必须具备概念上的完整性，要有一个系统结构师从上至下地进行所有的设计。要使工作易于管理，必须清晰地划分体系结构设计和实现之间的界线，系统结构师必须一丝不苟地专注干体系结构。
- 总的说来，上述的角色分工和技术是可行的，在实际工作中，具有非常高的效率。
作者总结
3.1 同样有两年经验而且在受到同样的培训的情况下， 优秀的专业程序员的工作效率是较差程序员的十倍。（Sackman、 Erikson 和 Grand）
3.2 Sackman、 Erikson 和 Grand 的数据显示经验和实际表现之间没有相互联系。我怀疑这种现象是否普遍成立。
3.3 小型、精干队伍是最好的——尽可能的少。
3.4 两个人的团队，其中一个项目经理，常常是最佳的人员使用方法。 [留意一下上帝对婚姻的设计。]
3.5 对于真正意义上的大型系统，小型精干的队伍太慢了。
3.6 实际上，绝大多数大型编程系统的经验显示出，一拥而上的开发方法是高成本、速度缓慢、不充分的，开发出的产品无法进行概念上的集成。
3.7 一位首席程序员、类似于外科手术队伍的团队架构提供了一种方法——既能获得由少数头脑产生的产品完整性，又能得到多位协助人员的总体生产率， 还彻底地减少了沟通的工作量。
第4章 贵族专制、民主政治和系统设计
Part 1 概念的完整性
对于计算机系统而言，尽管它们通常没有花费几个世纪的时间来构建，但绝大多数系统体现出的概念差异和不一致性（是巨大的）远远超过欧洲的大教堂。这通常并不是因为它由不同时代的设计师们开发，而是由于设计被分成了由若干人完成的若干任务。
在系统设计中，概念完整性应该是最重要的考虑因素。也就是说，为了反映一系列连贯的设计思路，宁可省略一些不规则的特性和改进，也不提倡独立和无法整合的系统，哪怕它们其实包含着许多很好的设计。
- 如何获得概念的完整性？
- 这样的观点是否要有一位杰出的精英，或者说是结构设计师的贵族专制，和一群创造性天赋和构思被压制的平民编程实现人员？
- 如何避免结构设计师制订出无法实现，或者代价高昂的技术规格说明，使大家陷入困境？
- 如何才能与实现人员就技术说明的琐碎细节充分沟通，以确保设计被正确地理解，并精确地整合到产品中？
Part 2 获得概念的完整性
① 当这些功能说明节约下来的时间，比花费在学习、记忆和搜索手册上的时间要多时，易用性才会提高。
② 易用性，功能与概念的复杂程度的比值才是系统设计的最终测试标准。
③ 对于给定级别的功能，能用最简洁和直接的方式来指明事情的系统是最好的。
④ 简洁和直白来自概念的完整性。每个部分必须反映相同的原理需求的一致平衡。在语法上，每个部分应使用相同的技巧；在语义上，应具有同样的相似性。因此，易用性实际上需要设计的一致性和概念上的完整性。
Part 3 贵族专制统治和民主政治
① 当概念的完整性要求设计必须由一个人，或者少数互有默契的人员来实现。
② 如果需要多人来开发，两种方法解决这个矛盾：
- 仔细地对设计方法和具体实现进行分工。
- 前一章介绍的组建编程开发团队的方法。
③ 对于大型项目，将设计方法、体系结构方面的工作与具体实现相分离是获得概念完整性的强有力方法。
④ 需求结构：完整和详细的用户接口说明。
⑤ 系统结构师：运用专业技术知识来支持用户的真正利益。
Part 4 在等待时，实现人员应该做什么
① 当建议由小型体系结构团队来编写计算机或编程系统的所有外部技术说明时，编程人员提出了三个反对意见：
- 该说明中的功能过于繁多，而对实际情况中的成本考虑比较少；
- 结构师获得了所有创造发明的快乐，剥夺了实现人员的创造力；
- 当体系结构的队伍缓慢工作时，很多实现人员空闲地坐着等待。
② 第一问题确实是危险的，下一章介绍。
③ 第二个问题，实现同样是一项高级的创造性活动。创造性的活动会因为规范化而得到增强，整个产品也一样。
③ 第三个问题，技术说明和开发实现能有多少重叠呢？
整个创造性活动包括了三个独立的阶段：体系结构、设计实现、物理实现。
（1）在计算机的设计中，一旦设计实现人员有了对手册的模糊设想，对技术有了相对清晰的构思以及拥有了适当的成本和目标时，工作就可以开始了。他可以开始设计数据流、控制序列、进行总体概念包装等。同时，还需要设计所需的工具以及进行相应的调整，特别是记录存档系统和设计自动化系统。
（2）在物理实现的阶段，对于电路、板卡、线缆、机箱、电源和内存，我们必须分别设计、细化和编制文档。这项工作与体系结构及设计实现并行进行。
（3）在编程系统的设计中，这个原理同样适用。在外部说明完成之前，设计实现人员有很多事情可以做。只要有一些最终将并入外部说明的系统功能雏形，他就可以开始了。首先，必须设定良好定义的时间和空间目标，了解产品运行的平台配置。接着，他可以开始设计模块的边界、表结构、路径和阶段分解、算法以及所有的工具。另外，其还需要花费一些时间与体系结构师进行沟通。
（4）在物理实现的阶段，也有很多可以着手的工作。编程也是一项技术，如果是新型的机器，刚在库的调整、系统理以及搜索和排序算法上，有许多事情需要处理。
（5）概念的完整性的确要求系统只反映唯一的设计理念，用户所见的技术说明来自少数人的思想。实际工作被划分成体系构、设计实现和物理实现，但这并不意味着该开发模式下的系统需要更长的时间来创建。经验显示恰恰相反，整个系统将会开发得更快，所需要的测试时间将会更少。
作者总结
4.1 概念完整性是系统设计中最重要的考虑因素。
4.2 功能与理解上的复杂程度的比值才是系统设计的最终测试标准，而不仅仅是丰富的功能。 [该比值是对易用性的一种测量，由简单和复杂应用共同验证。]
4.3 为了获得概念完整性，设计必须由一个人或者具有共识的小型团队来完成。
4.4 对于非常大型的项目，将设计方法、体系结构方面的工作与具体实现相分离是获得概念完整性的强有力方法。[同样适用于小型项目。]
4.5 如果要得到系统概念上的完整性，那么必须控制这些概念。这实际上是一种无需任何歉意的贵族专制统治。
4.6 纪律、规则对行业是有益的。外部的体系结构规定实际上是增强，而不是限制实现小组的创造性。
4.7 概念上统一的系统能更快地开发和测试。
4.8 体系结构（architecture）、设计实现（implementation）、物理实现（realization）的许多工作可以并发进行。 [软件和硬件设计同样可以并行。]