人月神话(40周年中文纪念版)读后感10篇
《人月神话(40周年中文纪念版)》是一本由(美) 布鲁克斯(Brooks, F. P.) 著著作，清华大学出版社出版的平装图书，本书定价：68.00元，页数：392，特精心从网络上整理的一些读者的读后感，希望对大家能有帮助。
《人月神话(40周年中文纪念版)》读后感(一)：懷一個孩子需要九個月，無論你把任務分給多少個女人。
標題背後的意思很明確，就是說程序有著穩定的成熟期，並非人越多所用的時間就能夠越短。
軟件工程基本上可以說是“關係”科學，它的研究對象就是概念之間的關係和人與概念的關係，自有一套難弄的邏輯。有時你要對付的不是什麼數學問題，而是你的同事或者看不見的同行，因為大家的努力，都用在彼此相容上，或者說，問題的關鍵，在於靈活性和紀律性之間的平衡。這是一門至今混亂同時也變化多端的科學。
作者如同標題名言之外的另一條名言是“在延期的課題中加入人力只能讓它延遲更多”意即，一個延期的課題，往往比較複雜，修改很多，如果再有新人參與，合作會更加困難，短期之內看不到人力增加的效果，反而會因為配合問題降低效率。
軟件工程不僅會受到人的干預，技術開發還會明顯受市場左右，新技術往往要讓位給利益、技術和商業，往往遵循的是兩套邏輯。
《人月神话(40周年中文纪念版)》读后感(二)：神作！非常好的一本书！
五星！神作！扉页上的数字表明，这本书购于2016.6，我足足看了1年3个月。分了6个晚上，陆陆续续看完了。一直拖着没看完，实因其中理论较庞杂，且时有妙语，细细品味为佳。1975年写成的书，在40年后的今天大部分理论仍然适用，且不停被引用到项目管理，软件开发排期，编程语言的选择，组织结构的调整，增量迭代开发(敏捷)，快速验证原型等诸多领域上，Brooks真乃神人也！恰巧今晚看到"程序员那些事儿"推了Brooks的言论"一个程序员一个月完成的编程工作，不要让两个程序员花两个月完成"，可知人月不能互相转换已经达成共识。软件项目里程碑未达成，只能通过赶工(加班)解决，妄想增加人手，只会在错误的道路上走得更远。一个女人生孩子需要十个月，十个女人生孩子，并不能一个月。BTW，程序员怼PM的很大原因，是PM觉得十个女人不用一个月就能生出孩子。
《人月神话(40周年中文纪念版)》读后感(三)：需求是说不清楚的问题
读这本书，自己还是初级程序员，但是这本书让我看到公司存在的一些管理问题。
总是没有需求
需求是搞不清楚的，所以快速原型很重要，软件功能的添加和修改以原型为基础。
在目前的公司做了一段时间的开发，这个问题体会比较深，我司算是公司的附属部门，公司主营业务是硬件，但是工资一直养着一个大概8人左右的开发团队，公司断断续续做了很多自用自研的项目，CRM ,售后管理，开发bug系统，公司知识库，可这些东西一直没有用起来，人走了一波来了一波，在这段时间，遇到的最多的问题是需求。老板给了一个页纸的需求点及描述，要做一个系统，开发负责人根据自己的想象而不是合理的需求分析，开发出来的东西，大家用不起来。所有如果能在老板给出简单的需求点后，先把原型做出来，在原型上确定功能和交互，这样做出来的东西肯定不一样。
总是拖延项目进度
遇到项目开发进度总是延期，仔细想想，是留给测试的时间不足，程序员总是乐观，测试的预留时间比较短，所以本来测试计划半天完成，可遇到一个bug整了一天。所以测试的时间，有时是无法准确计划的，尽量留足时间。设计，开发，测试 ，空余应该是 2：3：3：2 的计划比较合理一些。
其他一些认识
个人开发的应用程序和有文档规范的程序系统的工作量不是一个数量级。
程序开发的外科手术队伍，在开发团队中，主要写代码的可能就一两个人，十个人就能组成一个完整的团队。
开发人员的数量和开发效率不是正相关。也就是 1+1<2 ,开发成员越多，开发时的沟通成本越大。
《人月神话(40周年中文纪念版)》读后感(四)：人月神话：因爱而生
人月神话：因爱而生
只是半个世纪，
到小型计算机，
到微型计算机......
硬件设计飞速革命，
软件开发却危机重重。
软件开发，
尤其是大型软件的开发，
需要概念完整性、
结构化思维、
最佳的方法、
高效的团队。
“人是一切”、
究竟有没有“银弹”、
一本《人月神话》，
那里有：
妙趣的比喻、
多元的思维......
最重要的是，
rooks对计算机的热爱，
贯穿始终地，
跃然纸上，
仿佛一抹心香，
缓缓传递，
慢慢流淌......
是的，
“我实在无法想象，
一本40年前的、
关于软件工程的小书，
《人月神话》，
依然是软件工程领域的重要思考，
同时，
它持续拥有除计算机领域之外的，
为数众多的读者群。
能够使我们认识到自己的不足。”
《人月神话》，
还将陪伴那些爱它的人，
一起继续往前走。
《人月神话(40周年中文纪念版)》读后感(五)：《人月神话》读书笔记
第一章：
编程的乐趣：
1. 创建事物
2. 开发对他人有用的东西
3. 组装
4. 持续学习
5. 思考相对来说容易驾驭
编程的苦恼：
1. 正确的代码
3. 改bug
第二章：
合理的安排计划非常重要：“一切都将运作良好，任务不会超时”是错误的看法（15），其具有限定的概率。使用人月来衡量工作量是危险的做法，暗示人员数量和时间是可以互相替换的。由于程序相互练习开发人员之间需要交流（16），新人员需要培训，之前旧工作会被中断，这一估计技术并不可取。
第三章：
经验和实际的表现没有相互联系（存疑），关键还是编程速度和质量（30）。
第四章：
创造性活动的三个阶段：Blaauw(49)：体系结构→设计实现→物理实现
如果想提高开发效率，这三步可以并行。例如，在外部说明已经有雏形的时候，设计实现人员就可以开始设计模块的变节、表结构、路径和阶段能分解、算法以及所用工具了（49）。
第五章：探讨预估工时、“冗余功能”
如何防止出现由于结构师的创造性热情造成的冗余功能？基本回答是结构师和建筑人员之间彻底、谨慎、和谐的交流。（54）
第六章：贯彻执行：编程实现人员理解结构师的决策；结构师保持系统概念上的完整性。
文档是结构师主要的工作产物，为自己描述的任何特性准备一种实现方法，但是不应该试图支配具体的实现过程（62）
依旧是交流问题。
第八章，第九章：提高效率
工作量越大，效率就越低（8th）；
使用表数据的效率要高于流程图（9 - 102），数据的表现形式是编程的根本（244）；
第十章：准备文档
文档目的：记录内容、以明朗矛盾、沟通渠道、作为数据基础和检查列表
随着版本号的提高，受到影响的模块数量增加了，所有修改有倾向于破坏系统的架构（122）。最后，对于系统的重新设计变成了一项必须完成的步骤（246）。
管理人员和技术人员需要有互换性（120）。
第十二章：选择工具
计算机、操作系统
语言
程序、调试程序（热加载）、测试用例生成程序、字处理系统
第十三章：整体和部分
散乱且难以整理
第十四章：如何防止项目超时延期
1. 使用清晰设立的里程碑
2. 使用PERT图：Program_evaluation_and_review_technique
这一章作者认为自生成文档比较好，这样开发者就不用维护两个地方了。
------
第十六章、第十七章：如何快速降低软件成本
解决灾难的第一步是将大块项目进行分解为每一个步骤（185）
软件实体的概念结构包括：数据集合、数据条目之间的关系、算法和功能调用等。作者认为，软件开发中困难的部分是对这些概念的说明、设计和测试，而不是对概念的实现。
软件内在特性：
1. 复杂度：没有两个软件的部分是相同的，软件不存在重复的部分。软件实体的扩展会导致软件元素一非线性递增的方式交互，软件必然会越来越复杂。复杂度不仅导致技术产生苦难，还引发了很多管理上的问题。因为管理者越来越难以完整的理解问题。
2. 一致性：软件领域不存在像物理学那样“对于事物简化的解释”，软件的复杂度是随心所欲、毫无规则所言的。
3. 可变性：软件的修改成本相对于汽车、建筑要低很多。软件产品扎根于文化母体中，例如用户、社会规律、计算机硬件等。后者不断变化要求了前者也要跟着变。
4. 不可见性：软件客观上不具有抽象模型，这种缺憾限制了个人的设计过程，也阻止了思路互相之间的交流。
目前的一些创新：高级编程语言，面向对象编程，广义人工智能，专家系统：接受数据和条件，通过规则推到逻辑结果，提出结论和建议。（194），自动编程，图形化编程，程序验证（工作量和验证不匹配，198），数据环境、工作站
作者认为的根本的方法：
1. 不要定制（重新开发）软件，而是要购买现成软件或者开发可重用的组件（227），以降低开发成本；
2. 建立快速的原型：软件开发人员为客户所承担的最重要的职能是不断重复的抽取和细化产品的需求（202）。复杂的软件往往是活动的、变化的系统，需要让客户和设计人员之间进行多次广泛的交流沟通。原型是应用程序的功能主线，但是不处理任何无效输入、退出清除等异常情况，用于让客户测试可用性和一致性。
3. 增量开发
4. 使用卓越的设计人员，寻求培养卓越设计人员的途径：指派职业导师、制定和维护职业计划、提供交流机会
“点石成金时人类存粹信仰的体现，人们花费大量的时间和精力来认可和接受这个无法解决的问题。即使被证明是不存在的，那种寻找出路和希望能一劳永逸的愿望，依然十分强烈……所以，将圆形变方的论文被发表，抑制脱发的洗液被研制，提高软件生产率的方法被推销。”