1975年的人月神话

1975年《人月神话》的观点：

第一章 焦油坑

1、编程系统产品开发的工作量是供个人使用的、独立开发的构建程序的9倍。我估计软件构件产品化引起了3倍工作量。将软件构件整合成完整系统所需要的设计、集成和测试又加强了3倍工作量，这些高成本的构件在根本上是相互独立的。

2、编程行业“满足我们内心深处的创造渴望和愉悦所有人的共有感情”提供了五种乐趣：

创建事物的快乐

开发对其他人有用的东西的乐趣

将可以活动、相互啮合的零部件组装成类似迷宫的东西，这个过程所体现出令人神魂颠倒的魅力。

面对不重复任务，不断学习的乐趣。

工作在如此易于驾驭的介质上的乐趣——纯粹的思维活动——其存在、移动和运转方式完全不同于实际物体。

3、这个行业的苦恼（6个）

追求完美

由他人来设定目标

真正的权威来自于每次任务的完成

任何创造性活动都伴随着枯燥和艰苦的劳动，编程也不例外

人们通常期望项目接近结束时会收敛快些，实际相反

产品在完成前都有面临陈旧过时的威胁

第二章 人月神话

1、缺乏合理的时间进度是造成项目滞后的最主要原因，它比其他所有因素的总和影响还大。

2、由于编程人员通过纯粹的思维活动来开发，我们期待在实现过程中不会碰到困难。但是，我们构思本身是有缺陷的，因此总会有bug。

3、人月是危险和带有欺骗性的神话，因为它暗示人员数量和时间是可以相互替换的。

4、在若干人员中分解任务会引发额外的沟通工作量——培训和相互沟通。

5、关于进度安排，我的经验是1/3计划、1/6编码、1/4构件测试和1/4系统测试。

6、作为一门学科，我们缺乏数据估计。

7、我们对自己的估计技术不确定，因此在管理和客户压力下，我们常常缺乏坚持的勇气。

8、Brooks法则：向进度落后的项目增加人手，只会使进度更加落后。（主要原因为3个，任务重新分配本身造成工作中断，培训新人员，额外的相互沟通）

第三章 外科手术队伍

1、优秀专业的程序猿生产率是较差程序猿的10倍

2、数据显示，经验和现实之间没有相互联系，我怀疑这种现象是否普遍成立

3、小型、精干的队伍是最好的——思绪尽可能的少，但对于真正的大型系统，小型精干队伍太慢了

4、绝大多数大型编程系统的经验显示，一拥而上的开发是高成本、速度缓慢、低效的，开发出的产品无法进行概念上的集成

5、一位首席程序猿，类似于外科手术队伍的团队架构，既能获得由少数头脑产生的产品完整性，又能得到多位协助人员的总体生产率，还彻底地减少了沟通的工作量。

第四章 贵族专制、民主政治和系统设计

1、概念完整性是系统设计中最重要的考虑因素。

2、功能与理解上的复杂程度的比值才是系统设计的最终测试标准，而不仅仅是丰富的功能。

3、为了获得概念完整性，设计必须由一个人或者一个具有共识的小型团队来完成。

4、对于非常大型的项目，将体系结构方面的工作与具体实现相分离是获得概念完整性的强有力方法。

5、纪律、规则对行业是有益的。外部体系结构规定实际上是增强，而不是限制实现小组的创造性。

6、概念上统一的系统能更快地开发和测试。

7、体系结构、设计实现、物理实现的许多工作可以并发进行。（软硬件设计都可以并行）

第五章

1、尽早交流和持续沟通能使结构师有较好的成本意识。使开发人员获得对设计的信心，并且不会混淆各自的责任分工。

2、结构师如何成功地影响实现

牢记是开发人员承担创造性的实现责任，结构师只能提出建议。

时刻准备着为所指定的说明建议一种实现的方法，准备接受任何其他可行的方法。

对上述建议保持低调和平静。

准备对所建议的改进放弃坚持。

听取开发人员在体系结构上改进的建议。

3、人们所设计的最危险的系统，通常是过分地进行设计。

4、为功能分配优先权值是一个很有价值的规范化方法。

第六章 贯彻执行

必须明确定义体系结构中与先前定义不同的地方，重新定义的详细程度应该与原先的说明一致。

出于精确性考虑，我们需要形式化地设计定义，同样，我们需要记叙定义来加深理解。

允许体系结构师对实现人员的询问做出电话应答解释是非常重要的，并且必须进行日志记录和整理发布。

项目经理最好的朋友就是他每天要面对的对手——独立的产品测试机构/小组。

第七章 为什么巴比伦塔会失败

缺乏组织和交流

需要尽早尽量仔细的设计工作手册结构

每个团队成员应该了解所有的材料（看到网页）

实时更新是至关重要的

组织结构应该是网状，而不是树型结构。

第八章 胸有成竹

构建独立的小型程序的数据不适用于编程系统项目

当使用适当的高级语言编程时，程序编制生产率可以提高5倍。

第九章 削足适履

除了运行时间外，程序所占据的内存空间也是主要开销。规模本身不是件坏事，但不必要的规模是不可取的。

软件开发人员必须设立规模目标，控制规模，发明一些减少规模的方法。

对于每个关键的文档的维护提供了状态监督和预警机制

对于每个文档本身就可以作为检查列表或者数据库

第11章 未雨绸缪

开发人员交付的是用户满意程度，而不仅仅是实际的产品。

用户的实际需要和感觉会随着程序的构建、测试和使用而不断变化。

对于一个广泛使用的程序，其维护总成本通常是开发成本的40%或者更多。

缺陷修复总会以20%-50%的几率引入新bug

第12章干将莫邪

第13章整体部分

今天软件工程的一些特殊问题

1.如何把一系列程序设计构建成系统。

2.如何把程序或者系统设计构建成健壮的、经过测试的、文档化的、可支持的产品。

3.如何维持对大量的复杂性的控制。

//本书最亮的地方，在于通过过去看现在，看历史演进，看谁主沉浮。