文章吧-经典好文章在线阅读:《人月神话》读后感10篇

当前的位置:文章吧 > 经典文章 > 读后感 >

《人月神话》读后感10篇

2018-02-10 21:54:02 来源:文章吧 阅读:载入中…

《人月神话》读后感10篇

  《人月神话》是一本由弗雷德里克・布鲁克斯著作,中国电力出版社出版的精装(无盘)图书,本书定价:25.0,页数:336,文章吧小编精心整理的一些读者的读后感,希望对大家能有帮助

  《人月神话》读后感(一):人月神话(不朽的软件工程名著)

  本评论转自我的Blog

  转载必须包含本声明、保持本文完整。并以超链形式注明作者编程随想和本文原始地址

  http://program-think.blogspot.com/2009/03/book-review-mythical-man-month.html

  对于软件工程而言,我个人认为到目前为止,尚未有哪本书的影响力和深刻程度能够超越《人月神话》(全名是:The Mythical Man-Month -- Essay on Software Engineering)。于是考虑来聊一下鼎鼎大名的《人月神话》。如果你已经熟读此书,并且自认为深刻掌握其精华,本帖子你就不必再看了。

  ★作者及写书的背景

  根据“如何选择IT书籍”里面提到的经验,作者是书籍质量的一个主要保证。所以我先来八卦一下《人月神话》的作者:Frederick Phillips Brooks(以下简称Brooks)。这位老兄最牛X的成就是在60年代(他当时才29岁)主持并完成了一个同样很牛X的IBM 360系统的开发。IBM 360后来被誉为是人类从原子能时代进入信息时代的标志。该项目不光具有历史意义,而且在软件工程方面非常有代表性(因为其规模复杂度)。为了给大伙儿加深印象,列举该项目的几个数据如下:

  --------------------------------

  软件人员总数  2000 四十年后,微软的Windows 2003团队也就5000人

  软件总费用   5亿$ 发明第一个原子弹的曼哈顿工程也不过才花20亿$

  开发周期    4年

  --------------------------------

  注意,上述仅仅是软件方面的统计。

  最终,IBM 360项目并没有完成全部的预定目标,但是对于这个史无前例的项目,居然没有中途夭折,本身已经算是奇迹了。后来,Brooks在1975年(距今已30多年)把他所写的一些软件工程方面的随笔(很多都与360项目有关)整理出版,也就是我们今天点评的《人月神话》。

  ★本书的结构

  前面已经说了,Brooks当年是把他写过的一些随笔整理出书的,所以书中的各个章节相对来说比较独立。因此你不一定按照排版的顺序来阅读。比如我每次重读这本书都只是挑选其中一两个章节来看。

  ★本书的看点

  虽然本书的每个章节都称得上是经典,但限于篇幅,只把我印象最深刻的几章介绍一下。

  ◇第2章,关于“人月”的误导

  这是本书最有名气的章节。在本章,Brooks明确反对使用“人月”这个极具欺骗性的度量单位。因为人月这个称谓暗示着“人”和“月”是可以互换的。

  即使到今天为止,还是有大量的编程人员、测试人员、项目经理和软件公司老板错误地使用人月来衡量软件开发的工作量,实际上,当某人宣称某工作量是6个人月时,这句话本身是没有太大意义的。一般来说,1个人干6个月的工作,6个人在1个月内几乎很难完成。所以我在沟通工作量时,都会明确地讲清楚需要几个人干几个月。

  另外,Brooks根据人月的不可互换推导出一个怪论:向进度落后的项目增加人手会导致项目更加落后。这个怪论是如此出名,以至于后来被称为Brooks法则。每当上级领导企图通过增加人手来赶进度时(往往在项目后期),我都会搬出这个法则来拒绝这种企图。

  ◇第3章,关于团队的组成

  为了解决前几章中提到的大型团队的种种困难,Brooks提出了一种新的解决方案:把大型团队拆分为若干个类似于外科手术式的小团队。

  每个小团队有一名主程序员(类似于主刀医生),所有的问题分解和功能定义都通过主程序员来完成,以此来降低沟通成本。并且,每个主程序员配备若干个平庸的人帮他/她打下手,也很符合现实情况(还记得“二八原理系列”中提到的优秀人员和平庸人员的比例吗?)。具体角色职责我就不细说了,书上都有。

  ◇第16、17章,关于“没有银弹”的大实话

  实际上第16章“没有银弹”的内容来自于作者在1986年作的报告,后来才加入书中。第17章“再论没有银弹”是20周年版加入的。

  据作者在本书的“20周年纪念版”中宣称,“没有银弹”是引发最多争议的章节。不过我个人认为:虽然引发最多争议,但是这两章却是全书最重要、最深刻且最有价值的章节。即使你从事的工作和软件工程无关,你也应该认真阅读它。

  rooks在第16章分析了软件开发的根本性困难(复杂性、非一致性、易变性和不可见性)和次要性困难。分析完根本性困难和次要性困难之后,作者断言:未来十年内,不可能有某种技术突破(银弹)能够彻底解决根本性困难,从而导致软件开发效率数量级的提高。

  现在,时间已经过去了远远不止十年。在“没有银弹”发表之后,软件界冒出了数不清的新玩意儿(比如面向对象、组件技术、设计模式、CMM、UML、敏捷开发、RAD、等等),很多新玩意儿的创造者都号称他们发明了银弹。但实际上没有哪个新技术能够经受住时间的考验并真正获得银弹的称号。

  ★我个人的建议

  啰嗦了这么多,最后来说说我个人的几点建议:

  如果你从来没有看过本书,那赶紧去找一本来,并全部读一遍(不一定要按顺序看)。

  如果你以前看的是老版本,那赶紧去找来新版(20周年纪念版),并重点看看增补的4个章节。

  如果你已经把新版全部看完,今后可以考虑定期(例如每隔一两年)再拿出来翻一翻。

  《人月神话》读后感(二):貌似他预言了一切

  1.关于“人月”的神话,最近的一个大项目验证了这点,为了缩短项目周期zg的项目不断的增加人员,但是周期还是被一拖再拖。从我这个新来者的角度,我来这个新的项目需要学习了解太多东西,这需要一段时间。如果项目组有意识培训的话,可能会好一些。但是,实际上没有,实际情况也很惨。

  2.关于“外科手术团队”的组建项目团队的方式,已经被广泛的应用了,但是少量的落后公司还是没有使用它。

  3.自上而下整体的架构的方法,也是。这是我最近在思考的问题,看了之后豁然开朗,我们需要一个架构师。并且让他不要被一些琐事羁绊

  4.关于沟通,关于文档,如何将架构师的意图传达下去,以及如何将这些反馈反映到架构师那里,这个一直都是很重要的。

  5.关于潮流,关于构件,关于面向对象的发展的,关于购买软件(SOA不正是它的一个变种么)真是很有洞察力!当然他错误判断了“封装”的重要性

  恩最后,最重要的是 不要异想天开,没有银弹。需要我们一点一滴的把软件工程做好。这也许是最郁闷也是最有趣的方面。。。。

  《人月神话》读后感(三):软件研发方法论经典

  软件研发,首先是一个创作活动,不是照本宣科的复制或者重复性的劳动;其次软件必须是对现实的抽象和创新,而不是天马行空的恣意想象。这决定了软件研发不是能够按部就班制作出来,注定研发过程不是完全可控的,所以软件应该是演化而来的。

  既然是创作性活动,影响软件研发的核心要素是人。对于创作的影响,精英普通选手之间的贡献比是差别很大的。

  软件研发,复杂度和规模决定了必定是团队创作。团队的目标统一组织清晰有序、沟通明确顺畅,过程的有序、有效产出,是促进软件研发成功的有效方法,但不是银弹。

  软件研发的两个核心复杂度:软件对现实的抽象和创新;团队创作目标、组织、沟通、价值统一。

  《人月神话》读后感(四):《人月神话》读书笔记

  《人月神话》是软件工程方面的一本经典著作,其作者布鲁克斯(Frederick P. Brooks)被誉为“IBM System/360之父”,他曾是这一系统的项目经理,后来在设计期任360操作系统的项目经理。由于这一工作,他与Bob Evans和Erich Bloch 1985年曾获美国国家技术奖。Brooks博士早期曾担任IBM公司Stretch和Harvest计算机的体系结构设计师。1999年,他还荣获美国计算机领域最高奖图灵奖。

  作者在第一章总结了编程的快乐烦恼。编程的乐趣主要是创造的乐趣、学习的乐趣。而其烦恼是难以达到完美,必须付出艰苦的劳动,项目似乎总是倾向于推迟完成,最可怕的是产品还未完成就可能已经过时了。

  所有的程序员都是乐观主义者,他们倾向于认为事情会如他们想象的那么顺利,而事实上并非如此。所有的软件项目都倾向于被推迟完成。那种认为大项目只是增加足够的程序员就能顺利完成,已经对于已经推迟的项目,只要增加人手就能按期完成的看法是错误和危险的,因为它假定人和月是可互换的,而其实将工作分割给许多人、培训和程序员之间的交流都需要额外的工作。Brooks提出这样一条定律:给推迟的软件项目增加人手将使得项目更加推迟。

  有数据表明:好的程序员与差的程序员的生产力可能相差10倍以上,而且编程经验与编程的优秀度没有直接关联(一名糟糕的程序员不会在编10年程序后就成为优秀的程序员)。所以一个小规模的精锐的团队要比一个大的却有很多平庸的程序员的团队要好得多。一个两人的团队,其中一个作为领导者,通常是最好的使用脑力的方式。书中甚至似乎是玩笑地说:如果准备200人开发一个大项目,如果有25名项目经理,那么让这25人组成开发团队,将其余175解雇掉。但是,对于真正大的系统,小规模的团队开发速度又太慢,难以满足需求。这时,一个主程序员,就像手术团队中只有一名主刀医师的模式是很好的模式。一个团队另外配一名副程序员(与主程序员分享设计,并且代替主程序员于一般程序员、工具制造者、测试人员、语言律师交流)、一名管理员(管理钱、人、机器等)、一名编辑(修改、评价主程序员写的文档),管理员与编辑都配一名秘书。主程序员只与副程序员、管理员和编辑交流,这样就大大减少了主程序员与其他人的交流量。

  系统设计中最重要的是概念的完整性。应明白概念的完整性而不是功能的多样性是评价系统好坏标准。概念上统一的系统更容易建造和测试。要保证概念上的完整性,设计应该由一个人或者观念一致的小规模小组完成。这看似具有贵族主义倾向,却是保证系统概念上的完整性的需要。架构师的角色与军队的统帅很类似,虽然独裁,但是却是必须的。分离建构和实施是建造大工程时保证概念完整性的重要手段。这不是创造性和非创造性工作的分离。事实上,实施过程中同样需要大量创造性的工作。

  要保证项目尽快、低成本地完成,架构师与建造者之间尽早和持续的交流很重要。架构师应如何影响实施呢?首先应记住建造者有创造性实施的责任,架构师只是建议,而不是命令。其次,总是建议一种实施方案,但是永远准备接受其它同样好或者更好的方案。应无声和私人地给予这些建议,同时应准备对别人建议的好的方案给予赞扬和肯定。还有应能听取建造者对于架构的改进意见。第二个系统是一个设计的最危险的系统:最常见的倾向是过度设计。系统可能功能过于丰富,实际上只有半数的功能是常用的。为了避免二次系统效应,可以让一个设计师同时设计二个系统,另外,可以为每一功能付予一个优先值,这样如果时间不允许,可以去掉优先级低的功能。

  在工程实施过程中,每周有架构师、软件和硬件实施者代表、市场计划者组成的小组例会是非有用的。总架构师主持会议,如果对于一个问题达不成一致意见,由总架构师决定。会议应有确定的书面的讨论议案。另外,架构师应随时准备回答实施者对于设计的问题。实施者在有疑惑时不应猜测架构师的意图,而应询问清楚。询问的电话记录应集中起来,分发给所有实施者手中。项目经理的最好的朋友是他每天的敌人:独立的产品测试组织。

  巴别塔项目失败原因缺乏交流和组织。缺乏交流的问题可以通过电话交流、定期的项目会议和一本共享的正式的项目工作报告书解决。项目工作报告书应该有很好的结构,及时更新,每个人都可以看到。良好的组织可以减少所需的交流量。树状结构是传统的组织方式,它是可行的,但并不一定是最有效的,因为有利于交流的组织方式应该是网状的,但是完全的网状结构因为交流量太大,也是不可行的。所以需要设计出特别的组织交流机制以克服树状结构的不足(通常可以在树状结构中连接一些虚线)。在一个大的项目中,有两个角色是很重要的,一个是生产者(producer),就是管理经理,另一个是技术总监(经理)。管理经理负责组织团队、分配工作、创建日程表等。很多时候,他建立内部交流和报告的模式,但是很多时候负责团队之外的交流。技术经理构造设计,确定模块,保证系统的统一性和概念完整性等。管理经理和技术经理需要的天赋、能力是不同的。同时具有管理天赋和强的技术天赋的人是极其少见的。思想者很少,实干家也很少,有思想家特质的实干家是最少的。只有在3至6人的小项目中,管理经理和技术经理才可以是一个人。在更大的项目中,这两个角色应该由不同人担任,因为两者都需要全身心投入。

  准备估计一个编程项目的工作总量并制订进度表是很难的,因为很难根据编码时间来估算整个项目需要完成的时间。建造小系统的数据不能应用到大型系统上。据研究,若按基本语句来计算,软件的生产率基本是个常数,其原因是每个人的思考速度基本上是个常数。相比低级语言,使用一种合适的高级语言可以使生产率提高5 倍。

  程序占用的内存和硬盘空间是另一个要考虑的因素。尤其是对于操作系统软件而言,占用内存大小是要考虑的重要因素。不是说只要是大程序都是不好的,但是不必要的大程序却是。因此软件编写者必须设定软件大小的目标,控制大小,设计减少大小的技巧。软件大小的目标必须包括内存大小目标和占用磁盘大小目标。在设定大小目标的同时必须规定软件要实现的功能,防止程序员以减少功能为代价来减少软件大小。在大的项目中,分小组通常只考虑自己小组的目标的实现,而不顾对用户的影响。因此的实现的整个过程中,系统架构师必须时刻保持警惕,保证系统的完整性。为完成一个完整的系统,保持用户取向的态度是编程经理最重要的功能。另外还有时间-空间权衡的问题,为使空间-时间协调,整个小组要进行编程技巧的培训。但是精巧的快的程序几乎都是由战略上的突破产生的而不是战术上的聪明。通常,这种突破是一种新的算法,更常见的,这种突破来自数据或表的重新表示。表示法是编程的本质。

  一个计算机产品的主要文档包括目标(需求、需要的东西、限制、优先级)、规范(计算机手册和性能规格)、进度表、财务预算、组织结构图、空间、预测、估算、价格等。正式的文档是非常重要的:首先,将决定写下来是至关重要的,只有当一个人将自己的想法写下来的时候,不确定性、不一致性才可能凸显出来。其次,有了写出来的文档,才可能与别人交流你的决定。最后,经理的文档给他一个数据库和一个检查清单。根据正式的文档,他才会知道自己身在何处。经理每天主要的工作是交流,而不是做决定。文档将计划和已经做出的决定传达给整个团队。作为项目经理,只有一小部分时间,约20%的时间花在从外部获取信息上,所以,市场上呼声很高的的所谓“管理全部信息系统”不是建立在真正的管理实践之上的模型。

  在绝大多数的项目中,第一个建构的系统几乎不可用:太慢、太大、太不好用或者三者都有。所以准备做一个要扔掉的系统是很好的打算,因为即使最好的计划第一次也不可能保证有效。关键是,管理者是否预先就打算建造一个扔掉的系统。将垃圾扔给顾客当然可以节省时间,但是是以用户的痛苦为代价,设计者在重新设计时将会分心,还有,产品的坏名声将使得好的二次设计的产品没有生存空间。所以,计划扔掉一个,因为无论如何你会扔掉的。另外,应该明白,用户的目标和需求是会改变的,所以在设计时就应该准备改变,而不是假定不变,因为唯一不变的是变化本身。不仅目标和需求会变,开发策略和技术的改变也不可避免,准备扔掉一个的观念就是承受当一个人学习的时候,他改变自己的设计。设计可变化系统的技巧包括模块化,好的子程序,模块之间全面的接口定义以及所有这些的全面文档。组织也应该能应对变化。所有的计划、里程碑和时间表都应该是有弹性的,以应对变化。然而建立一个能应对变化的组织是更难的。老板应该尽量使得管理人员和技术人员在他们的天赋允许的情况下可互换:因此,管理人员应上技术课程,技术人员应进行管理培训。在天赋允许时,高级人员应随时准备自己写代码,技术人员也应乐意进行管理。要保证这一点,不应在管理人员和技术人员中进行高低的划分,管理级别和技术级别应完全等价(Bell实验室即进行了这种实践,它废除了所有的职业头衔)。那种高级的技术人员到最后必须走上管理岗位的观念是错误的。程序维护占据开发代价的约40%。软件的维护与硬件的维护是非常不同的:软件维护通常是修复系统缺陷、增加功能、适应使用环境和配置的变化。维护的费用受用户数量的影响,越多的用户发现越多的漏洞。但是在修补漏洞的时候必须十分小心,因为在修补一个漏洞的时候有20%到50%的概率引入另一个漏洞。在修补任一个漏洞后,应该做所有全部的测试。

  好的工人使用好的工具。在软件开发过程不仅需要通用的工具,还需要个性化的工具,最核心的问题是交流。使用高级语言编程可以提高生产力和调试速度,一般的反对意见(能干我所干的事、目标代码太大、目标代码太慢)都是难以成立的。交互式编程也可以提高生产力。

  在没有任何代码之前,编写出的规格说明应该提交给外面的测试组以检查其完全性和简明性。最有破坏性和隐蔽的漏洞是不同模块的建构者的不匹配的假设。 Wirth提出的自上往下、逐步求精的设计方式可以有效避免许多漏洞。组件测试的方法有联机测试、内存拷贝、快照、交互式测试等方法。系统测试往往要比我们期待的要花更多的时间。系统测试也更加艰难。我们应该应该使用各组件能正常工作时再进行系统测试(而不是将许多有Bug的组件组合起来测试,即使这些 Bug是已知的),另外在进行系统测试时一次只加一个组件,如果你一次加多个组件,你将难以判断一个新的Bug的来源。

  要保证一个项目的进度被大幅度推迟,制订进度表很重要。进度表由里程碑和完成的时间组成。里程碑必须具体、明确、可界定。某一里程碑要么到达,要么没有到达,不应该是80%到达的。一个程序员对于明确的里程碑是很少说谎的,如果里程碑很明显,他不能欺骗自己。长期的计划拖延是士气杀手,如果你错过一个限期,确保你在下一个限期按时完成。对于老板,当然应该把握工程的进度,但是他不应该随意行动。对于经理能够处理的问题,他不应该采取行动。小的计划和控制组可能是一个控制项目进度很好的看门狗。

  软件的文档是与机器同样重要的,即使是对于极其私人的程序,说明文档也是必须的。不应该由于进度压力等任何原因忽视文档的编写。绝大多数的文档失于概述部分过于简略。程序的概述应包括目的、运行环境、输入输出的范围、函数和应用的算法、输入输出格式、操作指令、选项、运行时间、准确性。修改一段程序也需要有一段概述,应包括流程图或者子程序结构图、详细的算法描述、所有文件的说明、通过结构的概述以及对最初设计进行更改的原因的说明。传统的用流程图说明程序的方式基本已经过时,因为如果流程图超过一页,将变得极其难懂。在源代码中嵌入说明的自说明文档方式是很好的改进。使用自说明文档的方式应注意以下几点:使用程序名和变量名携带更多的文档信息;使用空间和格式来显示子程序、嵌套,增强可读性;插入必要的段落说明,尤其是在模块的开头;另外在多说明使用的原因,而不是仅仅是怎样使用,因为动机是理解的关键。

  本书是二十周年纪念版在最后加了作者在1986年写的经典文章《没有银弹》。主要观点是:软件实体是一个许多概念交织的建筑:数据集、数据项的关系、算法以及引用函数。其本质是抽象的,概念架构在许多不同的表示方式下是一样的。编写软件最困难的部分是规范、设计和测试这种概念架构,而不是表式他的劳动和测试这一表示的可靠性。现代软件系统存在的内在的不可减少的特性有:复杂性(Complexity)、遵守随机的复杂的规范(Conformity)、易变性(Changeability)和不可见性(Invisibility)。高级语言、分时系统、统一编程环境、面向对象编程、人工智能、专家系统、自动化编程、图形化编程都只是解决了编程偶然的困难,而不能解决编程的内在困难。

  附注:2007年写的读书笔记,现在把它转帖到Douban来

评价:

[匿名评论]登录注册

评论加载中……