《The Mythical Man-Month（人月神话）》读后感（1）

临近考试周，这里我通过平时阅读的《人月神话》十九个章节和知乎、简书等网页中网友们对《人月神话》的读后感，对书中各个章节进行简单的总结，以下均为个人手打观点的思考与整合，仅供大家参考。

乍一看书名，人月？什么是人月？并非我第一下所想到的超级赛亚人看到月亮时的情景。人月是在估计和进度安排中使用的工作量单位。每个每月的工作量，这和我在公司实习中在系统中统计外包人员UT数量的性质相同。

书中作者的观点是，用人月来衡量一项工作的规模是一个危险和带有欺骗性的神话。它暗示着人员数量和时间是可以相互替换的，人数和时间的互换仅仅适用于某个任务可以分解给参与人员，并且他们之间不需要相互的交流的情况。下面让我们进入各个章节来看看作者所想表达的观点。

第0章 焦油坑

这里，我们沿用梦断代码给目录编辑的方式，以程序员的习惯，将其称为第0章。开篇以焦油坑为题，让人联想到了史前巨兽在焦油坑中垂死挣扎的震撼场景，也同样暗示了过去几十年来大型系统开发犹如焦油坑一样，各种问题纠结在一起，让人越陷越深，没有办法看清事情的本质。

作者认为编程系统产品开发的工作量是供个人使用的、独立开发的构件程序的九倍。如下图所示，普通程序要想成为真正有用的编程系统产品，可以通过成为横向功能上相互协作的编程系统和纵向通用的编程产品来实现，而编程代价均为3倍于原来的编程。

图1 编程系统产品的演进

编程这一职业同样也是有乐趣和苦恼的，程序员，就像诗人一样，几乎仅仅工作在单纯的思考中。程序员凭空运用自己的想象，来建造自己的“城堡”。这个观点与《黑客与画家》中的观点不谋而合，后者把程序员的工作看成和画家、作家一样的类似。但是也正因为程序员所做的工作是纯粹的智力创造，不断的推倒重来就成为常态。概念设计上的不完善，使得软件架构变得越来越庞大、复杂并且难以为继，成为一个焦油坑，越是挣扎，越是深陷其中。

第1章 人月神话

在众多软件项目中，缺乏合理的时间进度是造成项目滞后的最主要原因，它比其他所有因素加起来的影响还大。这些原因在于我们美好的假设（过于乐观）、将进度和工作量混淆、过高的估算、缺乏跟踪和监督、进度落后时下意识的增派人手。

所以问题的关键是，如何使得项目进度不落后；要想使得项目进度不落后，就要制定出合理的项目进度。故问题又可以称为如何制定出合理的项目进度。这里作者给出了自己多年的经验法则：“1/3计划+1/6编码+1/4构建测试和早期系统测试+1/4系统测试，所有的构建已完成”。充足的测试时间和仅仅1/6的编码时间，这与我们大多数新人的观念大相径庭，很多时候我们常常认为编码时间就是全部的时间了，难怪会导致进度落后。

对于课上“如何理解Brooks法则”，书中也给出了相应的解答：项目的时间依赖于顺序上的限制，人员的数量依赖于单个子任务的数量。从这两个数值可以推算出进度时间表，该表安排的人员较少，花费的时间较长（唯一的风险是产品可能会过时）。相反，分派较多的人手，计划较短的时间，将无法得到可行的进度表。

此外，向软件项目中增派人手从三个方面增加了项目必要的总体工作量：任务重新分配本身和所造成的工作中断；培训新人员；额外的相互沟通。

第2章 外科手术队伍

接着上一章的话题，需要协作沟通的人员的数量影响着开发成本，因为成本的主要组成部分是相互的沟通和交流，以及更正沟通不当所引起的不良结果（系统调试）。因此系统应该由尽可能少的人员来开发，Mills建议大型项目的每一个部分由一个团队解决，该队伍以类似外科手术的方式组建，而并非一拥而上。也就是说，由一个人来进行问题的分解，其他人给予他所需要的支持，以提高效率和生产力。

外科手术队伍的成员组成如下：

1.外科医生：首席程度员，天分、经验、能力；

2.副手：外科医生的后备，较少的经验；

3.管理员：控制财务、人员、工作地点安排和机器的专业管理人员；

4.编辑：分析重组开发文档；

5.两个秘书：管理员和编辑每人需要一个秘书；

6.程序职员：维护编程产品库中所有团队的技术记录；

7.工具维护人员：保证所有基本服务的可靠性，以及承担团队成员所需要的特殊工具的构建、维护和升级责任；

8.测试人员：大量合适的测试用例，搭建测试平台；

9.语言专家：寻找合适的编程语言。

图2 10人程序开发队伍的沟通模式

在具体运作中，首先，外科医生和副手都了解所有的设计和全部的代码，保证了工作概念上的完整性。其次，在外科手术团队中，不存在利益的差别，观点的不一致由外科医生单方面来统一。最后，团队中剩余人员职能的专业化分工是高效的关键，它使成员之间采用非常简单的交流模式成为可能，即所谓的专业的事交给专业的人来完成。

对于这样的团队的扩展，若要实现一个200人来解决的问题，我们仅仅需要协调20个人，即这20个“外科医生”，借助他们的思路来保证大型程序部分概念的完整性。

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

作者借欧洲教堂风格的完整性，来表达了自己在系统设计中的主张：“概念完整性应该是最重要的考虑因素”。

