`
ruilin215
  • 浏览: 1097219 次
  • 性别: Icon_minigender_2
  • 来自: 成都
文章分类
社区版块
存档分类
最新评论

杀不死的人狼——我读《人月神话》(三)

阅读更多

<<==上一节

=====

三、《人月神话》是预言了未来还是控制了未来?
=====
事实是:我们现在的很多工程知识,——无论是从书上看到的,还是从实践中体验到的——大多未曾脱离《人月神话》之所言。
我在开篇中说《人月神话》“是一本可怕的书”。然而我认为真正的可怕之处在于:如今只要论及工程(且不要让人认为是离经叛道),那么所讲述的一定是Brooks的这样的经验以及由此推出的观点,或者在不违背这些经验和观点上的一些具体的实作方法!我们全然不顾书中所言是现象,还是本质的推论,或者只是现象归结的一个(未必正确的)答案。尽管这些答案大多数时候都如同预期地出现在你的现实工程中:
原文
基本含义
现实
规格说明的风格必须清晰、完整和准确。用户常常会单独提到某个定义,所以每条说明都必须重复所有的基本要素,所以所有文字都要相互一致。这往往使手册读起来枯燥乏味,但是精确比生动更加重要。(P46)
重复所有基本要素,以便于单个的特性可能会被抽离出来进行讨论。
RUP
将来的规格说明同时包括形式化和记叙性定义两种方式。(P46)
用形式化来精确定义,用记叙性定义来被充说明。
UML
使用实现来作为一种定义的方式有一些优点……(但)可能更加过度地规定了外部功能。(P47)
陈述实现并不是设计中规定外部功能的方法。
UserCase不应指示或暗示实现的方法。
对软件系统的体系结构师而言,存在一种更加可爱的方法来分发和强制定义。对于建立模块间接口语法,而非语义时,它特别有用……(P48)
寻求一种描述功能而不涉及实现的方法,来协助架构师陈述它们的设计。
Interface
项目工作手册不是独立的一篇文档,它是对项目必须产出的一系列文档进行组织的一种结构。项目所有的文档都必须是该结构的一部分……(P54)
项目工作手册应当有组织、有结构地陈述项目各个方面的细节。
RUP
笨拙的文字归档工作确保了所有变更会被阅读,这正是工作手册要达到的目的。(P56)
确保变更不会丢失。
需求管理系统或任务管理系统
是因为控制序更加复杂,所以需要更多的人员?或者因为它们被分派了过多的人员,所以要求有更多的模块?是因为复杂程度非常高,还是分配较多的人员,导致花费了更长的时间?没有人可以确定……(P64)
随时关注生产率并控制它。
项目管理软件
但是只有书面计划是精确和可以沟通的。计划中包括了时间、地点、人物、做什么、资金……(P75)
以书面化的形式来制定计划,并且确保一些要素的准确性。
项目管理软件
试验性的系统必须被构建然后丢弃……(P77)
做一个原型并准备好扔掉它。
原型过程
目标上的一些变化无可避免,事先为它们做准备总比假设它们不会出现要好得多。不但目标上的变化不可避免,而且设计策略和技术上的变化也不可避免……(P77)
为变化而做出设计。
延长设计和迭代的周期。风险评估。
流程图是被吹捧得最过分的一种程序文档。事实上,很多程序甚至不需要流程图,很少有程序需要一页纸以上的流程图。 (P107)
编程的结果产生流程图(以供讨论和分析),而不是对照着流程图进行编程。
编程的结果产生流程图(以供讨论和分析),而不是对照着流程图进行编程。
试图把信息放在不同的文件中,并努力维持它们之间的同步,是一种非常费力不讨好的事情……(P108)
文档应该与代码同步。
代码文档化。
没有银弹(P114)
所有曾被认为是银弹的东西都无情地否定了。
原文中还有许多类似的观点、现象和答案,都成为了现实工程中的既存现象。先民们所说的圣人以及通神者,皆因他们多数时候在正确地预言自己的现实。只有当这个“多数时候”变成少数的时候,先民们才会置疑圣人和通神者的能力。其实我们知道并没有预言未来的人,大多数时候是两种情形导致的假象:
  • 他做出了正确的判断;
  • 你主观地跟从了他对未来的设定。
后者是危险的。大师们预言了未来也就改变了未来,即便未来未必“应当”如同他所预言的那样。
但如果这种预言的前提不正确,那么未来必然脱离这种影响而回到它应该的状态上去。如同我们看到的另一些事实一样,有很多现象表明,我们正在回归工程本相的道路上摸索前进。我们也发现,在大多数情况下,先哲们的预言在实践中被印证着,只是偶尔“不太灵光”。下表则列出一些不同的例子:
Brooks所述相同的例子
不同的例子
UML
AP:可以工作的软件重于求全责备的文档。
1
Interface
RUP
需求管理系统/任务系统
代码走查,结对编程。
AP:人和交互重于过程和工具。
AP:客户合作重于合同谈判。
项目管理软件
质量管理/评估和工程化测量
User Case要尽可能避免指示或暗示实现的方法
测试驱动从一开始就规定表现是什么,以及如何确认它。
原型过程
迭代过程
2
延长设计和迭代的周期
缩短周期使得变化来不及发生。
编程的结果产生流程图(以供讨论和分析),而不是对照着流程图进行编程。
不强调具体代码实现方法的、设计过程中的流程图例。例如时序图。
3
代码文档化。
通过工具来使代码与文档同步维护。
所有曾被认为是银弹的东西都无情地否定了。
我们还是有成功的工程实践的。
1:我例举了敏捷的一些观点,并不表明我是AP/XPfansAP/XP的问题另论,在这里,我只是说明存在一种不同的思想。
2Brooks后来承认“必须扔弃原型”是一个不太正确的观点。
3Brooks在这里没有犯错误,只是他所讨论的是狭义的流程图,而我们例举的时序图则更广义。
我们回顾上一小节,在《人月神话》中的那“31%的答案”的前提——也就是那7%的本质中,如下两项是明显存疑的(也是主要置疑):
  • 目标的本质:是大型工程,是系统项目,而不是程序
  • 个体的本质:是私利性的
其实早就有人意识到个体的本质“未必全是私利的”,尊重这些个体就会带来一些效果。例如AP正是因为更尊重开发人员的个性与能力,以及相互间的合作而得到了效率的提升。
再进一步地说,既然Brooks设定了“大型工程或系统项目”这样的目标,并给出了一些答案。那么在“小那么一点点的”工程项目中,是不是这些答案就不必须了呢?例如Brooks的许多建议,对于某些目标——例如你要用为期三个月的时间开发一个的产品——就并不是很有效;或者根本无法实施——例如你的团队总共只有6个人,连“外科手术式的团队”都组织不起来。
Brooks的答案对于同样的目标,以及在他所述的“本质”未能发生改变时,还是比较有效(或有实施的可能性)。因此上述一些例外,总是在上述的“7%的本质”被否定或被改变的情况下获得的。因而我们提出的问题是“如何否定或改变”这些难以撼动的本质。然而在我看来,Brooks早已经在最佳位置上,给出了撬动它们的一个支点:
  • Brooks认为构建“独立小型程序”与“编程系统产品”是不同的问题。
Brooks讨论的编程系统产品的规模到底有多大呢?我想至少应该是以IBM 360为参考的。不过书中在引用Joel AronIBM在马里兰州盖兹堡的系统技术主管)的例子时说,“大型意味着程序员的数目超过25人,将近30,000行的指令”。而按照《人月神话》的数据:人均效率800指令/人年,则这个“大型项目”应该需要1.5年才能完成。此外,还需要大约一倍的人工,来负责除开代码之外的测试、管理、文档和沟通等工作。
好的,如果你有一个“(至少)50人,开发一年半”的项目,那么你可以先接受Brooks的答案去实践一下:起码你可以有时间来讨论工程问题,也能够组建那样规模的团队。但是,难道只有这样的“大型工程”才算得工程,而“小那么一点点”的就不算吗?现实是,我们一方面在做着“小那么一点点的”工程项目,另一方面在听着整个业界喧嚣着“为更大规模的工程”而准备的工程理论。我们总在实践Brooks的“答案”或者“预言”,而忘却这些答案的前提:
  • Brooks的经验源自对IBM 360等大型项目的实践与分析;
  • Brooks所述的工程是要得到编程系统产品;
  • Brooks认为编程系统产品的工作量可能是独立小型程序的9倍(在实现大致相同功能的情况下)。
事实上我们现在的软件工程的发展是被驾驭了,而不是被预言了。从本质上来说,Brooks在《人月神话》中只是讨论了大型工程的实施,以及相应规模下的团队建设。而我们,便按照这样的设定来铺开了整个软件行业的工程化实施。
促成这种现状的,并不仅仅是一本书的力量,还在于商业的力量。因为只有在这样铺展开来的行业环境中,才可能有商业机会。——即使那些工程顾问与实施专家从来没有实施过“50人,开发一年半”这样的项目,只要他们能报出Brooks的名字,能谈及某些工具在应对“大型项目”中的成功经验,他们就已经成功了一半了。
为什么“敏捷”之初颇受争议?为什么敏捷对一些中小型的团队显得有效和可实施?为什么当这些争议被摆在眼前的成功平息之后,传统工程的理论家们却不忘恨恨地评上一句:那是一种不能(或难以)应用于大型工程的方法呢?!
因为如果大家都很“敏捷”,都只做比这些大型工程“小那么一点点”的工程,那么传统工程的专家们就失业了。反过来,只有把工程做大,大到“敏捷”失去了意义,而“庞大”变成了实质的时候,传统工程就可以为任何失败找到借口:看啊,Brooks就说过“没有银弹”嘛。

下一节==>>

分享到:
评论

相关推荐

    《人月神话》布鲁克斯.扫描版.pdf

    人月神话(THE MYTHICAL MAN-MONTH)...........................................................................6 乐观主义....................................................................................

    人月神话 pdf

    人月神话(THE MYTHICAL MAN-MONTH)...........................................................................6 乐观主义....................................................................................

    人月神话高清版

    - 电话日志.....................................................................................................................................38 产品测试.................................................

    变形金刚人物图片档案集——博派.exe

    变形金刚人物图片档案集——博派.exe &lt;br&gt;擎天柱 火车模式 爵士 爵士pretender 千斤顶 铁皮 救护车 警车 蓝霹雳 探长 开路先锋 幻影 飞毛腿 横炮 红色警报 轮胎 烟幕 消防车 吊车 滑车 刹车 飞过山 ...

    人狼羊菜渡河问题(含Matlab程序).doc

    人狼羊菜渡河问题(含Matlab程序).doc

    人狼大战 java源代码

    人狼大战 java源代码,功能丰富,界面美观,特别推荐一看

    人狼羊菜过河程序JAVA

    编译原理中人狼羊菜过河通过java语言实现的程序。

    人狼羊菜过河问题(编程求得最优算法)

    一个摆渡人F希望用一条小船把一只狼 W,一头羊 G 和一篮白菜 C 从一条河的左岸渡到右岸去,而船小只能容纳 F、W、G、C 中的两个,决不能在无人看守的情况下,留下狼和羊在一起,羊和白菜在一起,应怎样渡河才能将狼...

    用python编写的一款小游戏,实现人狼羊菜过河

    用python编写的一款小游戏,实现人狼羊菜过河

    人狼羊菜渡河问题(含Matlab程序).pdf

    人狼羊菜渡河问题(含Matlab程序).pdf人狼羊菜渡河问题(含Matlab程序).pdf

    人狼羊问题

    农夫需要把狼、羊、菜和自己运到河对岸去,只有农夫能够划船,而且船比较小,除农夫之外每次只能运一种东西,还有一个棘手问题,就是如果没有农夫看着,羊会偷吃菜,狼会吃羊。请考虑一种方法,让农夫能够安全地安排...

    c++语言程序设计 ()详细的讲解了C++)

    布鲁克斯用形象的譬喻来论述软件工程中存在的“陷阱”——“在所有恐怖民间传说的妖怪中,最可怕的是人狼,因为它们可以完全出乎意料地从熟悉的面孔变成可怕的怪物”,而“大家熟悉的软件项目具有一些人狼的特性...

    人狼日记「人狼日記 ブックマーク」-crx插件

    把人狼日记的参加者专用的页自动标记。 支持语言:日本語

    狼羊过河问题_数学建模

    利用状态转移矩阵,给出了狼羊过河问题的解法并附有相关代码及结果展示

    【老生谈算法】matlab实现人狼羊菜渡河问题(含Matlab程序).doc

    matlab算法原理详解

    JinroJ-heartScriptMEmu:MEmu版人狼Jスクリプト

    JinroJ-heartScriptMEmu MEmu版人狼Jスクリプト

    软件之死

    布鲁克斯用形象的譬喻来论述软件工程中存在的“陷阱”——“在所有恐怖民间传说的妖怪中,最可怕的是人狼,因为它们可以完全出乎意料地从熟悉的面孔变成可怕的怪物”,而“大家熟悉的软件项目具有一些人狼的特性...

    aiwolf:狼人AI竞赛(http)

    狼人狼人AI竞赛资料库( )相依性aiwolf客户端普通狼aiwolf服务器艾沃尔夫贵注意:始终使用最新的库版本会员列表

    狼,羊,白菜过河的小程序

    今天群里有人提起,就做了下,新手,做的不是很好.

    面向对象闲话

    面向对象渗透到软件的各个领域,既然找不到银弹,这颗铜子弹成了我们对抗人狼的最佳武器。在这样的世界里,你有没有想过,什么是面向对象呢?如果你习惯性地说:继承、封装和多态,那么请你继续读完这篇随笔吧,它会...

Global site tag (gtag.js) - Google Analytics