关于《人月神话》的读后感
基本情况：
- 书名:人月神话
- 作者:布鲁克斯(FrederickP.Brooks.Jr.)
- 页数:369
- 全书字数:316000
- 出版社:清华大学出版社
- 出版日期:2002年11月
- 阅读日期:2020年9月
一、主要内容：
针对每个章节的内容简单地进行了一些总结：
1.焦油坑
将大型的系统开发比喻成史前时代的焦油坑，在开发中不断出现的问题犹如剪不断，理还乱的毛线团，令人在其中痛苦挣扎，而又当从中挣脱一部分时，其中的乐趣远大于苦恼。这本书的价值也就在于提供一些开发的指导意见，使我们更快捷地通过这样地焦油坑。
2.人月神话
在传统的工作安排中，我们常以人月来作为工作的工作量单位，比如说这件事情十个人干了三个月，而二十个人可能就只要一个半月。它暗示着人月数量和时间是可以相互替换的，然而这样的互换在系统编程中却近乎不可能，因为我们往往向进度落后的项目中增加人手，反而会使我们开发的进度变得更加落后，制造出更多的麻烦。
3.外科手术队伍
在大型项目开发过程当中，众多人员组成的一个大型团队会存在很多缺点，管理成本高昂，团队成员能力相差太多，开发的效率跟不上，因此Mills建议大型项目的每一个部分由一个小团队解决，但是该队伍以类似外科手术的方式来组建，以充分实现团队成员的专业化合理分工。
4.贵族专制、民主政治和系统设计
为什么在系统开发过程中要强调贵族专制呢？因为在计算机系统开发过程中，由于设计被分成了由若干人完成的若干任务，所以其中的概念差异和不一致就会很大，而主张贵族专制正是考虑到开发的概念完整性，宁可省略一些不规则的特性和改进，也不提倡独立和无法整合的系统。
5.画蛇添足
在开发第一个系统时，结构师倾向与精炼和简洁。因为他知道自己对正在进行的任务不够了解，所以他会谨慎仔细地工作，而第二个系统是设计师们所设计地最危险地系统，一种普遍倾向就是过分地设计第二个系统，向系统中添加很多修饰功能和想法，他结果如同OVid所述，是一个“大馅饼”，最后只有一半操作被常规使用。
6.贯彻执行
假设一个项目经理已经拥有行事规范的结构师和许多编程实现人员，那么他该如何确保每个人听从、理解并实现架构师的决策呢。这就需要一件文档化的规格说明-手册，手册是所有开发人员统一的依据，这样才能保证一致的开发。
7.为什么巴比伦塔会失败
以巴比伦塔的失败来说明交流和组织的重要性，在大型编程项目中，因为左手不知道右手在做什么，所以进度灾难、功能的不合理和系统缺陷纷纷出现，随着工作的进行，许多小组慢慢地修改自己程序的功能、规模和速度，他们明确或者隐含地更改了一些有效输入和输出结果用法上的约定。因此在开发的过程中理应当进行一定的交流。
8.胸有成竹
一个项目时间的花费不应当只是局限于编码，计划、编制文档、测试、系统集成和培训的时间必须被考虑在内，生产率会根据任务本身复杂度和困难成都表现出显著差异。对项目进度的合理估算可以让项目的实施如成竹在胸。
9.削足适履
对项目经理而言，规模控制既是技术工作的一部分，也是管理工作的一部分。他必须研究用户和他们的应用，以设置将开发系统的规模。接着，把这些系统划分成若干部分，并设定每个部分的规模目标。由于规模-速度权衡方案的结果在很大的范围内变化，规模目标的设置是一件颇具技巧的事情，需要对每个可用的方案有深刻的了解。聪明的项目经理还会给自己预留一些空间，在工作推行时分配。
扫描二维码关注公众号，回复： 12039859 查看本文章
10.提纲挈领
在许多软件项目中，开发人员从商讨结构的会议开始，然后开始书写代码。不论项目的规模如何小，项目经理聪明的做法都是：立刻正式生成若干文档作为自己的数据基础，哪怕这些迷你文档非常简单。接着，他会和其他管理人员一样要求各种文档。
11.未雨绸缪
化学工程师很早就认识到，在实验室可以进行的反应过程，并不能在工厂中一步实现。一个被称为“实验性工厂”的中间步骤时非常重要的，他会为提高产量和在缺乏保护的环境下运作提供宝贵经验。例如，海水淡化的实验室过程会先在产量为10000加仑/每天的试验场所测试，然后再用于2000000加仑/每天的净化系统。软件系统的构建人员也面临类似的问题，但似乎并没有吸取教训。一个接一个的软件项目都是一开始设计算法，然后将算法应用到待发布的软件中，接着根据时间进度把第一次开发的产品发布给顾客。
12.干将莫邪
何为我们开发项目的干将莫邪？那就是众多的编程开发工具。开发和维护通用的编程工具会让项目开发的效率更高。项目经理需要合理地为通用工具的开发分配资源。项目经理必须考虑、计划、组织的工具首先是计算机设施，然后是实用程序、调试辅助程序、测试用例生成工具和处理文档的字处理系统。合适的开发工具和高级语言宛如良工利器可以使项目的开发事半功倍。
13.整体部分
如何开发一个可以运行的系统？如何测试系统？如何将经过测试的一系列构建集成到已测试过、可以依赖的系统？对这些问题，以前或多或少地提到了一些方法，但是在贯彻概念完整性地同时，我们仍需要对产品有更加细致的功能定义以及规范化的功能描述。根据自顶向下设计理念，程序设计应该是一系列的精化设计。
14.祸起萧墙
项目的进度被影响往往是由于多种情况产生的。但是我们可以通过制定进度表，设立里程碑来对项目进度进行准确地监控。这个必须是具体地、可度量地事件，能够进行清析地定义。
二、重点内容与个人心得：
初闻《人月神话》，以为这是一本技术之外，但是写得非常好的课外读物，所以老师才会推荐我们去读这本书，并且让我们写一篇读后感。这本书到今天为止已经读了两遍了，第一遍囫囵吞枣，感觉通篇都在讲合作沟通的重要性，然后就有了第二遍，我开始按章节看的时候才理解到好像每个章节都对应了一个方面，而这些方方面面似乎都是开发过程中或多或少不可避免遇到的问题，这本书详细地分析了这些问题地重要性，并引用了很多例证
在看到这本书前的第一个瞬间，首先吸引我的是它的书名，人月神话？为什么这么一本源于技术，重点分析强调团队开发规范化的书，会叫这么一个名字。而随着我后面不断地阅读以及思考，我也慢慢地开始懂得“人月”这个概念，它在系统编程中近乎不可能实现。
“人月”，可以认为它是一个在项目估计和进度安排中使用的工作量单位。在某种情况上来说，成本会随着开发产品的人数和时间的不同，有着很大的变化；但是成本的不断提高却不一定就会使进度不断加快，反而有可能会因出现问题致使整个进度被拖慢。因此用“人月”这个概念来衡量一项工作或者一个项目的规模是否宏大或者牛逼是存在问题的。在某种程度上来说，系统编程中的人员数量和开发时间是不能互换的，我们不能说给项目加人就一定可以加快项目完成的时间，十个人开发一个项目未必就比一百个人慢；但同时十个人开发一个项目有可能就是要比五个人开发的时间要快，我们所要实现的“人月神话”，正是在人数和时间之间达成一个工作的最大效益化。
但是同时一个好的产品开发队伍，不应该只由程序员来组成，所谓的工作效益最大化不是说用最少的成本来开发产品，开发队伍里面应该还有产品经理，有架构师，有明确的工作分工以及要求规范。曾经像求伯君那样一个人，一台电脑，一年多地时间就开发出像wps1.0这么伟大的产品的时代已经过去了。如今的项目大多数是以团队式为主的开发，而团队中每个人的思想以及性格的不同又会使项目地开发出现很大的危机，因此只有制定团队开发规范,才能够解决这一思想风格上地差异。《人月神话》就是这么一本书，它没有教我们如何去具体地挣脱大项目开发过程中出现地焦油区，他只是给我们指明了大多数开发过程中可能会出现地情况，然后让我重视这些情况。给我们应当如何合理地开发提了一些建议。我们也应当正确认识，认真对待这些建议。