人月神话 读书笔记 02
第4章 贵族专制、民主政治和系统设计
4.1 在系统设计中，概念完整性应该是最重要的考虑因素。也就是说，为了反映一系列连贯的设计思路，宁可省略一些不规则的特性和改进，也不提倡独立和无法整合的系统，哪怕它们其实包含着许多很好的设计。
4.2 编程系统（软件）的目的是使计算机更加容易使用。
为了做到这一点，计算机装备了语言和各种工具，只有当这些功能说明节约下来的时间，比用在学习、记忆和搜索手册上的时间要少时，易用性才会得到提高。由于目标是易用性，功能与理解上复杂程度的比值才是系统设计的最终测试标准。单是功能本身或者易于使用都无法成为一个好的设计评判标准。
4.3 概念的完整性要求设计必须由一个人，或者非常少数互有默契的人员来实现。而进度压力却要求很多人员来开发系统。
有两种方法可以解决这种矛盾。第一种是仔细地区分设计方法和具体实现。第二种是前一章节中所讨论的、一种崭新的组建编程开发团队的方法。
对于非常大型的项目，将设计方法、体系结构方面的工作与具体实现相分离是获得概念完整性的强有力方法。
系统的体系结构（architecture）指的是完整和详细的用户接口说明。
对于计算机，它是编程手册；对于编译器，它是语言手册；对于控制程序，它是语言和函数调用手册；对于整个系统，它是用户要完成自己全部工作所需参考的手册的集合。体系结构同实现必须仔细地区分开来。
难道不能遵循民主的理论，从所有的员工中搜集好的创意，以得到更好的产品，而不是将技术说明工作仅限定于少数人？
就必须只能存在少数的结构师而言，答案是肯定的，他们的工作产物的生命周期比那些实现人员的产物要长，并且结构师一直处在解决用户问题，实现用户利益的核心地位。如果要得到系统概念上的完整性，那么必须控制这些概念。这实际上是一种无需任何歉意的贵族专制统治。
纪律、规则对行业是有益的。外部的体系结构规定实际上是增强，而不是限制实现小组的创造性。概念上统一的系统能更快地开发和测试。
4.4 如同Blaauw所指出的，整个创造性活动包括了三个独立的阶段：体系结构（architecture）、设计实现（implementation）、物理实现（realization）。在实际情况中，它们往往可以同时开始和并发地进行。在编程系统的开发中，这个原理同样适用。
概念的完整性的确要求系统只反映唯一的设计理念，用户所见的技术说明来自少数人的思想。实际工作被划分成体系结构、设计实现和物理实现，但这并不意味着该开发模式下的系统需要更长的时间来创建。经验显示恰恰相反，整个系统将会开发得更快，所需要的测试时间将更少。
同工作的水平分割相比，垂直划分从根本上大大减少了劳动量，结果是使交流彻底地简化，概念完整性得到大幅提高。
第5章 画蛇添足
5.1 尽早交流和持续沟通能使结构师有较好的成本意识，以及使开发人员获得对设计的信心，并且不会混淆各自的责任分工。
面对估算过高的难题，结构师有两个选择：削减设计或者建议成本更低的实现方法——挑战估算的结果。后者是固有的主观感性反应。此时，结构师是在向开发人员的做事方式提出挑战。想要成功，结构师必须：
牢记是开发人员承担创造性和发明性的实现责任，所以结构师只能建议，而不能支配；
时刻准备着为所指定的说明建议一种实现的方法，同样准备接受其他任何能达到目标的方法；
对上述的建议保持低调和平静；
准备放弃坚持所作的改进建议；
5.2 在开发第一个系统时，结构师倾向于精炼和简洁。他知道自己对正在进行的任务不够了解，所以他会谨慎仔细地工作。
第二个系统是设计师们所设计的最危险的系统。一种普遍倾向是过分地设计第二个系统，向系统添加很多修饰功能和想法，它们曾在第一个系统中被小心谨慎地推迟了。
当设计师着手第三个或第四个系统时，先前的经验会相互验证，得到此类系统通用特性的判断，而且系统之间的差异会帮助他识别出经验中不够通用的部分。
项目经理如何避免画蛇添足（second-system effect）？
他必须坚持至少拥有两个系统以上开发经验结构师的决定。
第6章 贯彻执行
6.1 手册、或者书面规格说明，是一个非常必要的工具，尽管光有文档是不够的。手册是产品的外部规格说明，它描述和规定了用户所见的每一个细节；同样的，它也是结构师主要的工作产物。规格说明的风格必须清晰、完整和准确。规格说明作者应该追求的精确程度：在仔细定义规定什么的同时，定义未规定什么。
6.2 手册的作者必须注意自己的思路和语言，达到所需要的精确程度。一种颇具吸引力的作法是对上述定义使用形式化标记方法。形式化定义是精确的，它们倾向于更加完整；差异得更加明显，可以更快地完成。但是形式化定义的缺点是不易理解。
在表达的精确和简明性上，目前所提出的形式化定义，具有了令人惊异的效果，增强了我们进行准确表达的信心。但是，它还需要记叙性文字的辅助，才能使内容易于领会和讲授。如果同时具有两种方式，则必须以一种作为标准，另一种作为辅助描述，并照此明确地进行划分。
最后，关于实际使用标准是形式化描述还是叙述性文字这一点而言，使用实现作为形式化定义特别容易引起混淆，特别是在程序化的仿真中。另外，当实现充当标准时，还必须防止对实现的任何修改。
6.3 对软件系统的体系结构师而言，存在一种更加可爱的方法来分发和强制定义。对于建立模块间接口语法，而非语义时，它特别有用。这项技术是设计被传递参数和共享存储器的声明，并要求编程实现在编译时的一些操作（PL/I的宏或#include）来包含这些声明。
6.4 我们把会议分成两个级别：周例会和年度大会。
周例会是每周半天的会议，由所有的结构师，加上硬件和软件实现人员代表和市场计划人员参与，由首席系统结构师主持。
会议中，任何人可以提出问题和修改意见，但是建议书通常是以书面形式，在会议之前分发。新问题通常会被讨论一些时间。重点是创新，而不仅仅是结论。周例会的决策会给出迅捷的结论，允许工作继续进行。
这种会议的卓有成效是由于：
数月内，相同小组——结构师、用户和实现人员——每周交流一次。因此，大家对项目相关的内容比较了解，不需要安排额外时间对人员进行培训。
上述小组十分睿智和敏锐，深刻理解所面对的问题，并且与产品密切相关。没有人是“顾问”的角色，每个人都要承担义务。
当问题出现时，在界线的内部和外部同时寻求解决方案。
正式的书面建议集中了注意力，强制了决策的制订，避免了会议草稿纪要方式的不一致。
清晰地授予首席结构师决策的权力，避免了妥协和拖延。
随着时间的推移，一些决定没有很好地贯彻，一些小事情并没有被某个参与者真正地接受，其他决定造成了未曾遇到的问题。对于这些问题，有时周例会没有重新考虑，慢慢地，很多小要求、公开问题或者不愉快会堆积起来。为解决这些堆积起来的问题，我们会举行年度大会，典型的年度大会会持续两周。
年度大会的出席人员不仅仅包括体系结构小组和编程人员、实现人员的结构代表，同时包括编程经理、市场和实现人员，由System/360的项目经理主持。
议程典型地包括大约200个条目，每个不同的声音都有机会得到表达。然后，会制订出决策。每天早晨，会议参与人员会在座位上发现更新了的手册说明，记录了前一天的各项决定。
这些“收获的节日”不仅可以解决决策上的问题，而且使决策更容易被接受。每个人都在倾听，每个人都在参与，每个人对复杂约束和决策之间的相互关系有了更透彻的理解。
6.5 在大多数计算机项目中，机器和手册之间往往会在某一天出现不一致，人们通常会忽略手册。因为与机器相比，手册更容易改动，并且成本更低。
然而，当存在多重实现时，情况就不是这样。这时，如实地遵从手册更新机器所造成的延迟和成本的消耗，比根据机器调整手册要低。
6.6 一种有用的机制是由结构师保存电话日志。
日志中，他记录了每一个问题和相应的回答。每周，对若干结构师的日志进行合并，重新整理，并发布给用户和实现人员。这种机制很不正式，但非常快捷和易于理解。
6.7 项目经理最好的朋友就是他每天要面对的敌人——独立的产品测试机构/小组。
该小组根据规格说明检查机器和程序，充当麻烦的代言人，查明每一个可能的缺陷和相互矛盾的地方。每个开发机构都需要这样一个独立的技术监督部门，来保证其公正性。
在最后的分析中，用户是独立的监督人员。产品——测试小组则是顾客的代理人，专门寻找缺陷。
第7章 为什么巴比伦塔会失败？
7.1 巴比伦塔项目的失败是因为缺乏交流，以及交流的结果——组织。他们无法相互交谈，从而无法合作。当合作无法进行时，工作陷入了停顿。
7.2 因为左手不知道右手在做什么，所以进度灾难、功能的不合理和系统缺陷纷纷出现。随着工作的进行，许多小组慢慢地修改自己程序的功能、规模和速度，他们明确或者隐含地更改了一些有效输入和输出结果用法上的约定。由于对其他人的各种假设，团队成员之间的理解开始出现偏差。
团队应该以尽可能多的方式进行相互之间的交流：非正式、常规项目会议，会上进行简要的技术陈述、共享的正式项目工作手册以及电子邮件。
7.3 项目工作手册：
是什么。项目工作手册不是独立的一篇文档，它是对项目必须产出的一系列文档进行组织的一种结构。项目所有的文档都必须是该结构的一部分。这包括目的、外部规格说明、接口说明、技术标准、内部说明和管理备忘录。
为什么。技术说明几乎是必不可少的。如果某人就硬件和软件的某部分，去查看一系列相关的用户手册。他发现的不仅仅是思路，而且还有能追溯到最早备忘录的许多文字和章节，这些备忘录对产品提出建议或者解释设计。对于技术作者而言，文章的剪裁粘贴与钢笔一样有用。使用项目手册的第二个原因是控制信息发布。控制信息发布并不是为了限制信息，而是确保信息能到达所有需要它的人的手中。
项目手册的第一步是对所有的备忘录编号，从而每个工作人员可以通过标题列表来检索是否有他所需要的信息。还有一种更好的组织方法，就是使用树状的索引结构。
处理机制。同许多其它的软件管理问题一样，随着项目规模的扩大，技术备忘录的问题以非线性趋势增长。工作手册的实时更新是非常关键的。工作手册的使用者应该将注意力集中在上次阅读后的变更，以及关于这些变更重要性的评述。
现在如何入手？在当今很多可以应用的技术中，我认为一种选择是采用可以直接访问的文件。在文件中，记录修订日期记录和标记变更标识条。每个用户可以从一个显示终端（打印机太慢了）来查阅。
7.4 团队组织的目的是减少不必要交流和合作的数量，因此良好的团队组织是解决上述交流问题的关键措施。
减少交流的方法是人力划分（division of labor）和限定职责范围（specialization of function）。当使用人力划分和职责限定时，树状管理结构所映出对详细交流的需要会相应减少。事实上，树状组织架构是作为权力和责任的结构出现。
树状编程队伍的每棵子树所必须具备的基本要素：
任务（a mission）
产品负责人（a producer）
技术主管和结构师（a technical director or architect）
进度（a schedule）
人力的划分（a division of labor）
各部分之间的接口定义（interface definitions among the parts）
产品负责人的角色是什么？
他组建团队，划分工作及制订进度表。他要求，并一直要求必要的资源。这意味着他主要的工作是与团队外部，向上和水平地沟通。他建立团队内部的沟通和报告方式。最后，他确保进度目标的实现，根据环境的变化调整资源和团队的构架。
技术主管的角色是什么？
他对设计进行构思，识别系统的子部分，指明从外部看上去的样子，勾画它的内部结构。他提供整个设计的一致性和概念完整性；他控制系统的复杂程度。当某个技术问题出现时，他提供问题的解决方案，或者根据需要调整系统设计。
存在三种可能的关系，它们都在实践中得到了成功的应用：
产品负责人和技术主管是同一个人。这种方式非常容易应用在很小型的队伍中，可能是三个或六个开发人员。在大型的项目中则不容易得到应用。原因有两个：第一，同时具有管理技能和技术技能的人很难找到。思考者很少，实干家更少，思考者－实干家太少了。第二，大型项目中，每个角色都必须全职工作，甚至还要加班。对负责人来说，很难在承担全部管理责任的同时，还能抽出时间进行技术工作。对技术主管来说，很难在保证设计的概念完整性，没有任何妥协的前提下，担任管理工作。
产品负责人作为总指挥，技术主管充当其左右手。这种方法有一些困难。很难在技术主管不参与任何管理工作的同时，建立在技术决策上的权威。显然，产品负责人必须预先声明技术主管的技术权威，在即将出现的绝大部分测试用例中，他必须支持后者的技术决定。要达到这一点，产品责任人和技术主管必须在基本的技术理论上具有相似观点；他们必须在主要的技术问题出现之前，私下讨论它们；产品责任人必须对技术主管的技术才能表现出尊重。
技术主管作为总指挥，产品负责人充当其左右手。我猜测最后一种安排对小型的团队是最好的选择，如同在第3章《外科手术队伍》一文中所述。对于真正大型项目中的一些开发队伍，我认为产品负责人作为管理者是更合适的安排。
第8章 胸有成竹
系统编程需要花费多长的时间？需要多少的工作量？如何进行估计？
编码大约只占了问题的六分之一左右，编码估计或者比率的错误可能会导致不合理的荒谬结果。仅仅通过对编码部分的估计，然后乘以任务其他部分的相对系数，是无法得出对整项工作的精确估计的。必须声明的是，构建独立小型程序的数据不适用于编程系统产品。
8.1 Charles Portman发现他的编程队伍落后进度大约1/2，每项工作花费的时间大约是估计的两倍。
日志显示事实上他的团队仅用了百分之五十的工作周，来进行实际的编程和调试，估算上的失误完全可以由该情况来解释。其余的时间包括机器的当机时间、高优先级的无关琐碎工作、会议、文字工作、公司业务、疾病、事假等等。简言之，项目估算对每个人年的技术工作时间数量做出了不现实的假设。
8.2 Joel Aron对程序员的生产率进行了研究。他根据程序员（和系统部分）之间的交互划分这些系统，得到了如下的生产率：
非常少的交互 10,000指令每人年
少量的交互 5,000
较多的交互 1,500
该人年数据未包括支持和系统测试活动，仅仅是设计和编程。
8.3 John Harr，汇报了他和其他人的经验。下图是数据最详细和最有用的。头两个任务是基本的控制程序，后两个是基本的语言翻译。生产率以经调试的指令/人年来表达。它包括了编程、构件测试和系统测试。没有包括计划、硬件机器支持、文书工作等类似活动的工作量。
生产率同样地被划分为两个类别，控制程序的生产率大约是600指令每人年，语言翻译大约是2200指令每人年。注意所有的四个程序都具有类似的规模——差异在于工作组的大小、时间的长短和模块的个数。控制程序确实更加复杂。除开这些不确定性，数据反映了实际的生产率——描述了在现在的编程技术下，大型系统开发的状况。
8.4 IBM OS/360的经验，还是证实上面那些结论。
就控制程序组的经验而言，生产率的范围大约是600～800（经过调试的指令）/人年。语言翻译小组所达到的生产率是2000～3000（经过调试的指令）/人年。这包括了小组的计划、代码构件测试、系统测试和一些支持性活动。就我的观点来说，它们同Harr的数据是可比的。
生产率会根据任务本身复杂度和困难程度表现出显著差异。在复杂程度估计这片“沼泽”上的指导原则是：编译器的复杂度是批处理程序的三倍，操作系统复杂度是编译器的三倍。
8.5 Corbato的MIT项目MAC报告表示在MULTICS系统上，平均生产率是1200行经调试的PL/I语句（大约在1和2百万指令之间）/人年。MULTICS包括了控制程序和语言翻译程序。但Corbato的数字是行/人年，不是指令！系统中的每个语句对应于手写代码的3至5个指令！
这意味着两个重要的结论：
对常用编程语句而言。生产率似乎是固定的。这个固定的生产率包括了编程中需要注释，并可能存在错误的情况；
使用适当的高级语言，编程的生产率可以提高5倍。
