《人月神话》1975 笔记.doc

《人月神话》1975 笔记 《人月神话》的观点：是或非？ 我们理解的也好，不理解的也好，描述都应该简短精练。 塞缪尔·巴特勒，讽刺诗 第1章 焦油坑 1.1 编程系统产品（Programming Systems Product）开发的工作量是供个人使用的、独立开发的构件程序的九倍。我估计软件构件产品化引起了3倍工作量，将软件构件整合成完整系统所需要的设计、集成和测试又强加了3倍的工作量，这些高成本的构件在根本上是相互独立的。 1.2 编程行业“满足我们内心深处的创造渴望和愉悦所有人的共有情感”，提供了五种乐趣： .. 创建事物的快乐 .. 开发对其他人有用的东西的乐趣 .. 将可以活动、相互啮合的零部件组装成类似迷宫的东西，这个过程所体现出令人神魂颠倒的魅力 .. 面对不重复的任务，不间断学习的乐趣 .. 工作在如此易于驾驭的介质上的乐趣——纯粹的思维活动，其存在、移动和运转方式完全不同于实际物体 1.3 同样，这个行业具有一些内在固有的苦恼： .. 将做事方式调整到追求完美，是学习编程的最困难部分 .. 由其他人来设定目标，并且必须依靠自己无法控制的事物（特别是程序）；权威不等同于责任 .. 实际情况看起来要比这一点好一些：真正的权威来自于每次任务的完成 .. 任何创造性活动都伴随着枯燥艰苦的劳动，编程也不例外 .. 人们通常期望项目在接近结束时，（bug、工作时间）能收敛得快一些，然而软件项目的情况却是越接近完成，收敛得越慢 .. 产品在即将完成时总面临着陈旧过时的威胁 第2章 人月神话 2.1 缺乏合理的时间进度是造成项目滞后的最主要原因，它比其他所有因素加起来影响还大。 2.2 良好的烹饪需要时间，某些任务无法在不损害结果的情况下加快速度。 2.3 所有的编程人员都是乐观主义者：“一切都将运作良好”。 2.4 由于编程人员通过纯粹的思维活动来开发，所以我们期待在实现过程中不会碰到困难。 2.5 但是，我们的构思是有缺陷的，因此总会有bug。 2.6 我们围绕成本核算的估计技术，混淆了工作量和项目进展。人月是危险和带有欺骗性的神话，因为它暗示人员数量和时间是可以相互替换的。 2.7 在若干人员中分解任务会引发额外的沟通工作量——培训和相互沟通。 2.8 关于进度安排，我的经验是为1/3计划、1/6编码、1/4构件测试以及1/4系统测试。 2.9 作为一个学科，我们缺乏数据估计。 2.10 因为我们对自己的估计技术不确定，所以在管理和客户的压力下，我们常常缺乏坚持的勇气。 2.11 Brook法则：向进度落后的项目中增加人手，只会使进度更加落后。 2.12 向软件项目中增派人手从三个方面增加了项目必要的总体工作量：任务重新分配本身和所造成的工作中断；培训新人员；额外的相互沟通。 第3章 外科手术队伍 3.1 同样有两年经验而且在受到同样的培训的情况下，优秀的专业程序员的工作效率是较差程序员的十倍。（Sackman、Erikson和Grand） 3.2 Sackman、Erikson和Grand的数据显示经验和实际表现之间没有相互联系。我怀疑这种现象是否普遍成立。 3.3 小型、精干队伍是最好的——尽可能的少。 3.4 两个人的团队，其中一个项目经理，常常是最佳的人员使用方法。[留意一下上帝对婚姻的设计。] 3.5 对于真正意义上的大型系统，小型精干的队伍太慢了。 3.6 实际上，绝大多数大型编程系统的经验显示出，一拥而上的开发方法是高成本、速度缓慢、不充分的，开发出的产品无法进行概念上的集成。 3.7 一位首席程序员、类似于外科手术队伍的团队架构提供了一种方法——既能获得由少数头脑产生的产品完整性，又能得到多位协助人员的总体生产率，还彻底地减少了沟通的工作量。 第4章 贵族专制、民主政治和系统设计 4.1 “概念完整性是系统设计中最重要的考虑因素”。 4.2 “功能与理解上的复杂程度的比值才是系统设计的最终测试标准”，而不仅仅是丰富的功能。[该比值是对易用性的一种测量，由简单和复杂应用共同验证。] 4.3 为了获得概念完整性，设计必须由一个人或者具有共识的小型团队来完成。 4.4 “对于非常大型的项目，将设计方法、体系结构方面的工作与具体实现相分离是获得概念完整性的强有力方法。”[同样适用于小型项目。] 4.5 “如果要得到系统概念上的完整性，那么必须控制这些概念。这实际上是一种无需任何歉意的贵族专制统治。” 4.6 纪律、规则对行业是有益的。外部的体系结构规定实际上是增强，而不是限制实现小组的创造性。 4.7 概念上统一的系统能更快地开发和测试。 4.8 体系结构（architecture）、设计实现（imple