前言

由于《代码大全2》好几处引用了 《人月神话》的的内容，遂周末把《人月神话》看完了。总的来说，这本书更适合有管理经验的人阅读。目前我还处于开发人员的角色，学习软件工程为初衷，保持一个学习的心态总结本书有趣的思想。值得一提的是，这本书要完完整整的看完，后续的章节会对前面的章节进行补充。不进行章节的重写而是通过补充的手法，猜测其背后的原因是保留了那个年代的上下文语境。

1. 衡量工作量

1.1. 单位

“人月” —— Man Month
衡量工作量的单位，表示一个功能由一个人开发需要多少个月。

1.2. 工作量与人月（人天）的关系

管理层需要一个宏观数据，如果一个功能要超过半年才能进行业务验证，一定是不能接受的。那么往往考虑的是“加人”解决。
《人月神话》认为以“加人”为导向的缩短工期方法，是不可行的，是一种神话（点题了书名）。主要论据是：

1.2.1 忽略了沟通成本

• 把工作量与人月等价互换，会忽略人与人的沟通成本，导致预估不准
  等价互换，是一种过于美好的假设。它假设人与人之间是不需要沟通交流的，而现实世界是，两人及以上的协作需要对齐很多概念、需要调和可能出现的编码风格、需要在任务量上面进行扯皮。同样的，团队间的合作如是。

  P80: “如果项目有n个工作人员，则有(n^2 - n) / 2 个相互交流的接口，有将近2n个必须合作的潜在团队”

1.2.2 忽略了需求的特征

需求如果是不易拆分的，由多个人进行协作，会产生大量的重复劳动。特别是对需要短时间的攻坚战，更不应该加人手。如两周的任务拆给4个人，需要3天完成。4个人都在第1天完成了需求理解，本质上是进行了4次重复劳动，浪费掉了3天。

2. 外科手术团队 —— 少部分人主导项目

主刀医生是经验最丰富的，接着是副手。

2.1. 执行方式

• 1 / 7 左右的人充当关键 （1个主刀医生 + n副手) 角色
• 关键角色对产品的概念完整性负责
• 其他角色负责遵守概念并将需求落地

2.2. 遵守的理念

• 个体差异可能是指数级的

  只有少部分人能成为主刀医生，同样年限的医生工作效率也截然不同。

• 提高效率

  文档的简洁能为程序员减少学习、记忆、搜索成本。许多需求，往往是若干个简洁的表述进行组合 。所以提高整体开发效率，主旨就是让表述更加简洁。简洁和直白来自于概念完整性

• 必须将需求与实现区分出来

  需求是用来代表用户的核心利益。如果规定了如何实现，等同于扼杀了工程师的创造力。

• 不需要为独裁而惭愧

  少部分人负责概念的完整性，是因为这部分人才的流动性没有实施人员大，且有更丰富的经验，决策不用下沉至其他人，也避免了大量的沟通成本。

• 概念未完整的时候，不要动手编码
  《人月神话》自述，不同的程序员对需求有不同的理解，编码上自然难以统一，后期的调试和修改至少多花了一年时间。

3. 警惕“遗留需求”

开发第一个系统时，产品经理力求简练，一定会剔除掉某些功能。等第一版本上线后，又极其期待被砍掉的功能补充上。但是这是危险的。

• 做第一个系统时候特有的素质
  对正在进行的任务不够了解，所以会谨慎、仔细的工作。第二版本则不太拘谨了
• 如何决策
  第二版本中是否要实现遗留需求，需要由 至少两名，有系统二次开发经验的产品经理 决策

4. 管理进度

4.1 不要泄气

程序员延期后，会产生“其他的部分反正会落后”的想法，实则从整体项目来看是不一定的。项目中的任务进度推进是一个网状的关系，只要延期的事项不在“关键路径”上，依旧能保证整体按期交付。所以不要泄气，专注于眼前的任务，解决它。
目前待过的公司都没用上关键路径来管理项目，曾经理论学习过，写过一篇博客 。

4.2. 设定合适的里程碑并记录完成过程

• 里程碑一定要具体

  设定具体的指标，好处是避免汇报扯皮

• 记录完成过程有利于决策下一个里程碑的内容

5. 怎么写文档 P169

不同的用户需要的文档详细程度不同，具体的内容书中已经总结的很好了。

5.1. 怎么对待流程图

“逐一记录的详细流程图过时而令人生厌，它只适合启蒙初学者的算法思维”
我十分赞同这句话，流程图一般是用于理解代码用的，自己写的代码往往不需要先生成流程图。
有一个例外，我认为ER图、时序图 还是很好用的，并且是足够简单的时序图。在评审环节可以让评审人更直观的了解程序交互的系统、角色。在代码完成后绘制时序图曾让我看出代码质量不好的地方，并以出现简洁时序图为宗旨，最后把代码改造的更加可读。

5.2. 自文档化的程序

原则是代码的说明最后跟代码放在一起。所以有了 self-documenting 的说法。

• 规范
  JavaDoc
• 语言
  XML、Groovy DSL 本身就具有较高的可读性

6. 没有银弹 —— 软件开发的核心困难

“比起对概念进行表达和对实现逼真程度进行验证，以下的事项更为困难”

• 规格说明
• 设计
• 测试

现代软件系统无法规避的内在特性

• 复杂度
  数学家和物理学家为复杂的现象建立简化的模型，从而论证特性。但是这一套方法在软件开发中行不通，软件系统
  中的多种状态、语言特性、依赖的环境特性等因素都是构成软件复杂度的重要因素，无一可以被剥离出去。

• 一致性
  软件开发的目标之一是兼容性，如果要保持兼容性，代码上就要做大量的妥协。对软件的任何再设计，都无法简化这些复杂性

• 可变性
  需求变了、实现也一定变。这跟建筑工程完全不同。软件工程会遭受持续变更的压力

• 不可见性
  硬件有电路图，但是试图用图形来描述软件时，发现它是有很多互相关联、重叠在一起的图形。

7. 软件开发次要困难的解决方案（已知的）

• 高级语言

• 分时
  这个指为不同的团队设定共享资源的使用时间段，减少硬件资源竞争带来的部署缓慢、不稳定。

• 面向对象编程
  本质上是 “信息隐藏”。采用良好的接口封装、利用继承来表达层次关系、而不用交代实现，尽可能避免原来过程化编程曲解他人代码而造成的bug

• 需求精炼和快速原型
  敏捷开发、极限编程。旨在把跟用户的沟通频率提高。

• 增量开发
  小步快走，能提高正反馈。小版本之间构成产品族树，以最低限度控制版本失败的成本（可以按照树回溯到上个版本）
  

后记

《人月神话》一定要全部看完。主要是因为这本书的编排方式，后文会对前文进行补充，甚至是否定。比如 P176 的内容 关于信息隐藏，Parnas 是正确的，我是错误的。 如果看完书抓不住重点，P339 开始的内容会帮助我们找到重点，可以回头再看看相关内容。这本书的内容应该作为“课外读物”，提炼出思想是为了更好的理解管理工作以及看看大佬的眼界。看完这本书对软件工程更加敬畏了，保持谦虚，一路学习。