你好居住者！关于项目管理的书籍很少有《神话人月》那么重要。实际软件开发示例，观点和思想的混合，为管理复杂项目创造了生动的画面。这些文章借鉴了Brooks在IBM System / 360和OS / 360担任项目经理的五十年经验。这本书的第一版是45年前出版的，第二版是25年前出版的。新方法论不断涌现，新编程语言不断涌现，处理器数量不断增长，但本书仍在不断发展。为什么？半个世纪后，我们继续重复布鲁克斯描述的错误。书中讨论的某些主题似乎已经过时，但这只是一个表象。今天，它们背后的根本问题仍然很重要。重要的是要了解自己的过去才能理解软件开发行业正在发展的地方。因此，在45年后的今天，我们读了布鲁克斯（Brooks），虽然世界发生了许多变化，但仍有9个妇女在一个月内无法生育婴儿。
摘录。贵族，民主与系统设计
这座宏伟的教堂是杰出的艺术品。她表现出的教条中没有干燥或混乱...
这是风格的最高境界，艺术家的作品理解并吸收了其前辈的所有成功，他们完美地掌握了自己的时间技术，但使用时却没有进行不恰当的展示或技巧的荒谬展示。
毫无疑问，建筑总体规划的想法属于让·奥尔贝特（Jean d'Orbet），他的继任者至少在其基本要素上受到尊重。这是建筑物极度协调一致的原因之一。
兰斯大教堂指南
概念完整性
大多数欧洲大教堂都是逐步建造的，由不同世代的建筑商建造的部分在建筑风格上有所不同。随后的建筑商倾向于“改进”早期建筑的设计，着眼于建筑“时尚”和个人品味的变化。因此，和平的诺曼王朝*毗邻并与高耸的哥特式中殿相抵触，其结果不仅是赞美上帝的荣耀，也赞扬建造者的骄傲。
在他们的背景下，兰斯的建筑风格形成了鲜明的对比。设计的完整性和任何独特的优点都使观众兴奋。如指南中所述，这种完整性是通过八代建筑商的自我否定来实现的，为了确保整体设计的纯正性，他们每一个都牺牲了一些想法。结果不仅宣告了耶和华的荣耀，而且宣告了他有罪的人从他们的骄傲中得救的能力。
尽管大多数编程系统都不需要花费几个世纪的时间就可以完成，但是它们在概念上的不统一远不及大教堂。这通常不是由于更换设计人员而发生的，而是由于将项目划分为许多人执行的众多任务而导致的。
我坚持认为概念完整性是系统设计中最重要的考虑因素。最好是拥有一个缺少某些功能和改进但反映了一组设计思想的系统，而不是拥有一个包含许多良好但独立且不一致的思想的系统。在本章和接下来的两章中，我们将研究本主题对编程系统设计的影响：
-如何实现概念上的完整性？
-这个论点难道不是成群的普世实施者面前建筑师的精英或贵族的借口吗？
-如何避免建筑师因未执行或昂贵的规格而陷入困境？
-如何确保将体系结构规范的每个次要细节都引起实施者的注意，并正确，准确地嵌入产品中？
实现概念完整性
编程系统的目的是使计算机易于使用。为此，它提供了语言和各种支持工具，这些工具实际上是由语言功能调用和驱动的程序。但是这些工具是有代价的：编程系统的外部描述比计算机系统本身的外部描述大10–20倍。用户设置任何单个功能都容易得多，但是他们的选择范围很广，并且要记住许多其他选项和格式。
仅在功能说明中获得的时间超过吸收，记忆和搜索参考手册所浪费的时间时，才简化使用。在现代编程系统中，这种收益的确超过了成本，但是近年来，随着增加越来越复杂的功能，收益/成本比似乎有所下降。我对IBM 650易于使用的记忆感到困扰，即使根本没有汇编语言或任何其他软件也是如此。
由于易用性是目标，因此功能与概念完整性之间的关系是对系统设计的最终考验。单靠功能和简单性并不能定义好的设计。
这个论点被广泛误解了。 OS / 360操作系统被其创建者誉为有史以来设计最好的操作系统，因为它无疑是功能最强大的。功能而不是简单一直是其设计师追求卓越的标准。另一方面，由于概念的简单性和约束性，PDP-10分时系统被其创建者誉为最佳。但是，无论如何，它的功能与OS / 360甚至都不属于同一类。一旦将易用性作为标准，这些方法中的每一种都将变得不平衡，仅达到目标的一半。
但是，对于给定的功能级别，最好的系统是可以以最大的简单性和直接性指定事物的系统。单靠简单是不够的。 TRAC Mooers和Algol 68语言通过简单的基本概念的数量来实现简单性。但是，即时性不是它们的特征。表达您的意图通常需要以复杂且出乎意料的方式组合基本工具。仅研究元素及其组合的规则是不够的。还需要研究惯用用法，以吸收关于元素在现实中如何组合的整体知识。简单性和直接性来自概念的完整性。每一件作品都应体现出相同的理念和平衡行为。每个部分甚至必须在语法上使用相同的技术，在语义上使用相似的概念。因此，易用性决定了设计的统一性，概念的完整性。
贵族与民主
反过来，概念上的完整性要求该项目来自一个或多个开发人员，并且要一致行动。
日程安排的压力反过来又需要更多工人的参与。有两种方法可以解决此问题。首先是在架构和实现之间进行仔细的分工。第二种是上一章中讨论的构造编程实现指令的新方法。
将架构工作与实现分开是在大型项目中实现概念完整性的强大方法。我本人已经看到它在IBM Stretch和System / 360产品系列的计算机上获得了巨大的成功。而且我亲眼目睹了它在操作系统/ 360的开发中如何无法工作，因为它使用得不够充分。
我所说的系统体系结构是指用户界面的完整而详细的规范。对于计算机，它体现在编程参考手册中。对于编译器-在语言参考手册中。对于控制程序，请参考用于调用其功能的一种或多种语言的参考手册。对于整个系统，它是参考指南的集合，以帮助用户实现其目标。
系统架构师与建筑架构师一样，是用户代理。它的职责包括为了消费者的利益，而不是为了卖方，制造商的利益，使用专业和技术知识。
必须从实现上清楚地区分体系结构。正如Blaauw指出的那样：“架构谈论发生的事情，实现谈论实现它的方法。”举一个简单的例子，他列举了一款手表，其结构由表盘，指针和表冠组成。当孩子学习这种建筑时，他可以通过手表和教堂钟楼上的时钟轻松地分辨时间。实现及其实现描述了内部发生的情况：工作量的转移和许多机制中的每种机制对精度的控制。
例如，在System / 360中，九个模型中的每个模型都以不同的方式实现了单独的计算机体系结构。反过来，Model 30系统在不同时间的单独实现，数据流，内存和微代码则服务于四种不同的体系结构：System / 360计算机，具有224个逻辑独立子通道的多路复用通道，选择器通道和1401计算机。
相同的区别同样适用于编程系统。美国已经采用了Fortran IV标准。它是许多编译器的体系结构。在此体系结构内，可能有不同的实现方式：内存中的文本或编译器，快速或优化，句法或临时的。同样，任何汇编或作业控制语言都允许许多汇编或调度程序实现。现在，我们可以解决贵族和民主这个令人深切的情感问题。新的贵族，知识分子的精英不是为了告诉贫穷，没有头脑的实施者怎么办？这位精英不是接管了所有的创造活动，使表演者只参与其中的嵌齿轮吗？你不能得到更好的产品遵循民主理念实施整个团队的好主意，而不是将规范的制定限制在少数几个？
至于最后一个问题，这是最简单的问题。我并不是在建议只有建筑师才有好的建筑思想。新概念通常来自实施者或用户。但是，我的所有经验都使我信服，并且我试图证明这一点，即系统的概念完整性决定了它的易用性。最好不要与系统的基本概念集成的良好功能和想法。如果出现许多这样重要但不兼容的想法，则整个系统将被整体丢弃，并在具有其他基本概念的集成系统上重新开始工作。
至于贵族的指控，答案必须是“是”和“否”。是的，从某种意义上说，架构师应该很少，其产品的寿命应该比实现者的产品更长，并且架构师是他最终为用户利益所指导的力量的中心。如果系统要具有概念上的完整性，那么一个人必须带头。这是不需要道歉的贵族。
制定外部规范与设计实现一样具有创造性。这是创造力，只是另一种。具有体系结构意识的实现设计需要并允许与外部规范设计一样多的设计创造力，尽可能多的新想法以及尽可能多的技术才能。确实，产品的性价比将最取决于实施者，就像易用性最取决于架构师一样。
手工艺的许多例子使人们相信纪律可以提高工艺水平。实际上，艺术家的格言说：“形式解放了”。最糟糕的结构是那些预算太大而无法提供服务的结构。巴赫的创意活动几乎不受出版每周形式有限的颂赞曲的抑制。我敢肯定，如果限制性更强，Stretch计算机将拥有更好的体系结构。我认为，System / 360 Model 30的预算限制在各个方面都对Model 75架构有利。
同样，我发现外包架构可以增强而不是否定实施团队的创新风格。他们立即专注于没人能解决的任务，发明开始如河流般流动。在一个不受限制的实施小组中，大多数想法和讨论都进入了架构解决方案，实施期限很短。
我已经看过很多次了，RW Conway证实了这种效果，他在康奈尔大学的小组为PL / 1语言构建了PL / C编译器。他指出：“最后，我们决定在不做任何更改和改进的情况下实施该语言，因为对语言的讨论将占用我们的全部精力。”
实施者在等待时应该做什么？
犯一百万美元的错误实在令人感到羞耻，但令人难忘。我生动地记得当晚我们决定如何组织OS / 360外部规范的实际编写。我由架构经理和控制程序经理制定了计划，时间表和职责分配。
建筑经理有10个才华横溢的人。他认为，他们可以编写规范并正确执行。这将需要10个月的时间，比计划所允许的时间多了三个月。
实施控制计划的经理有150人。他认为，他们可以与建筑团队协调制定规格。它将做得很好并且很实用，并且适合时间表。另外，如果架构团队愿意这样做，那么它的150名员工将闲置10个月。
为此，架构经理回答说，如果我将责任转移给控制程序团队，那么实际上结果将在3个月后收到，而且质量会低得多。我将责任移交给了控制程序实施团队，结果如他所说。在两种情况下他都是对的。而且，由于缺乏概念上的完整性，因此系统的构建和更改成本要高得多，我估计它将调试推迟了一年。
当然，许多因素影响了这个错误的决定。但是压倒性的是时间表上的时间限制，并且呼吁将这150个实施者全部投入工作。现在，我将看到充满着致命危险的警笛声。
对于由小型架构团队实际编写计算机或编程系统的所有外部规范的建议，实现者提出了三个反对意见：
- 规格将过于丰富，无法反映实际成本。
- 建筑师将拥有所有的创作乐趣，并将放弃实施者的创造力。
- 当规格遇到建筑团队的瓶颈时，许多表演者将无所事事。
首先是真正的危险，我们将在下一章中进行探讨。另外两个是幻觉，纯粹而简单。正如我们在上面看到的，实施也是一阶创意活动。在一定的外部规格下工作的需要在一定程度上限制了设计的创造力和创造力，而该学科甚至可以增强创造力。整个项目无疑是正确的。
最后一个反对意见涉及时间安排和阶段。快速的答案是在规范完成之前不雇用实施者。在建筑中，它们以相同的原理运行。
但是，在计算机系统业务中，步伐更快，并且每个人都希望尽可能地缩短时间表。规范和开发在多大程度上可以重叠？
正如Blaau所指出的那样，整个创作工作包括三个不同的阶段：体系结构，实施和实施。事实证明，它们确实可以并行启动并同时继续。
例如，在计算机设计中，实施者只要对参考手册有相对模糊的假设，关于技术的或多或少清晰的想法以及明确定义的成本和性能目标，就可以开始使用。他可以设计数据流，控制序列，粗包装概念等。他开发或调整所需的工具，特别是会计系统，包括设计自动化系统。
同时，在实施级别上，应制定，改进和记录电路，卡，电缆，框架，电源和内存的设计。这项工作与体系结构和实现并行进行。
编程系统的设计也是如此。在外部规范最终定稿之前，实现者还有很多工作要做。随着系统功能的一些过分简化（最终将体现在外部规范中），他可以继续工作。它应该有明确定义的空间和时间目标标准。他必须知道要运行其产品的系统的配置。然后，他可以开始设计模块边界，表结构，通过和阶段故障，算法和各种工具。还应该花一些时间与架构师进行交流。
在实现级别上仍有许多工作要做。编程也有技术。如果机器是新机器，则有关子例程调用约定，主管技术，搜索和排序算法的工作有很多。
概念上的完整性要求系统反映一种哲学，并且用户可见的规范由多个人编写。但是，由于将工作真正划分为体系结构，实现和实现，因此完全不会因此而计划这样的系统组装会花费更长的时间。经验表明情况恰恰相反：整个系统融合得越来越快，并且测试时间更少。实际上，垂直的分工大大减少了广泛的水平分工，其结果是从根本上简化了沟通并提高了概念完整性。
»有关这本书的更多详细信息，请参见出版社的网站
»目录
»摘录：
为居住者提供25％的优惠券折扣-Brooks
在为该书的纸质版本付款后，会通过电子邮件发送一本电子书。