【www.jxscct.com--读后感】
《人月神话》是一本由[美] 弗雷德里克·布鲁克斯著作，清华大学出版社出版的平装图书，本书定价：29.80元，页数：369，文章吧小编精心整理的一些读者的读后感，希望对大家能有帮助。
《人月神话》读后感(一)：文科生无力评价
书中给出了一些概念与现下创造性的软件及项目都由小组织完成，并且解释了一些程序员的脾性。程序是追求完美的工作，而这种技术活需要多与艺术才能够达至工程完美之上的精致。
只能以文科生的浅薄眼光做个摘要——
1、所有的编程人员都是乐观主义者。可能是这种现代魔术特别吸引那些相信美满结局的人；也可能是成百上千琐碎的挫折赶走了大多数人，只剩下了那些习惯上只关注结果的人；还可能仅仅因为计算机还很年轻，程序员更加年轻，而年轻人总是乐观主义者。
无论是什么样的程序，结果是毋庸置疑的：“这次它肯定会运行。”或者“我刚刚找出了最后一个错误。”（#165-168）
2、Brooks法则：
向进度落后的项目中增加人手，只会使进度更加落后。（Adding manpower to a late software project makes it later) (#275-276)
3、软件经理很早就认识到优秀程序员和较差的程序员之间生产率的差异，但实际测量出的差异还是令我们所有人吃惊。在他们一个研究中，Sackman、Erikson、Grand曾对一组具有经验的程序人员进行测量。在该小组中，最好的和最差的表现在生产率上平均为10:1。（#289-291）
4、思路是大约十个人的想法，但如果像保持文字和产品之间的一致性，则必须由一个或两个人来完成将其结论转换成书面规格说明的工作。而且，将定义写成文字，必须对很多原先并不是非常重要的问题进行判断，并得出结论。（#594-597）
5、书面记录决策是必要的。只有记录下来，分歧才会明朗，矛盾才会突出。书写这项活动需要上百次的细小决定，正是由于它们的存在，人们才能从令人迷惑的现象中得到清晰、确定的策略。（#1040-1043）
6、必须关心每一天的滞后，它们是大灾祸的基本组成元素。（#1451-1452）
7、不了解，就无法真正拥有。——歌德·克雷布（What we do not understand we do not possess.——GOETHE）（#1515-1517）
8、软件开发上的困难是决定说什么，而不是如何说。表达的简化仅仅能提供少量的促进作用。（#1800-1801）
9、当一个可运行系统，即使是非常简单的系统出现时，开发人员的热情就迸发了出来。在开发过程中的每个阶段，总有可运行的系统。我们发现开发团队可以在四个月内，培育（grow）出比搭建（building）复杂得多的系统。（#1949-1952）
——————————————————————————————
2014/6/3-13 期间完成了一次杭州行，以及忙碌的工作周。读不懂严重影响阅读享受呐。
《人月神话》读后感(二)：作者尽量用科学化的语言来描述软件工程，管理本身也是一个工程
对比现在的工作。感觉我们最应该加强的有两点：1. 通过关注质量来提高生产率，而不是仅关注结果；2. 开发时要注意层次化和增量化，给之后的扩展留出空间，发现可修改性降低时立即补救；3. 风格没有严格统一；4. 测试用例不够丰富。
我们做的好的：1. 通过接口的清晰定义，来避免不必要的沟通成本；2. 持续化的撰写和修改文档，保证项目的透明。
《人月神话》读后感(三)：IT项目管理的艺术
人月神话
==============
@(note)[reading-notes|pm]
人月神话的英文是 《Man-Month Mythical》，也就是说，人月其实是软件工程管理工程量的单位，一个人每月的工作量，其实是想说明是使用人月的方式来估算大型项目是不靠谱的，只是一个神话的方式。
> 我们面临的挑战和任务是在实际的进度和有效的资源范围内，寻找解决问题的**切实可行方案**。
> 在众多软件项目中，缺乏合理的进度安排是造成项目滞后的最主要原因，它比**其他所有因素加起来的影响还要大**。
这点深有感触，这也是PM存在的价值，如果项目缺乏规划后果一定是失败的，其实做人做事不是都是一样的嘛？
> 所有的编程人员都是乐观主义者
这点大大有感触，不要将自己陷入到自信和永久做不完任务的泥潭中
> 使用人月可以精确计算的情况是：人数和时间可以互换，所有的任务都可以有效的分解。（但在实际的项目中，这种情况几乎是不存在的）
> Brooks法则： 向进度落后的项目增加人手，只会使进度更加落后。
需要考虑团队的培养成本和隐形的辅导别人花费的时间
> 外科手术队伍： (小型项目可以使用) 小而精悍的人员构成的团队。这样子的效率是高的。但是不适用于大型项目，因为对于大型项目而言，人数太少一定是慢的。这种情况下为了平衡好效率和概念完整性，最好是由少数干练的人员来设计和开发。
在这本书中多次提到了 **概念完整性** 的概念，结合自己的项目开发经验，这点确实非常重要。尤其是一些底层架构的设计和构思上，一定要有一个一致性的结论和方案，而不是大家各自搞成一套，也许这个设计上存在问题或者不完整的地方，但是可以调整，但是不可以违背设计的初衷，否则整理的概念完整性就被破坏了，这在项目后期的时候会用更多的工作量来修复因为设计迭代上导致的问题。不过说回来，这确实是经验活，在开始的时候就考虑到需要做的事情，需要预留的接口，都是对整个业务体系有深刻了解的人。
> System 360 系统的一致完整性仅来自于两名作者，思路是多个人的结果，但是最终形成规定和文字说明的只有两个人决定。例如，System 360需要决定在每次操作之后，如何设置返回的条件码。看似这种琐碎的问题，但其实对于整个系统设计而言，**这些琐碎问题处理上的一致性绝对不是一件无关紧要的事情**！
确实如此，简单说是细节决定成败，大了说，所有优秀的设计和大型项目的构建都是具有绝对的规律和自律的，比如参考[西斯廷教堂][1]的构建。
> 古老的格言：“不要携带两个时钟出海，带一个或者三个”
> 精湛的技艺出自**创造，精炼，充分和快速**，程序设计也是如此。技艺改进的结果往往是**战略上的突破，而不仅仅是技巧上的提高**。更普遍的情况是，战略上的突破常来自于**数据或表的重新表达，这是程序的核心所在**
数据结构为王，数据为王呀！！！
> 如果提供了程序流程图，而没有表数据，我仍然会很迷惑。而给我看表数据，往往不用再看流程图，程序的结构是非常清晰的。
深有感悟，结构的设计，算法的设计都是为了数据服务的，有了数据的设计，所有的问题都会变得明了。同理，设计系统的不好，很大程序上因为数据结构设计的不好。这也说明在设计的时候，对于数据结构的设计需要给予**充分的时间以及配对的文档描述**，这对于后期的维护和开发都是大有裨益的
> 实际上，数据的表现形式是编程的根本。（好吧，直接上升到本质的层次了）
> 程序维护的一个基本问题：缺陷修复总是会以固定（20%=50%）的几率引入新的bug。所以，整个过程是前进两步然后后退一步。
> 为什么缺陷不能更彻底的修复？首先，看上去很小的错误，似乎是局部操作的失败，实际上却是系统级别的问题。何况后期开发的人员不是最初编写代码的开发人员，而是一些列初级的程序或者新手，他们在设计的时候往往是没有考虑全之前的设计的，导致的问题是：看似简单的任务却导致很多的bug。
结合我自己的经验，在我们的项目后期，因为时间紧张，我将部分模块的开发工作给了新的的同学，本来以为是一件简单的事情，但是后期却出现了很多的问题，甚至是非常严重的问题。这点给我的反思就是即使非常简单的东西，也需要考虑好结构，然后指导新手去完成，而不是直接告诉他们功能去实现，需要你去设计好结构，然后让他再去实现。毕竟后期加入的同学不可能也不会有时间去掌握你之前的设计，何况设计也许也是糟糕的或者是有很多坑的，再其中增加东西，不是只是简单的功能堆积，很可能会产生连锁的反应。
> 我们的大脑具有的多样性，自我保护和自我更新的能力，其中的秘密就是逐步发育成长，而不是一次性搭建。开发模式也是如此，迭代增量的开发，这种模式迫切的需要自上而下的开发形态。
> 但是软件最重要的部分一定是：人。卓越的设计者和一般设计者的产品差异差了一个数量级。卓越设计者生产的成果更快，更小，更简单，更干净，实现的代价更少。
> There is nothing in the world constant but inconstancy.
FXXK the real truth.
> 我们理解也好，不理解也好，描述都应该简短清晰。
> 关于进度安排，我的经验是：1/3 计划 1/6 编码 1/4 构件测试 以及 1/4系统测试。
> 每个人看到每件事的目标是错误的！各个部分应该被封装，从而没有人需要或者被允许看到其他部分的内部结构，只需要了解接口。
> 能消除，至少是能指明有副作用的程序设计方案，对维护成本有很大的影响。
不要依赖于有副作用的方式，或者tricky的技巧，这些都可能是后期evil的根源。
> 人就是一切（或者说，几乎是一切）。我们行业的主要问题实质上更侧重于社会学而不是科学技术。
> 学习变成最困难的部分是将做事的方式向追求完美的方向调整。
> 不要低估产品的难度，难度估计的高点总是没有错的。
在确定任务进度的时候要争取更多的时间，这点我容易犯下的错误，不要低估了时间，按时按量的完成任务才是关键，何况很多东西就应该有固有的时间，时间紧张了，临时的方案，后面都是需要花更多的时间和精力去弥补的，为何不在开始的时候就多留一些时间，设计出一个更加有效，灵活的方案呢。
程序员都是自信的，对于进度估算上尤其如此，所以自己以后需要更加合理的估算进度，时间估算的多点总是没有坏处的。套用书中的一份法式餐厅菜单上的句子：「做好菜是需要时间的。如果人家让您多等会儿，那是为了让您最后吃得高兴。」
[1]: http://baike.baidu.com/link？url=Gcm5JqY7C2sslOpy8CjwRsuGAdzmhsE_CGtXOboRiSOJvovol4Y1n6yZOw1N1uLs55f6u4Yk-elZX_8BGqEN0a
《人月神话》读后感(四)：让码农去改变世界吧
这本书有些枯燥，据说软件项目领域内的经典之作。
看了下，用本书的思想来描述一下：
我们码农，像
诗人一样，单纯地思考着世界的存在和意义。
我们码农，像魔法师一样，键入一个又一个咒语，以魔术般的力量创造出自我运转的世界。
很少有人类的活动要力求完美，程序却像是神的咒语，以一个个音节、一个个停顿层层构建出前所未有或已经存在的事物。
我们就是操纵咒语的魔法师，但现实往往是不完美的，往往需要在有限的时间和有限的资源条件下，寻求最实用、最有利的解决方案。
问题是，项目越大，就越像面对一头困入沼泽的巨兽，没有足够的实力和技巧就无法将他脱出泥沼。
想要解决掉它，需要一个团队，但更需要一位英雄。
团队不是一拥而上，而是以外科手术方式来操刀。
于是，一个主治医师操刀对问题进行分解，其他成员提供各种支持。主导手术的码农就这样成长为大魔法师一样的人物。
依靠强有力的组织和执行力，有的码农相当于几十或者几百个普通码农的战斗力。
我们码农就这样不断的打怪升级、升级打怪......
《人月神话》读后感(五)：盲目的评分更显自己的不自信
这本书的观点的适应的项目规模：大型项目，上百人到上千人；
适用的软件工程类型：工程型、专业型等软件而不是现在普遍的大众型软件；
还有这本书毕竟是软件工程尚未成熟的情况下写的，其中的观点现在基本都已经流程化、系统化和成熟化了，所以对现在的开发没有太大的价值，顶多就是配菜，而且很不爽口甚至绕口；
作者完全以自己的视角来叙述，可读性极差，举例基本上是ibm项目，
我想说的是您弄个大家都不懂的例子岂不是更加增强了解释的混乱性；
翻译是相当的差，也可能是作者自己思维不是特别明确又或者是作者笔法不行；
人都是跟风的动物，没有自己独立的思考就胡乱评价，这本书最多3分，
让你及格是看在作者资历和真诚的份；
这本书如果不是因为作者的名气大，基本上无人会读；
《人月神话》读后感(六)：补课
编程的乐趣和苦恼，创造性的过程必须在一定的限制条件下去创新，这个行业的苦与乐。体力与脑力的结合。
人月的不可替代性。人才的流失对于一个公司的影响是很大的，项目的关键阶段，额外的增加人力不能减少所需要的时间，因为额外的培训需要的时间。
必要的文档对于项目成功的重要性，所有的假设和讨论都是基于文档来进行的。包涵重要的信息，对于项目的计划和实施至关重要。agile的开发流程还是需要文档的，不是说文档不重要。
新技术对软件行业的影响，基于软件商品包暴露的接口进行开发，操作系统的进化，使用脚本语言来进行模块之间的交互。
结构师的作用，保证设计的一致性，外科手术的架构体系。对于大的组织结构来说，一个核心的SWA团队，然后带领蓝领来进行设计。能达到效率的最大化。
专门的团队来开发共用的软件库，来提升效率。AIW中refactor中减少项目的依赖性，就是通过这个方式来运行的。
沟通对于保证项目的成功至关重要。项目经理起的就是润滑油作用。
技术和管理两条线，之间可以相互借调。
《人月神话》读后感(七)：软件工管理&现代工程管理
****************************************************这本书的格局
我很喜欢这本书。
这本书从软件的乐趣和苦恼写起，体现了老一辈黑客的纯粹。也体现了生活哲学：莫忘初心。
确实，软件对于一个立志于建设的青年来说是最理想的场景：凭空，凭大脑，凭双手，凭一台计算机。
比尔盖茨起家的空手套白狼，google的双人组，twitter的大学寝室传奇。包括现在写日志的豆瓣网创始人咖啡馆一周完成故事。
IT业是一个传奇的行业，传奇是软件的自然属性。
我也喜欢作者宽阔的视野。
软件开发团队与外科手术队伍的类比，类比的非常棒。
与化学工业的对比，也非常棒。
与建筑行业的对比，当然我们都在干，所谓IT民工也。
更不论巴别塔、silver bullet的形象比喻。
大学教育学生多学多懂就是指望像这样通过对比启迪思维。
我也喜欢作者看破历史迷雾的预测能力。
no silver bullet，这是作者对软件开发效率提升的预测。
基于对软件开发核心问题的认识，和行业过去重大进展的分析和总结，现有新技术的分析和总结。这是任何一个想要掌握历史大势的人所要做的基本功。
以天赋为根基，以快乐为目的，莫忘初心，先宽后广的高等教育，理论知识和实际实践经验的积累和总结。
这就是作者所展示的素质。也正是高等教育和想做事业的人，理想的社会人应有的素质。
******************************************************************本书的架构
通读此书，感觉愉快。
比想象中的有趣&有用很多。
计算机系的软件工程课程就像大多数工科课本那样：只有what，how，没有why。
此书将软件工程管理的困难、原因、解决办法，一一道来。
计算机系学生参与过一个4人及以上的项目，实际进行过符合规程的测试，即可阅读此书，以全局视野纵览软件工程。
果然如所有本行业的前辈所说的那样，软件工程应该尽早学习。大三或更早。对软件工程有认识了，有利于自己的学习计划、职业规划。
凡是参与过4人以上的项目，便认识到：
复杂。软件的复杂，人的复杂，合作的复杂。
就是这俩字。一切问题来源都在软件开发的复杂。
复杂所以交流是问题。
所以需要文档、科学的管理体系，所以人月只是个神话
复杂所以可靠性是问题。
所以严格的测试，合理的测试计划很重要
复杂所以进度规划是问题
所以不同阶段的时间管理、进度评估、迭代开发很重要。
复杂所以一致性是问题
所以我们要确定领导核心的民主集中制——外科手术团队
软件行业永远是大海航行靠舵手。
由复杂二字起，软件工程的一切井井有条的被分析。
以上都不超乎大多数人的理解能力。
作者也提出了软件工程的复杂性未来进行更科学的研究和度量的可能。类似信息论在通信领域的作用。这是个目光高远的建议。
我更推崇的是作者所体现出的那种西方的管理素养：
客观看待人性，科学管理。
计算机本科生的软件工程教材上应该不会对软件架构师办公室的地毯应该被注意有所描述。
这方面例子如本书中对老板和项目负责人的矛盾如何解决的客观描述
将工程的规律和人的规律结合起来论证才是本书真正的特色和高水准之处。
凡是想做事的人，尤其是工科人实在应该多读几本管理尤其是工业管理的书，正如此书。
才能不卑微如打工仔心态，也不傲慢得不切实际，能够真正客观。
******************************************
想想此书成熟的年代，那些靠敲汇编语言，在狭小的屏幕，纸带存储，小的可怜的内存完成复杂工作的前辈。
想想那些动辄就是议论重新设计语言，实现编译器的前辈。
风淡云轻的写此书。
堪称举重若轻。
现代程序员的软硬件工具强大无比，更多的乐趣，更少的苦恼。
实在应该珍惜。
莫忘本心。
《人月神话》读后感(八)：一个人十个月开发的完的项目，十个人一个月是做不完的
作者一开始提出的编程的乐趣和苦恼，我深感赞同。我觉得说出了我的心里话。我也认为，编程的核心乐趣是在一种极其容易操作的介质上进行创造。而苦恼一方面是要违背本性的在编程过程中追求完美，一方面是现实中的创造往往受到多种外界条件的制约。
一个人十个月开发的完的项目，十个人一个月是做不完的。这差不多就是本书的核心思想。
越大型的项目，花在有效编码上的时间越少。作为一个面向市场的成熟产品的开发，真正大量的时间花在计划、团队内部沟通、测试、整合、文档之上。
作者讲他开发一般会花三分之一的时间做计划，六分之一的时间编码，一半的时间做各种测试。作者也提到编程的另外一种苦恼就是做完之后发现开发的东西过时了。我觉得作者提到的这种开发方式大概是过时了，毕竟是六七十年代的事情。快速制作产品原型，快速迭代我觉得更适合现在这个时代。
充分测试和文档的重要性几十年来应该没有变化。
《人月神话》读后感(九)：没的标题
这本书对于现阶段的我只能是扩大了知识面，让我知道匡总是反面的典型，对着书里所讲的，我发现他把所有不对的做法都实践干净了。
牛逼的程序员比傻逼的程序员要牛逼很多。
傻逼的程序员比牛逼的程序员要傻逼很多。
2人*2月≠4人月。
一切要遵循万物发展的规律。
文档很重要，比你爹妈还重要。
程序验证，自动生成代码等等有鸟用，关键是也只有鸟用。
王垠肯定部分同意这位老伙计的看法。
宁当菜鸟，不当傻逼，虽然很多时候傻逼就是菜鸟。
没有银弹看完了就没看了，一堆我听都没听过的远古机器名词，以后再拿出来重看。
《人月神话》读后感(十)：人月终究只是神话
这本书，看得挺费神的，不像故事书有个情节，不像一般的小说有一条线索让读者去追随，也没有哲学的优美，不像手册一样条条框框简单明了，第一感觉就是，读得挺累的。
“孕育一个生命需要十月怀胎，所以不管有多少个母亲，时间都是一样的”，阐明增加人手来弥补项目被拖延的进度，有时候是不现实的。从这里开始慢慢透漏出，人月是神话的韵味。
运筹学里学过一道典型题目，一个工程的最早开始时间，最晚结束时间等，当时觉得这不是很简单的吗？有必要这么重点进行讲解吗？后来在数据结构中又碰到类似的题，那时候依旧是觉得有点小题大做的感觉，直到读了这本书，才知道一个项目的进度的跟进多么的重要！
这本书个人觉得比较适合项目管理者看，或者是老板级别的人物看。前部分主要讲项目进度的跟进的重要性，进度被拖延后采取的策略以及用处，项目推进的过程需要注意的一些步骤。中间是文档记录日志的汇总等的重要性。后半部分都是在说人狼和银弹，文中作者表明10年内不会有银弹的出现，而银弹是什么呢？就是能杀掉人狼的东西。看到这里是不是还是丈二的和尚摸不着头脑？文中有一句话是对银弹的描述就是：没有一个计算机技术能够使得计算机的生成效率得到数量级的增长，所以没有银弹。（大致是这样）
文末后部分说到面向对象的编程技术能够提升生成效率，但是效率还是很低下的，所以说面向对象的编程技术也是不能成为是银弹。
本文来源：https://www.jxscct.com/xxs/36158/
