现在位置: 首页 > 人物 > 正文

没有银弹&人月神话

2013年12月07日 暂无评论 ⁄ 被围观 (浏览总计: 707 次)+
弗雷德里克·布鲁克斯 Frederick P. Brooks, Jr.

弗雷德里克·布鲁克斯
Frederick P. Brooks, Jr.

本文根据百度百科维基百科整理而成。

佛瑞德·菲利普斯·布鲁克斯二世(Frederick Phillips Brooks, Jr.,1931年4月19日-),又译为弗雷德里克·布鲁克斯,生于美国北卡罗来纳州德罕,软件工程师、学者,曾任IBM公司系统部主任,主持开发过OS/360等大型计算机用的操作系统软件。后来,布鲁克斯离开IBM公司,任教于北卡罗莱纳大学教堂山分校,担任计算机科学Kenan讲座教授,并著书立说。为1999年图灵奖得主。

或许很多人对布鲁克斯这个名字很陌生,但对他的著作《人月神话》一定有所耳闻。他的著作主要有:

(1)没有银弹(No Silver Bullet: Essence and Accidents of Software Engineering),一篇论文
(2)人月神话(The Mythical Man-Month: Essays on Software Engineering),1975年初版
(3)再论人月神话(The Mythical Man-Month: Revised Essays on Software Engineering),1995年纪念版
(4)设计的设计:一位计算机科学家的设计历险(The Design of Design: Essays from a Computer Scientist)

其中《没有银弹》和《人月神话》在软件工程领域影响很大,经常有人介绍一个东东,然后加一句“没有银弹”,是嘛意思?请看下文。

1.《没有银弹》

《没有银弹:软件工程的本质性与附属性工作》(No Silver Bullet — Essence and Accidents of Software Engineering),原先是在1986年都柏林IFIP研讨会的一篇受邀论文,隔年电机电子工程师学会《Computer》也转载了这篇文章,他们用了几张《伦敦狼人(The Werewolf of London)》之类的电影剧照来当作说明,还加上了一段〈终结狼人〉的附注,用来引出非银弹则不能成功的(现代)传说。该论述中强调由于软件的复杂性本质,而使真正的银弹并不存在;所谓的没有银弹是指没有任何一项技术或方法可使软件工程的生产力在十年内提高十倍。

这篇经典论文的核心论述通常被解释为复杂的软件工程问题无法靠简单的答案来解决。

次要和必要复杂度

在该论述当中,讨论到了次要和必要复杂度的差异。所谓次要复杂度是指由人们本身所产生的问题,而这类型的问题是可以被解决的。譬如说,撰写和最佳化组合语言的复杂度就是属于次要的,它可以借由高阶程序语言如Java来取代。必要复杂度则是从软件本身要解决的问题衍生而来,并无法被移除。如果软件需要提供三十个不同的功能,那么这三十个功能都是必要的,这些功能都必须被实作出来。

软件工程面临的问题在于我们已经清除了大部分的次要复杂度,而剩余的(主要复杂度)都无法改变。

在移除次要复杂度中最大的进展也许要算是高阶语言的诞生,像是Fortran和Java。

在欧洲中世纪的传说中,有一种叫“人狼”的妖怪,就是人面狼身。它们会讲人话,专在月圆之夜去袭击人类。而且传说中对“人狼”用一般的枪弹是不起作用的,普通子弹都伤不到也打不死它,只有一种用银子作成的特殊子弹才能把它杀死。Brooks在他最著名的随笔文章《No Silver Bullet》里引用了这个典故 ,说明在软件开发过程里是没有万能的终杀性武器的,只有各种方法综合运用,才是解决之道。而各种声称如何如何神奇的理论或方法,都不是能杀死“软件危机”这头人狼的银弹。他当时大胆声称并预言方法学家们10年之内绝找不到什么极好的的神奇银弹。他的文章发表后,被广泛引用,后来他的随笔结集成书,就是《人月神话》。从此,在软件界,银弹(Silver Bullet)成了一个通用的比拟流行开来。

在今天看来,没有银弹当时所指的“没有任何一项技术或方法可使软件工程的生产力在十年内提高十倍”这个预测是否正确已不重要,重要的是它的寓意:软件开发和管理不能一味追究走捷径,很多时候银弹是不存在的,还是得靠按部就班、不辞劳苦而获得成功。

2.《人月神话》

《人月神话:软件项目管理之道》(The Mythical Man-Month: Essays on Software Engineering),全书讲解软件工程、项目管理相关课题,被誉为软件领域的圣经,内容源于作者布鲁克斯在IBM公司System/360家族和OS/360中的项目管理经验。该书于1975年首次发行,并于1995年重新发行纪念版,其中新增了对〈没有银弹〉一文的评论和回应,与4个额外的新章节。在软件领域,很少能有像《人月神话》一样具有深远影响力和畅销不衰的著作。该书英文原版一经面世,即引起业内人士的强烈反响,后又译为德、法、日、俄、中、韩等多种文字,全球销售数百万册。确立了其在行业内的经典地位。《人月神话(英文版)》适合任何软件开发行业的从业人员阅读,对软件开发人员、软件项目经理、系统分析师更是必读之作。

主要内容如下:

人月神话(The mythical man-month)

