人月神话(英文版)
2推荐 收藏
6.5K阅读
图灵程序设计丛书

人月神话(英文版)

Frederick P.Brooks , Jr. (作者)
终止销售
  本书内容源于作者Brooks 在IBM 公司任System/360 计算机系列以及其庞大的软件系统OS/360 项目经理时的实践经验。在本书中,Brooks 为人们管理复杂项目提供了最具洞察力的见解,既有很多发人深省的观点,又有大量软件工程的实践,为每个复杂项目的管理者给出了自己的真知灼见。
  大型编程项目深受由于人力划分产生的管理问题的困扰,保持产品本身的概念完整性是一个至关重要的需求。本书探索了达成一致性的困难和解决的方法,并探讨了软件工程管理的其他方面。本书适合任何软件开发行业的从业人员阅读,对软件开发人员、软件项目经理、系统分析师更是必读之作。
纸质书
¥29.00

其他购买方式?

出版信息

  • 书  名人月神话(英文版)
  • 系列书名图灵程序设计丛书
  • 执行编辑关于本书的内容有任何问题,请联系 傅志红
  • 出版日期2010-07-20
  • 书  号978-7-115-23268-7
  • 定  价29.00 元
  • 页  数336
  • 开  本16开
  • 出版状态终止销售
  • 原书名The Mythical Man-Month
  • 原书号978-0-201-83595-3

同系列书

  • JavaScript高级程序设计(第4版)

    [美]马特·弗里斯比(Matt Frisbie)   李松峰   译

    本书是JavaScript经典图书的新版。第4版涵盖ECMAScript 2019,全面、深入地介绍了Java...

  • HTTP权威指南

    David Gourley   Brian Totty   Marjorie Sayer   Sailu Reddy   Anshu Aggarwal   陈涓   赵振平   译

    本书是HTTP及其相关核心Web技术方面的权威著作,主要介绍了Web应用程序是如何工作的,核心的因特网协议如何...

  • JavaScript高级程序设计(第3版)

    Nicholas C.Zakas   李松峰   曹力   译

    本书是JavaScript超级畅销书的新版。ECMAScript 5 和HTML5在标准之争中双双胜出,使大量...

  • 计算机科学的基础

    Al Aho   Jeff Ullman   傅尔也   译

    本书全面而详细地阐述了计算机科学的理论基础,从抽象概念的机械化到各种数据模型的建立,用算法、数据抽象等核心思想...

  • Java技术手册(第6版)

    Benjamin J Evans   David Flanagan   安道   译

    通过学习本书,你将能够: 掌握最新的语言细节,包括Java 8的变化 使用基本的Java句法学习面向对...

本书特色

图灵奖得主总结软件项目实战得失
软件工程领域35年畅销不衰的经典
软件从业人员不可不读的宝书

目录

Contents
Chapter 1 The Tar Pit 3
Chapter 2 The Mythical Man-Month 13
Chapter 3 The Surgical Team 29
Chapter 4 Aristocracy, Democracy, and System Design 41
Chapter 5 The Second-System Effect 53
Chapter 6 Passing the Word 61
Chapter 7 Why Did the Tower of Babel Fail? 73
Chapter 8 Calling the Shot 87
Chapter 9 Ten Pounds in a Five-Pound Sack 97
Chapter 10 The Documentary Hypothesis 107
Chapter 11 Plan to Throw One Away 115
Chapter 12 Sharp Tools 127
Chapter 13 The Whole and the Parts 141
Chapter 14 Hatching a Catastrophe 153
Chapter 15 The Other Face 163
Chapter 16 No Silver Bullet—Essence and Accident 177
Chapter 17 "No Silver Bullet" Retired 205
Chapter 18 Propositions of The Mythical Man-Month: True or False? 227
Chapter 19 The Mythical Man-Month after 20 Years 251
Epilogue 291
Notes and References 293
Index 309

