人月神话-19

第3 章外科手术队伍3.1 同样有两年经验而且在受到同样的培训的情况下，优秀的专业程序员的工作效率是较差程序员的十倍。（Sackman、Erikson 和Grand）3.2 Sackman、Erikson 和Grand 的数据显示经验和实际表现之间没有相互联系。我怀疑这种现象是否普遍成立。3.3 小型、精干队伍是最好的——尽可能的少。3.4 两个人的团队，其中一个项目经理，常常是最佳的人员使用方法。[留意一下上帝对婚姻的设计。]3.5 对于真正意义上的大型系统，小型精干的队伍太慢了。3.6 实际上，绝大多数大型编程系统的经验显示出，一拥而上的开发方法是高成本、速度缓慢、不充分的，开发出的产品无法进行概念上的集成。- 136 ------------------------ Page 149-----------------------3.7 一位首席程序员、类似于外科手术队伍的团队架构提供了一种方法——既能获得由少数头脑产生的产品完整性，又能得到多位协助人员的总体生产率，还彻底地减少了沟通的工作量。第4 章贵族专制、民主政治和系统设计4.1 “概念完整性是系统设计中最重要的考虑因素”。4.2 “功能与理解上的复杂程度的比值才是系统设计的最终测试标准”，而不仅仅是丰富的功能。[该比值是对易用性的一种测量，由简单和复杂应用共同验证。]4.3 为了获得概念完整性，设计必须由一个人或者具有共识的小型团队来完成。4.4 “对于非常大型的项目，将设计方法、体系结构方面的工作与具体实现相分离是获得概念完整性的强有力方法。”[同样适用于小型项目。]4.5 “如果要得到系统概念上的完整性，那么必须控制这些概念。这实际上是一种无需任何歉意的贵族专制统治。”4.6 纪律、规则对行业是有益的。外部的体系结构规定实际上是增强，而不是限制实现小组的创造性。4.7 概念上统一的系统能更快地开发和测试。4.8 体系结构（architecture）、设计实现（implementation）、物理实现（realization）的许多工作可以并发进行。[软件和硬件设计同样可以并行。]第5 章 画蛇添足5.1 尽早交流和持续沟通能使结构师有较好的成本意识，以及使开发人员获得对设计的信心，并且不会混淆各自的责任分工。5.2 结构师如何成功地影响实现：牢记是开发人员承担创造性的实现责任；结构师只能提出建议。时刻准备着为所指定的说明建议一种实现的方法，准备接受任何其他可行的方- 137 ------------------------ Page 150-----------------------法。对上述的建议保持低调和平静。准备对所建议的改进放弃坚持。听取开发人员在体系结构上改进的建议。5.3 第二个系统是人们所设计的最危险的系统，通常的倾向是过分地进行设计。5.4 OS/360 是典型的画蛇添足（second-system effect）的例子。[Windows NT 似乎是90 年代的例子。]5.5 为功能分配一个字节和微秒的优先权值是一个很有价值的规范化方法。第6 章贯彻执行6.1 即使是大型的设计团队，设计结果也必须由一个或两个人来完成，以确保这些决定是一致的。6.2 必须明确定义体系结构中与先前定义不同的地方，重新定义的详细程度应该与原先的说明一致。6.3 出于精确性的考虑，我们需要形式化的设计定义，同样，我们需要记叙性定义来加深理解。6.4 必须采用形式化定义和记叙性定义中的一种作为标准，另一种作为辅助措施；它们都可以作为表达的标准。6.5 设计实现，包括模拟仿真，可以充当一种形式化定义的方法；这种方法有一些严重的缺点。6.6 直接整合是一种强制推行软件的结构性标准的方法。[硬件上也是如此——考虑内建在ROM 中的Mac WIMP 接口。]6.7 “如果起初至少有两种以上的实现，那么（体系结构）定义会更加整洁，会更加规范。”6.8 允许体系结构师对实现人员的询问做出电话应答解释是非常重要的，并且必须进行- 138 ------------------------ Page 151-----------------------日志记录和整理发布。[电子邮件是一种可选的介质。]6.9 “项目经理最好的朋友就是他每天要面对的敌人——独立的产品测试机构/小组。”第7 章为什么巴比伦塔会失败？7.1 巴比伦塔项目的失败是因为缺乏交流，以及交流的结果——组织。交流7.2 “因为左手不知道右手在做什么，从而进度灾难、功能的不合理和系统缺陷纷纷出现。”由于对其他人的各种假设，团队成员之间的理解开始出现偏差。7.3 团队应该以尽可能多的方式进行相互之间的交流：非正式、常规项目会议，会上进行简要的技术陈述、共享的正式项目工作手册。[以及电子邮件。]项目工作手册7.4 项目工作手册“不是独立的一篇文档，它是对项目必须产生的一系列文档进行组织的一种结构。”7.5 “项目所有的文档都必须是该（工作手册）结构的一部分。”7.6 需要尽早和仔细地设计工作手册结构。7.7 事先制订了良好结构的工作手册“可以将后来书写的文字放置在合适的章节中”，并且可以提高产品手册的质量。7.8 “每一个团队成员应该了解所有的材料（工作手册）。”[我想说的是，每个团队成员应该能够看到所有材料，网页即可满足要求。]7.9 实时更新是至关重要的。7.10 工作手册的使用者应该将注意力集中在上次阅读后的变更，以及关于这些变更重要性的评述。- 139 ------------------------ Page 152-----------------------7.11 OS/360 项目工作手册开始采用的是纸介质，后来换成了微缩胶片。7.12 今天[即使在1975 年]，共享的电子手册是能更好达到所有这些目标、更加低廉、更加简单的机制。7.13 仍然需要用变更条和修订日期[或具备同等功能的方法]来标记文字；仍然需要后进先出（LIFO）的电子化变更小结。7.14 Parnas 强烈地认为使每个人看到每件事的目标是完全错误的；各个部分应该被封装，从而没有人需要或者允许看到其他部分的内部结构，只需要了解接口。7.15 Parnas 的建议的确是灾难的处方。[Parnas让我认可了该观点，使我彻底地改变了想法。]组织架构7.16 团队组织的目标是为了减少必要的交流和协作量。7.17 为了减少交流，组织结构包括了人力划分 （division of labor）和限定职责范围（specialization of function）。7.18 传统的树状组织结构反映了权力的结构原理——不允许双重领导。7.19 组织中的交流是网状，而不是树状结构，因而所有的特殊组织机制（往往体现成组织结构图中的虚线部分）都是为了进行调整，以克服树状组织结构中交流缺乏的困难。7.20 每个子项目具有两个领导角色——产品负责人、技术主管或结构师。这两个角色的职能有着很大的区别，需要不同的技能。7.21 两种角色中的任意组合可以是非常有效的：产品负责人和技术主管是同一个人。产品负责人作为总指挥，技术主管充当其左右手。技术主管作为总指挥，产品负责人充当其左右手。- 140 ------------------------ Page 153-----------------------第8 章胸有成竹8.1 仅仅通过对编码部分的估计，然后乘以任务其他部分的相对系数，是无法得出对整项工作的精确估计的。8.2 构建独立小型程序的数据不适用于编程系统项目。8.3 程序开发呈程序规模的指数增长。8.4 一些发表的研究报告显示指数约为1.5。[Boehm 的数据并不完全一致，在1.05和1.2之间变化。1]8.5 Portman 的ICL 数据显示相对于其他活动开销，全职程序员仅将50％的时间用于编程和调试。8.6 IBM 的Aron 数据显示，生产率是系统各个部分交互的函数，在1.5K千代码行/人年至10K千代码行/人年的范围内变化。8.7 Harr 的Bell 实验室数据显示对于已完成的产品，操作系统类的生产率大约是0.6KLOC/人年，编译类工作的生产率大约为2.2KLOC/人年。8.8 Brooks 的OS/360S 数据与Harr 的数据一致：操作系统0.6～0.8KLOC/人年，编译器2～3 KLOC/人年。8.9 Corbato 的MIT 项目MULTICS 数据显示，在操作系统和编译器混合类型上的生产率是1.2KLOC/人年，但这些是PL/I 的代码行，而其他所有的数据是汇编代码行。8.10 在基本语句级别，生产率看上去是个常数。8.11 当使用适当的高级语言时，程序编制的生产率可以提高5倍。第9 章 削足适履9.1 除了运行时间以外，所占据的内存空间也是主要开销。特别是对于操作系统，它的很多程序是永久驻留在内存中。9.2 即便如此，花费在驻留程序所占据内存上的金钱仍是物有所值的，比其他任何在配置上投资的效果要好。规模本身不是坏事，但不必要的规模是不可取的。- 141 ------------------------ Page 154-----------------------9.3 软件开发人员必须设立规模目标，控制规模，发明一些减少规模的方法——就如同硬件开发人员为减少元器件所做的一样。9.4 规模预算不仅仅在占据内存方面是明确的，同时还应该指明程序对磁盘的访问次数。9.5 规模预算必须与分配的功能相关联；在指明模块大小的同时，确切定义模块的功能。9.6 在大型的团队中，各个小组倾向于不断地局部优化，以满足自己的目标，而较少考虑队用户的整体影响。这种方向性的问题是大型项目的主要危险。9.7 在整个实现的过程期间，系统结构师必须保持持续的警觉，确保连贯的系统完整性。9.8 培养开发人员从系统整体出发、面向用户的态度是软件编程管理人员最重要的职能。9.9 在早期应该制订策略，以决定用户可选项目的粗细程度，因为将它们作为整体大包能够节省内存空间。[常常还可以节约市场成本。]9.10 临时空间的尺寸，以及每次磁盘访问的程序数量是很关键的决策，因为性能是规模的非线性函数。[这个整体决策已显得过时——起初是由于虚拟内存，后来则是成本低廉的内存。现在的用户通常会购买能容纳主要应用程序所有代码的内存。]9.11 为了取得良好的空间－时间折衷，开发队伍需要得到特定与某种语言或者机型的编程技能培训，特别是在使用新语言或者新机器时。9.12 编程需要技术积累，每个项目需要自己的标准组件库。9.13 库中的每个组件需要有两个版本，运行速度较快和短小精炼的。[现在看来有些过时。]9.14 精炼、充分和快速的程序。往往是战略性突破的结果，而不仅仅技巧上的提高。9.15 这种突破常常是一种新型算法。9.16 更普遍的是，战略上突破常来自于数据或表的重新表达。数据的表现形式是编程的根本。- 142 ------------------------ Page 155-----------------------第10 章提纲挈领10.1 “前提：在一片文件的汪洋中，少数文档形成了关键的枢纽，每个项目管理的工作都围绕着它们运转。它们是经理们的主要个人工具。”10.2 对于计算机硬件开发项目，关键文档是目标、手册、进度、预算、组织机构图、空间分配、以及机器本身的报价、预测和价格。10.3 对于大学科系，关键文档类似：目标、课程描述、学位要求、研究报告、课程表和课程的安排、预算、教室分配、教师和研究生助手的分配。10.4 对于软件项目，要求是相同的：目标、用户手册、内部文档、进度、预算、组织机构图和工作空间分配。10.5 因此，即使是小型项目，项目经理也应该在项目早期规范化上述的一系列文档。10.6 以上集合中每一个文档的准备工作都将注意力集中在对讨论的思索和提炼，而书写这项活动需要上百次的细小决定，正是由于它们的存在，人们才能从令人迷惑的现象中得到清晰、确定的策略。10.7 对每个关键文档的维护提供了状态监督和预警机制。10.8 每个文档本身就可以作为检查列表或者数据库。10.9 项目经理的基本职责是使每个人都向着相同的方向前进。10.10 项目经理的主要日常工作是沟通，而不是做出决定；文档使各项计划和决策在整个团队范围内得到交流。10.11 只有一小部分管理人员的时间——可能只有 20%——用来从自己头脑外部获取信息。10.12 出于这个原因，广受吹捧的市场概念——支持管理人员的“完备信息管理系统”并不基于反映管理人员行为的有效模型。第11 章未雨绸缪11.1 化学工程师已经认识到无法一步将实验室工作台上的反应过程移到工厂中，需- 143 ------------------------ Page 156-----------------------要一个实验性工厂（pilot planet）来为提高产量和在缺乏保护的环境下运作提供宝贵经验。11.2 对于编程产品而言，这样的中间步骤是同样必要的，但是软件工程师在着手发布产品之前，却并不会常规地进行试验性系统的现场测试。[现在，这已经成为了一项普遍的实践，beta版本。它不同于有限功能的原型，alpha 版本，后者同样是我所倡导的实践。]11.3 对于大多数项目，第一个开发的系统并不合用。它可能太慢、太大，而且难以使用，或者三者兼而有之。11.4 系统的丢弃和重新设计可以一步完成，也可以一块块地实现。这是个必须完成的步骤。11.5 将开发的第一个系统——丢弃原型——发布给用户，可以获得时间，但是它的代价高昂——对于用户，使用极度痛苦；对于重新开发的人员，分散了精力；对于产品，影响了声誉，即使最好的再设计也难以挽回名声。