这部分讲述人力(man)和时间(month)并不呈现线性关系。指出以大量人员和较短的时间,并不能缩短软件的开发进度。一窝蜂的作业方式无助于软件生产,且会制造麻烦,产生出更差的软件。向进度落后的项目追加人力,只会使进度更加落后。因为新进的人员需要时间了解整个项目,而增加额外的沟通消耗。

用“人月”来衡量工作规模的大小是危险的,也是一个容易遭到误解的迷思,使用人月的前提必须是在人力和工时可以互换的情况之下:当一份工作因具有连续性的限制而不可切分时,就算投入再多的人力,也不会对时程有所影响,生小孩就是需要九个月,你叫多少个妈一起生都一样,软件工程就是像这样的工作,因为它必须除错,而除错本身就具有连续性的本质。

人月(man-month)

指的是“一个人要花几个月”才能完成软件开发的单位,通常用来评估一件软件项目的大小。以成本会计(cost accounting)为基础的时程预估技术,使我们误把工作量和项目进度混为一谈,人月是个危险并很容易就遭到误解的迷思(myth),因为它假设人力和工时可以互换。

Brooks法则

在一个时程已经落后的软件项目中增加人手,只会让它更加落后。根据Brooks法则,增加人员到一个已经延误的项目里,等于是火上加油。除非你可以把工作区分,让新进人员可在不影响他人工作的状况下有所贡献。

把工作切分给更多人做将造成额外的沟通(communication)代价——训练和相互的交流(intercommunication)。欲增加软件项目的人手,总共必须付出的代价可分为三方面:工作重新切分本身所造成的混乱与额外工作量、新进人员的训练、新增加的相互交流。

外科手术团队

在接受相同的训练、同样都是两年资历的情况下,优秀专业程序员的生产力要比差劲的程序员好上十倍。短小精悍团队是最棒的——尽可能用最少的人。两人团队,其中一人当领导者,这通常是最佳的用人方式。以短小精悍团队开发真正大的系统就太慢了。绝大多数大型软件系统的经验显示,使用一堆人蛮干的方式最耗成本、最慢、最没有效率,做出来的系统在概念上也最不完整。

以一位首席程序员为主、类似于外科手术团队的组织提供了一个良方,既可因少数人的决策而兼顾到产品的整体性,又可因多数人的合作与大幅沟通减少而得到全部人的生产力。

专制、民主与系统设计

(1)在系统设计时,保有概念整体性(conceptual integrity)是最重要的原则。
(2)功能概念复杂度比(这个比值是为了量测使用便利性,对简单和困难的运用都很有效)才是系统设计的最终测试标准。功能多,不见得是好事。
(3)要达成概念整体性,设计必须出自于一个人的想法,或是极少数人的一致决定。
(4)对大型软件项目(小项目也一样)来说,将架构设计独立于实现之外是取得概念整体性强而有利的方法。
(5)如果系统必须保有概念上的整体性,那么就必须有人来控制这些概念,这就是需要专制的原因,无庸置疑。
(6)许多软件架构、实现、实现的工作都是可以同时进行的。(不论硬件或软件设计,都可以同时进行)

第二系统效应(The second-system effect)

就一个人所做过的设计而言,第二个系统是最危险的系统,一般来说,都倾向于过度设计。

当他做第三或之后的系统时,之前的经验会互相印证,以确认出这类系统的一般性特色,而系统彼此之间的不同处,也会帮助他辨别出属于特殊和非通用的部份。除了做些功能上的修饰之外,第二系统效应还有另外一项特征,那就是倾向于将之前已熟悉的技术发挥到淋漓尽致,但却没有留意到,这项技术早就跟目前项目的基本系统假设有冲突而不再适用,OS/360有好多这样的例子。(Windows NT则似乎是1990年代的示例)

对大部份OS/360的设计人员来说,它也是个第二系统,设计成员分别来自1410-7010磁盘操作系统、Stretch操作系统、Project Mercury实时系统、给7090用的IBSYS操作系统等等,几乎没有人拥有两个上述系统的发展经验,所以OS/360可称得上是一个最佳的第二系统效应示例。

项目工作手册

手册或书面规格是不可或缺的工具,虽然光靠它是不够的。手册载明的是产品的外部(external)规格,用来描述并制定出用户从外观上将或看到的所有细节,撰写手册便是架构设计师的主要工作。当用户和实现人员的反应不断地显示出设计上难以使用或实现之处,手册就会堕入重新准备、修改的轮回之中。为了造福实现人员,将修改的程度予以量化(quantize)是很重要的——在时程上应该要有载明日期的版本信息。

软件需求

失败的软件项目经常发生在开发者与用户间对需求认知的误解。开发者抱怨用户说不清楚需求,而用户抱怨开发者误解他们的意思。布鲁克斯认为“软件开发最困难的单一项目,是精确地决定要建造什么。

二十周年纪念版

增修内容:

1.将初版中所主张的所有论断整理出一个简洁的摘要,包括了原书的主要理念:就人力配置的比例而言,大型软件项目所面临的是跟小型项目完全不同的管理问题,这引申出产品的概念整体性是其中的关键,而达成概念整体性虽然困难,但却是可能办到的。
2.作者佛瑞德·布鲁克斯对他当初所提出的这些论断,在经过一个世代之后所做的观察。
3.转载布鲁克斯1986年发表于IEEE《Computer》的经典论文〈没有银弹〉。
4.布鲁克斯对于他1986年的论断“十年内不会有任何银弹”所做的回应。
  打分:5.0/5 (共2人投票)

给我留言