相关文章

  • 杜小豆 10推荐

    私以为可以提高程序员技术档次的书和博客

    为什么中国的程序员总是在不断学习新的开发工具、钻研程序代码,而不逐步提升自己的视野、思维和经验? **(注意:本文阅读量在2016.08.26日正常的为150+左右,为了测试阅读量的不合理计算方法,我写了一个小程序将其刷到了2056。关于阅读量的不合理计算方式的bug,已…...

  • 转自:豆瓣 作者:铂程斋@喷嚏网
    作为软件工程的经典著作,《人月神话》的主要贡献是对软件开发过程的几个重要关键点,提出了独到的见解。
      
       这几个关键内容就是:
      (1)提倡外科手术式的团队组织:
       [在软件开发组织上的过份民主,往往带来的是没有效率和责任,参与其中的人想法太多,层面参差不齐。所以,软件开发的组织,应该借鉴外科手术式的团队方式,有一个主要的负责人,其他人都是分工协作的副手,这样效率最好,结果最好。]
      (2)软件项目的核心概念要由很少的人来完成,以保证概念的完整性:
       [少就是多,项目的定位需要和功能多少的权衡。太多的想法,使项目没有焦点,什么都要放进去,结果什么都做不象;]
      (3)软件开发过程中必要的沟通手段;
       [ 软件开发中最大的风险往往不是技术的缺陷,而是缺少沟通;]
      (4)如何保持适度的文档:
      [ 在开发中,保持适度的文档。喜欢过度多的文档的人,忘记了文档不是最终的产品,不是用户需要的,最后以为文档好,就是好的开发,其实完全不是。]
      (5)在软件开发的过程中,只有适度改进,没有包治百病的银弹。
      [在软件开发的过程中,重要的不是采用了什么工具,而是不论用何种工具,都要达到项目本身的客户需求。任何方法论之前,先要探求问题的来源,否则,对各种方法论的依赖或滥用,有害无益。
    熊猫夜未眠  发表于 2011-09-08 15:15:12
    推荐
  • 转自:豆瓣 作者:pythia
    000年新年伊始,国际计算机协会 (ACM)在纽约宣布1999年图灵奖得主为时年69岁的布鲁克斯(Frederick P. Brooks, Jr.)。评选委员会主席在致辞中提到,“今天我们所看到的计算机体系结构、软件工程,以及三维计算机图形,均受惠于布鲁克斯的开创性工作,是他改变了这 些领域的面貌。”布鲁克斯确实是一位在计算机科学各方面均作出杰出贡献的奠基者。然而,他最广为人知的功绩则是在软件工程领域的重要经典著作――《人月神 话》,可以说正是此书让软件工程学进入人们的视野。
      
      大学期间曾主修物理的布鲁克斯,1956年从哈佛大学获得计算机博士学位。毕业后他加入IBM公司,在著名的Stretch和Harvest 计算机体系结构设计中建树良多,其中包括著名的中断处理系统。上世纪60年代,他主持了IBM 360系列计算机及其操作系统 OS/360的开发,本书所谈到的经验,很多便来自他的这些项目经历。
      
      三十年来计算机技术的发展迅捷无伦,然而《人月神话》一直畅行不衰。自1975年第一版发行以来,直到1995年还保持着稳定的销量,成为软 件工程领域引用率最高的著作之一,在普通读者和学术圈内都备受关注。1995年Addison-Wesley出版社推出二十周年纪念版,又是一时洛阳纸 贵。在这个计算机这个日新月异的领域中,这样长盛不衰的书籍不能不说是凤毛麟角。《人月神话》的魅力并不因为技术的更新换代而黯淡,相反在纷繁多变的世代 中,验证了自己的价值――固然计算机技术的变迁之快令人瞻望无及,然而技术并非《人月神话》的着眼点,它更关注的是软件的创造过程、需求的变化无常和管理 的永恒困境,《人月神话》中的思想超越了具体的时代和技术。
      
      今天的软件从业人员,或许比三十年前的前辈们,能更深地体味到布鲁克斯在本书中的思虑――三十年来的技术发展,使计算机从高深莫测的象牙塔进 入了寻常百姓案头,计算机硬件领域那些曾经的天堑化为通途,然而与此同时,布鲁克斯法则(Brooks’ Law),渐渐成为软件界耳熟能详的术语,大型软件项目的“焦油坑”危机,依然如幽灵般徘徊,布鲁克斯在三十年前写下的这些随笔,怎能不让我们深省?
      
      在写作风格上,《人月神话》也足以垂范后世。图灵奖评选委员会曾经特意提到,布鲁克斯不仅为计算机技术做出了杰出的贡献,他也是一位修养全面 的学者。《人月神话》并非一份枯燥的技术文献,而是一系列文采斐然的随笔――布鲁克斯对文学和艺术涉猎颇广,他敏锐的思维和渊博的学识,使他在表述软件工 程思想时,能从人文和其他工程领域信手拈来旁证博引,深得触类旁通之妙。从英语写作的角度上说,《人月神话》具备随笔体睿智而典雅的风貌,行云流水间文思 严谨。读者不必象阅读常见的技术手册一样正襟危坐在工作台前研读,倒是可以在旅途之中,工作之暇轻松地开卷有益,领略精纯的文笔、睿智的思索。
      
      没有译者敢于声明自己的译文保留了《人月神话》的全貌,能象原著一样,让技术和人文炉火纯青地交相辉映。在保持技术准确的同时兼备原文流畅典 雅的神韵,并非易事。美国文艺评论家苏珊.桑格塔曾说过,“翻译等于一次死亡”。《人月神话》在装帧排版上也颇具匠心,这些特色使《人月神话》在诸多计算 机专业书籍中具备了卓尔不群的优雅风范,甚至于后来软件工程领域的随笔集,颇有不少效颦于《人月神话》者。基于这些原因,力所能及的读者,应以阅读原版为 佳。只有这样不致于因为不完美的译文而错失精华。
      
      《人月神话》毕竟是三十年前出版的作品,文中谈到的许多技术,固然在历史上赫赫有名,但在今天的读者看来未免陌生,注释者拣选其中的一些术语加以说明。
      另外,布鲁克斯引用的人文著作和艺术隐喻,虽然在美国读者中耳熟能详,颇有趣味和启示意义,然而中国读者可能未必熟悉,我们也加以注释。
      
      更重要的是,正如布鲁克斯在《人月神话》中所倡导的“唯一不变的是变化本身”,人们只有在变化中才能体味永恒。作者在本书出版后不断根据技术 的变化对本书中的观点进行审视和修订。如今距《人月神话二十周年纪念版》发行也已过去10年,在这10年中互联网技术的奇迹发展,使计算机越来越深入地渗 透到普通人的日常应用中,软件工程领域的研究也非常活跃。我们在注释中有意识地提到这10年来技术的沿革以及最新的进展。以期读者能将目光延伸到当前乃至 未来――相信这也是《人月神话》的本意。
      
      为这样的英文经典之作提供注释版本,无论对注释者来说还是一种尝试。注释者力图提供更丰富的背景知识和旁敲侧击的解说,以便读者在一睹原文全 貌的同时,能在更开放的上下文中体味原文的精粹。布鲁克斯在书中谈到,计算机从业人员多是乐观主义者,这固然是由于这个行业朝气蓬勃令人振奋,更常见的缘 故是我们常把目光局限在自己的所知领域内,一厢情愿地认为万事具备。布鲁克斯常在一片盲目乐观的欢快气氛中,通过周全的调查,冷静的思考,提出自己的怀 疑,匡正可能出现的危机。正如他自称的“怀疑并不等同于悲观主义”,也正如他在《人月二十周年纪念版》最后一章末尾引用的圣经箴言:“上帝阻挡骄傲的人, 赐恩给谦卑的人。”《人月神话》的宗旨并非提供确定的断言,而是提出省问和启发,在这个充满活力的技术领域中,引导人们思考。故而读者在阅读本书时,也当 结合时代和自己的经验,博学审问,慎思明辨。
      
      1975年本书初版,之前不久,计算机工程师还在用紫色电线标出错误线路,程序员还在为获得几个小时的终端使用权而欣喜若狂,如今想来恍若隔 世,对于《人月神话》谈到的过去的技术窘迫,读者不应傲慢嘲笑,书中记述的前辈们在解决这些窘迫所体现的才智和热情,则是永远值得后人借鉴的,也将启迪我 们开拓未来之路。海德格尔曾说,“人类探索之路错综纷杂,只有向后之路才能指引我们向前。”
      
      谨以此向布鲁克斯致敬。
      
      2006年10月30日于北京
    熊猫夜未眠  发表于 2011-09-08 15:15:39
    推荐
  • 转自:豆瓣 作者:老好人
    《人月神话》是软件工程方面的一本经典著 作,其作者布鲁克斯(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)。高级语言、分时系统、统一编程环境、面向对象编程、人工智能、专家系统、自动 化编程、图形化编程都只是解决了编程偶然的困难,而不能解决编程的内在困难。
    熊猫夜未眠  发表于 2011-09-08 15:16:29
    推荐
  • 转自:豆瓣 作者:心在荒野
    刚刚看完《人月神话》,看书的时候常常联想到我们日常工作中的种种现象。原来人家早在三十年前的时候就已经碰到过,并且有了如此深入的思考。
      
      IT行业的高速发展,软件本身难以克服的复杂性,软件的组件化、服务化,以及软件技术的爆炸、软件市场的细分,作为软件最终缔造者的“程序 员”将越来越成为一个普通“民工”或者“螺丝钉”又或者是“流水线上的一环”。我们投入这个行业初期的那么一丁点优越感,以及被对技术的那么一点狂热都将 渐渐被时间榨干。工作,渐渐退去光辉,露出它狰狞的本来面目。是的,我们正迷茫着。迷茫包括 IT 本身,包括我们自己的职业发展。路在何方呢?
      
      所以说,也许最有价值的观点是,当我们的行业已经成熟到一定程度,当工作已经不再有任何创造性时,我们是否应当转变自己的工作角色,我们是否应当做到“随需应变”,还是坚定的转型:项目管理、或者纯粹的设计师。
      
      对于设计师这样的职业,我充满好感。它充分保留了“创造性”,“创意”,“新鲜感”等特性,另外“经验”也是非常重要的,同时他还能给自己一点点“成就感”。
      
      《人月神话》确实是一部每一个 IT 人员应该读几遍的好书。虽然他描述的工程项目是系统级的基础软件,而基础软件开发对于我们现在的程序员来说,也是一个神话。我想,我会再读上几遍,并掩卷深思。
    熊猫夜未眠  发表于 2011-09-08 15:17:01
    推荐
  • 转自:豆瓣 作者:yuqiang
    刚刚看完《人月神话》,因为工作的原因开始涉及到一些软件管理方面的内容,虽然规模很小但是也是颇有启发。看下来几点想法:
      
      1。项目小组人员尽量精简,
      
      2。开发前完整的架构和文档,及接口定义
      
      3。管理者数目为一个或者两个
      
      4。作为使用者,尽量购买现成的软件,因为开发及调试成本并非你所可以承受的, 这点从之前实验室开发过的管理系统,以及最早试图开发的erp系统有深刻的体会,以个人来说改变自身行为模式或者是去一个小组改变流程适应已有的软件,或 者再商业软件上做二次小开发,结果和成本都好很多。
      
      5。作为开发者,尽量开发和利用现有架构:
      
       1。利用免费或者收费的各种开发包,注意和开发包和软件的接口,提高封装程度,
       2。做好架构,使得软件是一个可添加的结构,将软件做成模块化,可以添加的结构,尽量延长软件寿命,增加其价值。
      
      这是一些感受,另外就是了解了整体软件开发的架构,流程,各个部分时间的安排,你应该如何去做。其实这种方式可以推而广之的到所有产品所有开发上去。
      
      客户的复杂程度,大大增加了个性化软件的可为之处。简约,复杂像长尾理论所说的一切都有人喜欢。
      
      另:结尾把所有重要点,再次提点,对于一本列举了很多概念的软件工程书,很好的帮读者再过了一遍整本书的内容。
    熊猫夜未眠  发表于 2011-09-08 15:17:28
    推荐