《人月神话》各章精选

转载 2005年03月02日 17:58:00
《人月神话》各章精选



第1章 焦油坑


史前史中,没有别的场景比巨兽在焦油坑中垂死挣扎的场面更令人震撼。上帝见证着恐龙、猛犸象、剑齿虎在焦油中挣扎。它们挣扎得越是猛烈,焦油纠缠得越紧,没有任何猛兽足够强壮或具有足够的技巧,能够挣脱束缚,它们最后都沉到了坑底。
过去几十年的大型系统开发就犹如这样一个焦油坑,很多大型和强壮的动物在其中剧烈地挣扎。他们中大多数开发出了可运行的系统——不过,其中只有非常少数的项目满足了目标、时间进度和预算的要求。各种团队,大型的和小型的,庞杂的和精干的,一个接一个淹没在了焦油坑中。表面上看起来好像没有任何一个单独的问题会导致困难,每个都能被解决,但是当它们相互纠缠和累积在一起的时候,团队的行动就会变得越来越慢。对问题的麻烦程度,每个人似乎都会感到惊讶,并且很难看清问题的本质。不过,如果我们想解决问题,就必须试图先去理解它。



第2章 人月神话


Brooks法则:

向进度落后的项目中增加人手,只会使进度更加落后。



第3章 外科手术队伍


在计算机领域的会议中,常常听到年轻的软件经理声称他们喜欢由头等人才组成的小型、精干的队伍,而不是那些几百人的大型团队,这里的“人”当然暗指平庸的程序员。其实我们也经常有相同的看法。

但这种幼稚的观点回避了一个很困难的问题——如何在有意义的时间进度内创建大型的系统?那么就让我们现在来仔细讨论一下这个问题的每一个方面。

第4章 贵族专制、民主政治和系统设计


法国城市兰斯(Reims)在建筑风格上的一致性和上面所说的大教堂形成了鲜明的对比。设计的一致性和那些独到之处一样,同样让人们赞叹和喜悦。如同旅游指南所述,风格的一致和完整性来自8代拥有自我约束和牺牲精神的建筑师们,他们每一个人牺牲了自己的一些创意,以获得纯粹的设计。同样,这不仅显示了上帝的荣耀,同时也体现了他拯救那些沉醉在自我骄傲中的人们的力量。



第5章 画蛇添足


在开发第一个系统时,结构师倾向于精炼和简洁。他知道自己对正在进行的任务不够了解,所以他会谨慎仔细地工作。

在设计第一个项目时,他会面对不断产生的装饰和润色功能。这些功能都被搁置在一边,作为“下一个”项目的内容。第一个项目迟早会结束,而此时的结构师,对这类系统充满了十足的信心,熟练掌握了相应的知识,并且时刻准备开发第二个系统。

第二个系统是设计师们所设计的最危险的系统。



第6章 贯彻执行


假设一个项目经理已经拥有行事规范的结构师和许多编程实现人员,那么他如何确保每个人听从、理解并实现结构师的决策?对于一个由1000人开发的系统,一个10个结构师的小组如何保持系统概念上的完整性?在System/360硬件设计工作中,我们摸索出来一套实现上述目标的方法,它们对于软件项目同样适用。



第7章 为什么巴比伦塔会失败?  


那么,既然他们具备了所有的这些条件,为什么项目还会失败呢?他们还缺乏些什么?两个方面——交流,以及交流的结果——组织。他们无法相互交谈,从而无法合作。当合作无法进行时,工作陷入了停顿。通过史书的字里行间,我们推测交流的缺乏导致了争辩、沮丧和群体猜忌。很快,部落开始分裂——大家选择了孤立,而不是互相争吵。



第8章 胸有成竹


系统编程需要花费多长的时间?需要多少的工作量?如何进行估计?



第9章 削足适履


创造出自精湛的技艺,精炼、充分和快速的程序也是如此。技艺改进的结果往往是战略上的突破,而不仅仅是技巧上的提高。这种战略上突破有时是一种新的算法,如快速傅立叶变换,或者是将比较算法的复杂度从n2降低到n log n。

