《人月神话》读后感与读书笔记_人月神话讲了什么

《人月神话》讲了什么

一开始我觉得这本书重点是在软件工程，但后来我觉得更准确的说法是，《人月神话》是讲软件工程中人与团队关系的。
一个由个人完成的“小”程序，和一个由团队完成的“大”程序，有根本性的不同，《人月神话》将讨论的是那些由团队进行开发的大型程序。另外，软件工程的项目管理也和其他类型的项目管理有很大不同，软件工程往往更复杂，存在很多“不可见”的东西。

这本书由于年代久远，部分所讨论的东西已经和现在有较大差异。不过还是有很多重要且并没有过时的道理，我将分章节记录下来。
需要说明：书的【第18章《人月神话》的观点：是与非】，也分章节做了概括性的观点，因此这篇读书笔记将与其类似。不过，这里我将从自己的角度去记录我最关心的内容。

第1章：焦油坑

大型系统开发就像一个焦油坑，很多强壮的动物都在其中挣扎。

---

如果将一个 “程序” 提升为 “产品”（意味着：通用化、测试、文档、维护）需要3倍的时间；如果将一个 “程序” 提升为 “系统”（意味着：接口、系统集成），需要3倍时间；而如果将一个 “程序” 提升为 “系统产品”，就需要9倍了。

第2章：人月神话

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

---

沟通所增加的负担由两个部分组成：培训和相互的交流。

---

在众多软件项目中，缺乏合理的进度安排是造成项目滞后的最主要原因，它比其他所有因素加起来的影响还要大。

第3章：外科手术队伍

2万美元/年的程序员的生产率可能是1万美元/年的程序员的10倍。

---

小型、精干队伍是最好的——思绪尽可能少。

---

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

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

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

第5章：画蛇添足

在开发第1个系统时，结构师倾向于简洁，之后不断产生装饰和润色。第二个系统是最“危险”的，往往会过度设计。而随后的系统由于之前的经验会相互验证，因此能识别出不够通用的部分。

第6章：贯彻执行

设计结果必须由一个人或两个人完成，以确保这些决定是一致的。

---

确保贯彻执行：

• 手册
• 形式化定义
• 直接整合到代码
• 会议
• 多重实现
• 电话日志
• 产品测试

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

为什么？因为缺少交流。文档（手册）很重要。

---

但有一种看法认为：编程人员只了解自己负责的部分效率更高。确实，但这要求精确，完整地定义所有地接口。

---

【产品负责人】&【技术主管】

第8章：胸有成竹

软件工作量是根据规模成指数型增长的，指数大约是1.5，即：
$$工作量=常数\times 指令的数{量}^{1.5}$$

---

实践是最好地老师
实践是最好地老师，但智者还能从其他地方有收获。

第9章 削足适履

这一章讨论了内存成本问题。基本的教训是：

1. 制定预算
2. 确切定义模块的功能
3. 需要有人进行宏观掌控。因为团队内的成员都是争取小红花的学生，都在局部优化自己的程序而很少考虑整体影响。

---

另外的措施是：

• 让用户选择模块，减少不需要的内存占用。
• 让“时间”换“空间

---

此外，革新的算法或者数据结构也能从根本上优化。

---

（不过，书中讨论的关于内存的限制情况已经和如今差别巨大。例如对于“时间”和“内存”的折中，从我个人在做交互工具的经验而言，“时间”往往比较重要，如果能用多点的“空间”来换取，一般会做这种交易。）

第10章：提纲挈领

任何管理任务的关注焦点都是：时间、地点、人员、项目内容、资金。

---

为什么要有正式的文档？

• 书面决策是必要的，只有记录下来，分歧才会明朗，矛盾才会突出。
• 文档能够作为同其他人沟通的渠道。
• 项目经理的文档可以作为数据基础和检查列表。

第11章：未雨绸缪

为舍弃而计划，无论如何，你一定要这么做

---

唯一不变的就是变化本身

---

程序维护就是：前进两步，后退一步。
随着修改的增多，还可能变为：前进一步，后退一步。

第12章：干将莫邪

工具很重要，需要专门人员开发

---

“仿真装置”很重要

---

不确定性是所有情况中最糟的，因为它剥夺了程序员寻找BUG的能力

第13章：整体部分

系统各个组成部分的开发者都会做出一些假设，而这些假设之间的不匹配是大多数致命和难以察觉的BUG的主要来源。

---

自上而下的设计。

第14章：祸起萧墙

灾祸通常来自于白蚁的肆虐，而不是龙卷风的侵袭。项目进度经常以一种难以察觉，但是残酷无情的方式慢慢落后。

---

里程碑的日期选择是一个估计技术上的问题，很大程度上依赖以往的经验。
里程碑的选择只有一个原则：必须是具体的，特定的，可度量的事件，能够进行清晰的定义。

---

并不是每一天的滞后都等于灾难。如何判断哪些偏离是关键呢？可以采用PERT图（Program Evaluation and Review Technique）。

---

有两种掀开毯子将污垢展现在老板面前的方法：

1. 减少角色冲突和鼓励状态共享。老板决不在检查状态的时候做安排。
2. 猛地掀开地毯。建立能了解状态真相的评审机制。

第15章：另外一面

这一章强调了“文档”的重要性。即使是完全开发给自己的程序，仍然是必要的，因为记忆会衰退。

---

不同用户需要不同级别的文档：

1. 使用程序。不需要了解程序的代码。
2. 依赖程序。需要调用程序，因此需要知道程序代码的外部接口
3. 修改程序。需要完全知道程序中代码的内部结构。

---

“流程图”被过分吹捧了。

---

自文档化的程序：
试图努力维护不同文件之间的同步关系，是一件费力不讨好的事情。 但我们在文档编制的时候违反了这一规则：程序变动总是不能及时准确地反映在文档之中。相应地解决方法就是：将文档整合到源代码中。
其实说白了，就是通过加注释等方法提高代码的可读性。如果代码非常好读懂，那就不需要文档了。

第16章：没有银弹

所有的软件活动包括：

• 根本任务：即打造构成抽象软件实体的复杂概念结构。
• 次要任务：即使用编程语言表达这些抽象实体，在空间和时间限制下将它们映射成机器语言。

目前取得的进步基本上都是“次要任务”上的，但是“根本任务”上的困难一直存在，并且可以预见在短时间内无法取得数量级上的进步。

困难的特性：

• 复杂度
• 一致性
• 可变性
• 不可见性