为了实现概念完整性，在软件体系结构设计的时候必须实行贵族专制，让少数的架构师来决定整体的架构，普通程序员毫无发言权。但是Brooks为了安慰那些可怜的普通程序员，说道：其实实现细节也是需要一样的创造性、同样的新思路和卓越的才华。但是谁都知道，如果能够成为贵族，为何要在制造工艺上费劲心思呢？

总结一下，作者认为设计由一个人或者具有共识的小型团队来完成更能够活得概念的完整性，对于大型的项目，可以将设计方法、体系结构方面的工作与具体实现相分离，将体系结构、设计实现、物理实现的诸多工作并发进行。

第4章 画蛇添足

本章主要讲述的是结构师需要认识到第二个系统的风险，从而少犯错误。这是因为，在开发第一个系统时，结构师倾向于精炼和简洁。他知道自己对正在进行的任务不够了解，所以他会谨慎仔细地工作。第二个系统则是设计师们所设计的最危险的系统（可能是过分的设计）。而当他着手第三个或第四个系统时，先前的经验会相互验证，得到此类系统通用特性的判断，而且系统之间的差异会帮助他识别出经验中不够通用的部分。

结构师无法跳过第二次系统，但是他可以有意识的关注那些系统的特殊危险，运用特别的自我约束准则和设计理念、目的的变更，来尽可能避免画蛇添足的后果。结构师必须坚持至少拥有两个系统以上开发经验结构师的决定。同时，保持对特殊诱惑的警觉，他可以不断提出正确的问题，确保原则上的概念和目标在详细设计中得到完整的体现。

第5章 贯彻执行

假设一个项目经理已经拥有行事规范的结构师和许多编程实现人员，那么，接下来，他需要做的是如何确保每个人听从、理解并实现自己作为结构师的决策。

手册、或者书面规格说明，是一个非常必要的工具，尽管光有文档是不够的。手册是产品的 外部 规格说明，它描述和规定了用户所见的每一个细节；同样的，它也是结构师主要的工作产物。随着用户和实现人员反馈的增加，规格说明也在不断地被完善。

这里再次强调了一致性的重要：即使是大型的设计团队，设计结果也必须由一个或两个人来完成，以确保这些决定是一致的，同样地，必须明确定义体系结构中与先前定义不同的地方，重新定义的详细程度应该与原先的说明一致。出于精确性的考虑，我们需要形式化的设计定义，利用记叙性定义来加深理解。允许体系结构师对实现人员的询问做出电话应答解释也是非常重要的，并且必须进行日志记录和整理发布。最后一个建议是，项目经理最好的朋友就是他每天要面对的敌人——独立的产品测试机构/小组，他们是用户的代理人，专门寻找缺陷。设立测试小组是使设计决策得以贯彻执行的必要手段，同样也是需要尽早着手，与设计同时实施的重要环节。

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

据《创世纪》记载，巴比伦塔是人类继诺亚方舟之后的第二大工程壮举，但巴比伦塔同时也是第一个彻底失败的工程，而其失败的原因是缺乏交流和组织。

一个编程项目中同样会出现这样的问题，开发团队应该以尽可能多的方式进行相互之间的交流：非正式、常规项目会议，会上进行简要的技术陈述、共享的正式项目工作手册。

团队组织的目的是减少不必要交流和合作的数量，因此良好的团队组织是解决上述交流问题的关键措施。这里给出如果项目有 n 个工作人员，则有（n^2 - n）/ 2 个相互交流的接口，有将近 2^n个必须合作的潜在团队。而减少交流的方法是人力划分和限定职责范围。交流和交流的结果——组织，是成功的关键，交流和组织的技能需要管理者（这里建议为产品负责人）仔细考虑，相关经验的积累和能力的提高同软件技术本身一样重要

第7章 胸有成竹

本章只解决一个问题：一个程序员的生产效率究竟有多高？首先，作者明确了估计的两个要点，一是仅仅通过对编码部分的估计，然后乘以任务其他部分的相对系数，是无法得出对整项工作的精确估计的；二是构建独立小型程序的数据不适用于编程系统项目。对此，作者指出了工作量和代码行数不是线性关系，而是指数关系：工作量＝（常数）×（指令的数量）^1.5。文中又给出了Portman的数据、Aron的数据、Harr的数据、OS/360的数据和Corbato的数据，这里就不一一列举了。

总结以下上述数据的结论：

1.对于常用编程语句而言，生产率似乎是固定的。这个固定的生产率包括了编程中需要注释，并可能存在错误的情况；

2.生产率随着系统复杂性或者难度增加而降低；

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

第8章 削足适履

这一章主要是要解决项目投资与磁盘空间和内存之间的矛盾，但是这个矛盾在电脑硬件发展到现在的层次已经可以忽略掉了。

第9章 提纲挈领

技术、周边组织机构、行业传统等若干因素凑在一起，定义了项目必须准备的一些文书工作。而这对一个新任命的项目经理来说是一大难题，这些文档的某些部分包含和表达了一些管理方面的工作。

本章通过对比计算机产品的文档、大学科系的文档、软件项目的文档，进一步阐释了为什么要有正式的文档。软件项目的要求包括目标、用户手册、内部文档、进度、预算、组织机构图和工作空间分配。即使是小型项目，项目经理也应该在项目早期规范化上述的一系列文档。

一个正式的文档能够明确团队中的分歧和矛盾、作为同其他人的沟通渠道、作为数据基础和检查列表，通过遵循文档开展工作，项目经理能更清晰和快速地设定自己的方向。

本次读后感先写到《人月神话》中的前十章，明天再继续整理出剩余的九章内容，与同学们共同学习、进步。