更普遍的是,战略上突破常来自数据或表的重新表达——这是程序的核心所在。



第10章 提纲挈领


我记得曾经有一个项目,在三年的开发周期中,机器指令计数器的设计每六个月变化一次。在某个阶段,需要好一点的性能时,指令计数器采用触发器来实现;下一个阶段,成本降低是主要的焦点,指令计数器采用内存来实现。在另一个项目中,我所见过的最好的一个项目经理常常充当一个大型调速轮的角色,他的惯性降低了来自市场和管理人员的起伏波动。



第11章 未雨绸缪


因此,管理上的问题不再是“是否构建一个试验性的系统,然后抛弃它?”你必须这样做。现在的问题是“是否预先计划抛弃原型的开发,或者是否将该原型发布给用户?”从这个角度看待问题,答案更加清晰。将原型发布给用户,可以获得时间,但是它的代价高昂——对于用户,使用极度痛苦;对于重新开发的人员,分散了精力;对于产品,影响了声誉,即使最好的再设计也难以挽回名声。

因此,为舍弃而计划,无论如何,你一定要这样做。



第12章 干将莫邪


就工具而言,即使是现在,很多软件项目仍然像一家五金店。每个骨干人员都仔细地保管自己工作生涯中搜集的一套工具集,这些工具成为个人技能的直观证明。正是如此,每个编程人员也保留着编辑器、排序、内存信息转储、磁盘实用程序等工具。

这种方法对软件项目来说是愚蠢的。



第13章 整体部分


和古老的神话里一样,现代神话里也总有一些爱吹嘘的人:“我可以编写控制航空货运、拦截弹道导弹、管理银行账户、控制生产线的系统。”对这些人,回答很简单,“我也可以,任何人都可以,但是其他人成功了吗?”

第14章 祸起萧墙
当一线经理发现自己的队伍出现了计划偏离时,他肯定不会马上赶到老板那里去汇报这个令人沮丧的消息。团队可以弥补进度偏差,他可以想出应对方法或者重新安排进度以解决问题,为什么要去麻烦老板呢?从这个角度来看,好像还不错。解决这类问题的确是一线经理的职责。老板已经有很多需要处理的真正的烦心事了,他不想被更多的问题打搅。因此,所有的污垢都被隐藏在地毯之下。

有两种掀开毯子把污垢展现在老板面前的方法,它们必须都被采用。一种是减少角色冲突和鼓励状态共享,另一种是猛地拉开地毯。



第15章 另外一面


面对那些文档“简约”的程序,我们中的大多数人都不免曾经暗骂那些远在他方的匿名作者。因此,一些人试图向新人慢慢地灌输文档的重要性:旨在延长软件的生命期、克服惰性和进度的压力。但是,很多次尝试都失败了,我想很可能是由于我们使用了错误的方法。

第16章 没有银弹
在所有恐怖民间传说的妖怪中,最可怕的是人狼,因为它们可以完全出乎意料地从熟悉的面孔变成可怕的怪物。为了对付人狼,我们在寻找可以消灭它们的银弹。

大家熟悉的软件项目具有一些人狼的特性(至少在非技术经理看来),常常看似简单明了的东西,却有可能变成一个落后进度、超出预算、存在大量缺陷的怪物。因此,我们听到了近乎绝望的寻求银弹的呼唤,寻求一种可以使软件成本像计算机硬件成本一样降低的尚方宝剑。 但是,我们看看近十年来的情况,没有银弹的踪迹。没有任何技术或管理上的进展,能够独立地许诺在生产率、可靠性或简洁性上取得数量级的提高。本章中,我们试图通过分析软件问题的本质和很多候选银弹的特征,来探索其原因。



第17章 再论《没有银弹》


《没有银弹》中声称和断定,在近十年内,没有任何单独的软件工程进展可以使软件生产率有数量级的提高(引自1986年的版本)。现在已经是第九个年头,因此也该看看是否这些预言得到了应验。

