人月神话(40周年中文纪念版)读后感摘抄
《人月神话(40周年中文纪念版)》是一本由(美) 布鲁克斯(Brooks, F. P.) 著著作，清华大学出版社出版的平装图书，本书定价：68.00元，页数：392，特精心从网络上整理的一些读者的读后感，希望对大家能有帮助。
《人月神话(40周年中文纪念版)》读后感(一)：懷一個孩子需要九個月，無論你把任務分給多少個女人。
標題背後的意思很明確，就是說程序有著穩定的成熟期，並非人越多所用的時間就能夠越短。
軟件工程基本上可以說是“關係”科學，它的研究對象就是概念之間的關係和人與概念的關係，自有一套難弄的邏輯。有時你要對付的不是什麼數學問題，而是你的同事或者看不見的同行，因為大家的努力，都用在彼此相容上，或者說，問題的關鍵，在於靈活性和紀律性之間的平衡。這是一門至今混亂同時也變化多端的科學。
作者如同標題名言之外的另一條名言是“在延期的課題中加入人力只能讓它延遲更多”意即，一個延期的課題，往往比較複雜，修改很多，如果再有新人參與，合作會更加困難，短期之內看不到人力增加的效果，反而會因為配合問題降低效率。
軟件工程不僅會受到人的干預，技術開發還會明顯受市場左右，新技術往往要讓位給利益、技術和商業，往往遵循的是兩套邏輯。
《人月神话(40周年中文纪念版)》读后感(二)：神作！非常好的一本书！
五星！神作！扉页上的数字表明，这本书购于2016.6，我足足看了1年3个月。分了6个晚上，陆陆续续看完了。一直拖着没看完，实因其中理论较庞杂，且时有妙语，细细品味为佳。1975年写成的书，在40年后的今天大部分理论仍然适用，且不停被引用到项目管理，软件开发排期，编程语言的选择，组织结构的调整，增量迭代开发(敏捷)，快速验证原型等诸多领域上，Brooks真乃神人也！恰巧今晚看到"程序员那些事儿"推了Brooks的言论"一个程序员一个月完成的编程工作，不要让两个程序员花两个月完成"，可知人月不能互相转换已经达成共识。软件项目里程碑未达成，只能通过赶工(加班)解决，妄想增加人手，只会在错误的道路上走得更远。一个女人生孩子需要十个月，十个女人生孩子，并不能一个月。BTW，程序员怼PM的很大原因，是PM觉得十个女人不用一个月就能生出孩子。
《人月神话(40周年中文纪念版)》读后感(三)：《人月神话》读后感
为2018.01期读书会活动所写
作为一本1975年出版的书籍，该书已经有40多年历史了，至今还在出版，可见生命力顽强。该书是软件工程方面的管理类书籍，讲述一些软件工程实践的经验。
“人月”是传统的工作量统计单位，比如一个软件需要100人月，即1个人需要干100个月能完成，100个人需要干1个月能完成。该书作者认为，以人月来衡量软件工作量是错误的。因为对于软件工程，有个细分粒度，分解到一项项的小功能后，它只能由一个人完成。如果参与人数太多，还会导致沟通成本增大，降低效率。书中核心观点：通过增加人手来提高项目进度的做法是错误的。
书中另一个核心观点是“团队必须有统一的大脑”，即决策和架构由一个人完成。这样才能保证整个软件工程的概念统一性。书中推荐技术负责人和产品负责人有一人为主一人为辅，像外科手术医生一样的工作流程。
由于该书初版距今已40年，有些观点已经众所周知，有些观点已经落伍。但40年前，它是一本管理类畅销书籍，永久不衰。
《人月神话(40周年中文纪念版)》读后感(四)：万金油
1.Brooks 60年 主持并完成了一个同样很牛逼的IBM 360系统的开发。这本书是他当年是把他写过的一些随笔整理出书的，所以书中的各个章节相对来说比较独立。
2.本书一句话概括就是1人干10个月如果等同10人干1个月，那就成神话。比如 通常怀孕需要10个月，但是显然即使 10 个人同时努力，也不能在一个月内生下孩子。
3.人月不可靠。两者不能想加来谈论。比如 向进度落后的项目增加人手会导致项目更加落后。
4.人月可靠。比如 项目初期 雏形阶段，加派 ”适当的“人手 = 外科手术一般的人数 往往会有作用。
5.二八定律。 外科主刀人+协同配合者。主刀人一定要优秀。否则无法达到减少沟通成本，提升效率。
6.没有万金油。就像没有永动机一样。但，每人应该制定自身相应的万金油。
9.在各个开发过程，绝大多数情况下安排团队成员自主去进行沟通，提高自身沟通能力及效率，并减少沟通成本。
10.进行有效的组织管理开发，形成我们组目前开发的万金油。
《人月神话(40周年中文纪念版)》读后感(五)：需求是说不清楚的问题
读这本书，自己还是初级程序员，但是这本书让我看到公司存在的一些管理问题。
总是没有需求
需求是搞不清楚的，所以快速原型很重要，软件功能的添加和修改以原型为基础。
在目前的公司做了一段时间的开发，这个问题体会比较深，我司算是公司的附属部门，公司主营业务是硬件，但是工资一直养着一个大概8人左右的开发团队，公司断断续续做了很多自用自研的项目，CRM ,售后管理，开发bug系统，公司知识库，可这些东西一直没有用起来，人走了一波来了一波，在这段时间，遇到的最多的问题是需求。老板给了一个页纸的需求点及描述，要做一个系统，开发负责人根据自己的想象而不是合理的需求分析，开发出来的东西，大家用不起来。所有如果能在老板给出简单的需求点后，先把原型做出来，在原型上确定功能和交互，这样做出来的东西肯定不一样。
总是拖延项目进度
遇到项目开发进度总是延期，仔细想想，是留给测试的时间不足，程序员总是乐观，测试的预留时间比较短，所以本来测试计划半天完成，可遇到一个bug整了一天。所以测试的时间，有时是无法准确计划的，尽量留足时间。设计，开发，测试 ，空余应该是 2：3：3：2 的计划比较合理一些。
其他一些认识
个人开发的应用程序和有文档规范的程序系统的工作量不是一个数量级。
程序开发的外科手术队伍，在开发团队中，主要写代码的可能就一两个人，十个人就能组成一个完整的团队。
开发人员的数量和开发效率不是正相关。也就是 1+1<2 ,开发成员越多，开发时的沟通成本越大。
《人月神话(40周年中文纪念版)》读后感(六)：人月神话：因爱而生
人月神话：因爱而生
只是半个世纪，
我们经历了从计算机，
到电子计算机，
到小型计算机，
到微型计算机......
硬件设计飞速革命，
软件开发却危机重重。
作为人类创造的最错综复杂的事物之一，
软件开发，
尤其是大型软件的开发，
如同操作一台复杂的外科手术，
或者烹饪一套传世的法式美味，
需要概念完整性、
结构化思维、
最佳的方法、
高效的团队。
“体系建构”的贡献、
“人是一切”、
“放弃权力的力量”、
究竟有没有“银弹”、
软件文化变迁......
一本《人月神话》，
那里有：
妙趣的比喻、
透彻的思考、
精彩的讨论，
多元的思维......
最重要的是，
rooks对计算机的热爱，
贯穿始终地，
灵动在字里行间。
那些因热爱而生的学习和探索，
那些萦绕在学习和探索之程的快乐、兴奋、沉迷和期待，
跃然纸上，
仿佛一抹心香，
缓缓传递，
慢慢流淌......
是的，
“我实在无法想象，
还有哪种生活会比热爱计算机更加激动人心。”
一本40年前的、
关于软件工程的小书，
《人月神话》，
依然和现在的软件实践密切相关，
依然是软件工程领域的重要思考，
同时，
它持续拥有除计算机领域之外的，
包括律师、医生、社会学家、心理学家等在内的，
为数众多的读者群。
“上帝所给予的谦卑，
能够使我们认识到自己的不足。”
《人月神话》，
还将陪伴那些爱它的人，
一起继续往前走。
《人月神话(40周年中文纪念版)》读后感(七)：软件的本质在于变更
《人月神话》中提到软件工程领域“没有银弹”，其根本原因在于软件本身的业务复杂性，这是现代软件系统无法规避的内在特性：复杂度、一致性、可变性和不可见性。复杂度体现在规模上比人类创造的其他实体更复杂，软件系统在构思、描述和测试上都非常困难，软件实体的扩展也不仅仅是相同元素的重复添加，而必须是不同元素实体的添加；一致性体现在软件工程师掌握的复杂度是随心所欲、毫无规则可言的，来自若干必须遵循的人为惯例和系统，而且与人强相关；可变性体现在软件会受到持续的变更压力，因为软件很容易进行修改——它是纯粹思维活动的产物，可以无限扩展，尤其是和其他产品相比，比如：硬件、建筑、汽车；不可见性体现在软件是不可见的和无法可视化的，软件结构内部相互关联、相互叠加，用不同的视图去描述是强制将关联分割，层次化一个或多个图形。
当前的软件工程还未有绝对的方法彻底解决这些问题，但也出现一些方法或多或少尝试降低这些内在特性的复杂度，简化软件领域的问题。比如：针对软件复杂度，可以采用多种架构模式、设计方法，将一个复杂系统基于不同的领域模型划分为多个相对简单的子系统，层层分解，分而治之；针对一致性，软件领域提炼了SOLID原则、KISS、DRY等一系列设计原则，同时也形成了应对多种应用场景的设计原则，而且有Linux、Kubernetes等多种开源软件或框架可以参考；针对可变性，涌现出敏捷方法，包括Scrum、极限编程、精益方法帮助开发人员应对软件快速变化的诉求；针对不可见性，软件工程领域也涌现了多种设计方法：ADD（属性驱动设计）、RUP的4+1视图、ASC（架构关注点分离模型）、DDD（领域驱动设计）帮助我们去展示软件的可视性。我们的产品，尤其是嵌入式产品，在可变性上，并没有寻找到合适的方法，而且深受其害，我们在软件变更过程中做出的种种决策，往往是为了短期目标，比如易于实现（工作量小）、影响最小（不破坏老功能）、急于求成（没有软件设计），而付出了系统长期可维护性的代价。
《人月神话(40周年中文纪念版)》读后感(八)：没有银弹
一本四十多年前的软件书，到今天还有人买来读，每年还有稳定的销量，对于计算机这种快速迭代的行业来说，这本书的存在就是一个神话。为什么一部软件书经久不衰？这是这本书最吸引我的地方。我看的是2015年出版的40周年中文纪念版，也就是说到今年这本书已经45岁了，看完我想尝试回答一下这个问题：
首先，这是一本讲管理，项目管理，具体来说是软件项目管理的书，虽然技术容易过时，但是管理却是一个需要经验积累、认知高度的事情，所以讲管理的书会活得长一点儿。而且作者是一个管理经验丰富且善于总结的人，书中给出的很多干货，即使不是完全正确，对于软件的管理也是有很多借鉴意义的，比如：
“对于软件任务的进度安排，以下是我使用了很多年的经验法则： 1/3 计划 1/6 编码 1/4 构件测试和早期系统测试 1/4 系统测试，所有的构件已完成” 想不到吧？其实编码只占整个进度的1/6。
按作者的话说，“思考者很少，实干家更少，既是思考者又是实干家的太少了。”而作者就既是思考者又是实干家，自然对于实战经验不是那么丰富，或者很少有时间停下来的从业人员来说当然很有指导意义。
第二，其实软件、软件技术、软件开发技术……并没有人们想象中发展中那么快。“而是计算机硬件技术以一种与人类历史不相配的方式爆发出来。大体上这源于计算机制造从装配工业向流水线工业、从劳动密集型向资金密集型的逐渐过渡。”而软件的发展如果要达到摩尔定律那样的速度，就需要解决软件的“流水线”化的问题，而目前，软件还是达不到像硬件工业流水化的程度。这和软件项目管理的难度，也就是整本书都在探讨的问题，是息息相关的。正因为这种难度的存在，而且长期存在，所以本书几十年来都在软件行业保留着一席之地。
最后，这其实是一本哲学书，还有什么比哲学能够持续更长时间的吗？看看标题："Ten Pounds in a Five-Pound Sack"，"Plan to Throw One Away"，"No Silver Bullet"...还有每个章节的引言都是这种风格：“我们理解也好，不理解也好，描述都应该简短精炼。”，“任何人若想看到一件完美无瑕的作品，他所想的那种作品过去不存在，现在和将来也不会出现。”……用作者的话来讲，“人类历史是一个舞台，总是在上演着相同的故事。随着文化的发展，这些故事的剧本变化非常缓慢，而舞台的布局却在随时改变。……因此，某种程度上，《人月神话》是关于人与团队的书，所以它的淘汰过程会是缓慢的。”
因此，也许再过十年，这本书也还是有用武之地。考虑到技术背景、时代背景一直在变，很多内容读上去确实显得很老套和晦涩，没有时间的读者可以先读18章和19章，如果有感兴趣的内容，再返回相应章节阅读即可。
《人月神话(40周年中文纪念版)》读后感(九)：写在华为实习之后
前阵子有幸在华为实习了两个月， 关于《人月神话》，结合实习的经历，还是多少有一点感触吧。
Brooks提出的令我印象最深刻的观点是：软件开发过程中参与人员与时间并不是线性的——沟通和交流的成本非常大，它会很快消耗任务分解所节省下来的个人时间。这也意味着，添加更多的人手，实际上是延长了而不是缩短了时间进度。这一观点确实挺颠覆的，在软件项目中，还真不是所谓的“人多力量大”，一个小模块由一至二个人负责是最合适的，每个人的编码习惯、工作节奏各不相同，参与者越多，沟通成本越大。
但是在企业中，很多时候面对的是一个大型项目，不得不需要足够的人手来支撑，此时就需要文档化的规格说明以及会议来提供高效沟通的媒介。我刚进入部门的头几天，一直在阅读编码规范手册，之后大多也会依靠产品指导手册辅助工作；身边有一位负责编写接口的同事，大部分时间都在电话会议，这也是从侧面说明了一个大型项目中沟通成本之高。
作为学生，项目中占据大多数时间的编码，而Brooks对于软件任务的进度安排给出的经验法则是：1/3 计划、1/6 编码、1/4 构件测试和早期系统测试、1/4 系统测试，所有构件已完成。测试的过程居然占据了一半的时间！其重要性可见一斑。就我看来，华为对于测试还是比较重视的，测试的责任田、测试平台的搭建都很规范。我实习中大部分时间也是在编写测试用例，可以看出在一个版本发布之前，需要进行重重关卡；毕竟早期错误发现并修改的代价可比发布之后要低得多。
另外，在作者在“贵族专制、民主政治和系统设计”这一章中，强调了概念完整性对于一个成功软件的重要性，主张将设计方法、体系结构方面的工作与具体实现相分离。从大局上来看，这种垂直划分确实从根本上减少了劳动量；但从个人发展的角度，“安安静静地作为一颗螺丝钉仿佛不是这个时代的精神”。关于这个问题，我确实没有参与过实际的开发过程，没有什么发言权，仅在此引用书中一位前辈文章中的看法（并不代表个人意见），“严格按照分工进行开发，提高了质量，看似少了机会，但从长远的角度看，大家对设计的了解更加透彻，对流程的理解更加深刻，为以后的发展打下基础”。
《人月神话》对于我这样一个半只脚还在大学校园里的人来说，可能还是有一点抽象。的确，可能只有在真正切身经历过一个企业级别的软件开发项目之后，对于作者观点的体会和认识才能来的更加深刻吧。正如一位读者所说，“它不是良药，不能为你解决实际工作中的问题，但它可以给你提供很多思考的空间，让你变得更加成熟。”《人月神话》确实得以让我站在一个更高的视角来看待软件行业；而我现在需要做的则是脚踏实地走好每一步路。
《人月神话(40周年中文纪念版)》读后感(十)：《人月神话》读书笔记
第一章：
编程的乐趣：
1. 创建事物
2. 开发对他人有用的东西
3. 组装
4. 持续学习
5. 思考相对来说容易驾驭
编程的苦恼：
1. 正确的代码
2. 由他人来设定目标、提供资源、提供信息
3. 改bug
4. 被更优秀的产品替代
5. 在资源范围内寻找可行方案
第二章：
合理的安排计划非常重要：“一切都将运作良好，任务不会超时”是错误的看法（15），其具有限定的概率。使用人月来衡量工作量是危险的做法，暗示人员数量和时间是可以互相替换的。由于程序相互练习开发人员之间需要交流（16），新人员需要培训，之前旧工作会被中断，这一估计技术并不可取。
第三章：
经验和实际的表现没有相互联系（存疑），关键还是编程速度和质量（30）。
简单的结论：让最能干的项目经理来编程开发（30）。
第四章：
创造性活动的三个阶段：Blaauw(49)：体系结构→设计实现→物理实现
如果想提高开发效率，这三步可以并行。例如，在外部说明已经有雏形的时候，设计实现人员就可以开始设计模块的变节、表结构、路径和阶段能分解、算法以及所用工具了（49）。
第五章：探讨预估工时、“冗余功能”
如何防止出现由于结构师的创造性热情造成的冗余功能？基本回答是结构师和建筑人员之间彻底、谨慎、和谐的交流。（54）
第六章：贯彻执行：编程实现人员理解结构师的决策；结构师保持系统概念上的完整性。
文档是结构师主要的工作产物，为自己描述的任何特性准备一种实现方法，但是不应该试图支配具体的实现过程（62）
建立模块间接口语法（66）。
第七章：反思项目为何失败
依旧是交流问题。
第八章，第九章：提高效率
工作量越大，效率就越低（8th）；
除了考虑局部优化，也要考虑改动对用户的整体影响（243）；
使用表数据的效率要高于流程图（9 - 102），数据的表现形式是编程的根本（244）；
第十章：准备文档
文档组成：目标、技术说明、进度、预算、工作分配
文档目的：记录内容、以明朗矛盾、沟通渠道、作为数据基础和检查列表
第十一章：对软件进行升级以及修改bug
软件的构建人员特别容易面临永恒的需求变更（247）。
随着版本号的提高，受到影响的模块数量增加了，所有修改有倾向于破坏系统的架构（122）。最后，对于系统的重新设计变成了一项必须完成的步骤（246）。
管理人员和技术人员需要有互换性（120）。
第十二章：选择工具
计算机、操作系统
语言
程序、调试程序（热加载）、测试用例生成程序、字处理系统
第十三章：整体和部分
散乱且难以整理
第十四章：如何防止项目超时延期
1. 使用清晰设立的里程碑
2. 使用PERT图：Program_evaluation_and_review_technique
3. 花费一定的资源进行计划和控制
第十五章：如何了解全局
这一章作者认为自生成文档比较好，这样开发者就不用维护两个地方了。
------
第十六章、第十七章：如何快速降低软件成本
解决灾难的第一步是将大块项目进行分解为每一个步骤（185）
软件实体的概念结构包括：数据集合、数据条目之间的关系、算法和功能调用等。作者认为，软件开发中困难的部分是对这些概念的说明、设计和测试，而不是对概念的实现。
软件内在特性：
1. 复杂度：没有两个软件的部分是相同的，软件不存在重复的部分。软件实体的扩展会导致软件元素一非线性递增的方式交互，软件必然会越来越复杂。复杂度不仅导致技术产生苦难，还引发了很多管理上的问题。因为管理者越来越难以完整的理解问题。
2. 一致性：软件领域不存在像物理学那样“对于事物简化的解释”，软件的复杂度是随心所欲、毫无规则所言的。
3. 可变性：软件的修改成本相对于汽车、建筑要低很多。软件产品扎根于文化母体中，例如用户、社会规律、计算机硬件等。后者不断变化要求了前者也要跟着变。
4. 不可见性：软件客观上不具有抽象模型，这种缺憾限制了个人的设计过程，也阻止了思路互相之间的交流。
目前的一些创新：高级编程语言，面向对象编程，广义人工智能，专家系统：接受数据和条件，通过规则推到逻辑结果，提出结论和建议。（194），自动编程，图形化编程，程序验证（工作量和验证不匹配，198），数据环境、工作站
作者认为的根本的方法：
1. 不要定制（重新开发）软件，而是要购买现成软件或者开发可重用的组件（227），以降低开发成本；
2. 建立快速的原型：软件开发人员为客户所承担的最重要的职能是不断重复的抽取和细化产品的需求（202）。复杂的软件往往是活动的、变化的系统，需要让客户和设计人员之间进行多次广泛的交流沟通。原型是应用程序的功能主线，但是不处理任何无效输入、退出清除等异常情况，用于让客户测试可用性和一致性。
3. 增量开发
4. 使用卓越的设计人员，寻求培养卓越设计人员的途径：指派职业导师、制定和维护职业计划、提供交流机会
“点石成金时人类存粹信仰的体现，人们花费大量的时间和精力来认可和接受这个无法解决的问题。即使被证明是不存在的，那种寻找出路和希望能一劳永逸的愿望，依然十分强烈……所以，将圆形变方的论文被发表，抑制脱发的洗液被研制，提高软件生产率的方法被推销。”