《人月神话》一文被大量地引用,很少存在异议;相比之下,《没有银弹》却引发了众多的辩论,编辑收到了很多文章和信件,至今还在延续3。他们中的大多数攻击其核心论点和我的观点——没有神话般的解决方案,以及将来也不会有。他们大都同意《没有银弹》一文中的多数观点,但接着断定实际存在着杀死软件怪兽的银弹——由他们所发明的银弹。今天,当我重新阅读一些早期的反馈,我不禁发现在1986年~1987年期间,曾被强烈推崇的秘方并没有出现所声称的戏剧性效果。



第18章 《人月神话》的观点:是或非?


现在我们对软件工程的了解比1975年要多得多。那么在1975年版本的人月神话中,哪些观点得到了数据和经验的支持?哪些观点被证明是不正确的?又有哪些观点随着世界的变化,显得陈旧过时呢?为了帮助判断,我将1975年书籍中的论断毫无更改地抽取出来,以摘要的形式列举在下面——它们是当年我认为将会是正确的:客观事实和经验中推广的法则。(你也许会问,“如果这些就是那本书讲的所有东西,为什么要花177页的篇幅来论述?”)方括号中的评论是新增内容。



第19章 20年后的人月神话


为什么《人月神话》得以持续?为什么看上去它仍然和现在的软件实践相关?为什么它还拥有软件工程领域以外的读者群,律师、医生、社会学家、心理学家,和软件人员一样,不断地对这本书提出评论意见,引用它,并和我保持通信?20年前的一本关于30年前软件开发经验的书,如何能够依然和现实情况相关?更不用说有所帮助了。

《人月神话》一句话总结各章核心观点

第1章 焦油坑:提出软件产品现在处于进度和质量焦油坑当中,难以摆脱。 第2章 人月神话:人月估算法是错误的,这会暗示人月可互换,这种方式严重的忽视了一个重要的成本,沟通成本。 第3章 外科手术队伍...

人月神话精选篇章

  • 2011年12月27日 13:16
  • 28KB
  • 下载

《The Design of Design》之 理性模型--《人月神话》作者之力作

理性模型         最原始也是最符合设计师第一感觉的设计方式,因为理性,所以叫理性模型:);         设计的理论即一般的搜索理论,对象是巨大的组合空间. 目标:         ...

《人月神话》的观点:是与非?

摘录自《人月神话》第18章第1章 焦油坑1.编程系统产品开发的工作量是供个人使用的、独立开发的构件程序的9倍。我估计软件构件产品化引起了3倍的工作量,这些高成本的构件在根本上是相互独立的。2.编程行业...

读软件工程经典《人月神话》观点摘抄和我的理解之二

Brooks的观点拿到现在,不一定都是金科玉律,但是我们得分析,哪些还是客观规律,必须遵循;哪些需要与时俱进;我们应当对Brooks的观点有所增益。   第4章 贵族专制、民主政治和系统设...
  • joeyon
  • joeyon
  • 2015年03月06日 11:28
  • 603

[人月神话]读书笔记6--永恒的变化&&开发工具效用

未雨绸缪(Plan to Throw One Away) 干将莫邪(Sharp Tools)

控制变化——《人月神话》书评

前几天终于把《ren》

简图记录-人月神话-编程产品开发的问题与思考

简图记录学习~ 《人月神话》Friderick P.Brooks 相比程序开发,编程产品的开发往往困难的多~     编程产品=程序+良好风格+完善测试+完备手册。大家都乐于 创造 学习 思维碰...

【人月神话】第一章:焦油坑

最近在看《人月神话》,分享一下自己的读书笔记个人的感受。希望能对大家有所帮助。第一章主要就是讲软件编程就是一个乐趣与苦恼并存的焦油坑。本书用了一个很新形象的比喻:大型软件系统的开发就像是一个焦油坑(像...

[人月神话]读书笔记4--项目中的交流沟通&&项目估算

为什么巴比伦塔会失败?(Why Did the Tower of Babel Fail) 胸有成竹(Calling the Shot)...
内容举报
返回顶部
收藏助手
不良信息举报
您举报文章:《人月神话》各章精选
举报原因:
原因补充:

(最多只允许输入30个字)