logo资料库

人月神话的读书笔记.doc

第1页 / 共34页
第2页 / 共34页
第3页 / 共34页
第4页 / 共34页
第5页 / 共34页
第6页 / 共34页
第7页 / 共34页
第8页 / 共34页
资料共34页,剩余部分请下载后查看
《人月神话》作者-Frederick Brooks传记
人月神话-未雨绸缪和干将莫邪
人月神话-另外一面
主题阅读-人月神话读书笔记汇总 作者介绍:20 世纪最后一年也就是 1999 年的图灵奖,授予了年已 69 岁的资深计算机科学家 布鲁克斯(Frederick Phillips Brooks, Jr.)。布鲁克斯这个名字在中国知之者不多,但在 美国却是大名鼎鼎。因为他在 60 年代初只有 29 岁时就主持与领导了被称为人类从原子能时 代进入信息时代标志的 IBM/360 系列计算机的开发工作,取得辉煌成功,从而名噪一时。以 后他作为硬件和软件的双重专家和出色的教育家始终活跃在计算机舞台上,在计算机技术的 诸多领域中都做出了巨大的贡献。从某种意义上说,对于布鲁克斯而言,图灵奖是一个“迟 到的荣誉”。1975 年,他把他历年来所写的有关软件工程和项目管理方面的文章汇集成书, 书名为《人月神话》(The Mythical Man-Month: Essay on Software Engineering,Addison Wesley)。由于本书是他领导 IBM/360 软件开发经验的结晶,内容丰富而生动,成为软件工 程方面的经典之作。 人月神话这本书究竟谈了什么?我大概按 CMMI 的项目管理,工程和支持过程三个维度。按 人,方法工具技术和流程三要素进行了一下梳理。书里面这几个方面的内容全部涉及到了。 在项目管理方面可以看到项目估算,组织结构和人员角色安排,团队建设和沟通,历史数据 积累和建模,软件开发方法论,风险和问题管理等相关的内容;在软件工程方面可以看到架 构设计保证概念完整性,整体和部分,空间技能和程序结构的关系,产品集成的方法和消除 缺陷的设计思路;在支持过程上我们可以看到文档和流程的建设,软件开发工具对软件开发 过程的支持和效率的提升以及工具的选择等相关内容。 回过来再看,发现书里面仍然大部分内容涉及到了团队,人和沟通。对于大型的软件工程项 目仍然强调了人的重要性,在开篇就在讲开发人员的职业乐趣,后面又通过巴比伦塔讲沟通 的重要性,在外科手术队伍中讲团队的组建和分工。这些都涉及到了团队中的人和交互,只 有一个有了积极心态和热情的沟通团队,才可能成就一个伟大的团队。从最后的没有银弹, 再次肯定了开发工作是一种高智力的脑力工作。 以下为分章节的读书笔记汇总: 《人月神话》各章精选  《人月神话》作者-Frederick Brooks 传记 
人月神话-人月的启示  人月神话-焦油坑  人月神话-外科手术队伍  人月神话-贵族专制和民主政治  人月神话-画蛇添足  人月神话-贯彻执行  人月神话-巴比伦塔的失败  人月神话-胸有成竹  人月神话-削足适履和提纲挈领  人月神话-未雨绸缪和干将莫邪  人月神话-整体部分和祸起萧墙  人月神话-另外一面  人月神话-没有银弹
人月神话》各章精选 第 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 年前软件开发 经验的书,如何能够依然和现实情况相关?更不用说有所帮助了
《人月神话》作者-Frederick Brooks 传记 20 世纪最后一年也就是 1999 年的图灵奖,授予了年已 69 岁的资深计算机科学家布鲁克斯 (Frederick Phillips Brooks, Jr.)。布鲁克斯这个名字在中国知之者不多,但在美国却是 大名鼎鼎。因为他在 60 年代初只有 29 岁时就主持与领导了被称为人类从原子能时代进入信 息时代 标志的 IBM/360 系列计算机的开发工作,取得辉煌成功,从而名噪一时。以后他作 为硬件和软件的双重专家和出色的教育家始终活跃在计算机舞台上,在计算 机技术的诸多 领域中都做出了巨大的贡献。从某种意义上说,对于布鲁克斯而言,图灵奖是一个“迟到的 荣誉” 布鲁克斯 1931 年 4 月 19 日生于北卡罗来纳州的杜哈姆。1953 年从杜克大学毕业,取得学 士学位以后,进入哈佛大学深造,1955 年取得硕士学位, 1956 年取得博士学位。值得指出 的是,布鲁克斯取得的是计算机科学的博士学位,是一位“正宗”的计算机博士,是世界上 第一批获得计算机科学博士学位的少 数学者之一。他的博士论文课题工作是在哈佛著名的 计算实验室(Computation Laboratory)进行的。大家知道,40 年代被称为 MARKI 的世界上 第一台程序控制的机电式计算机 ASCC(Automatic Sequence Controlled Calculator)就是 由艾肯(Howard Hathaway Aiken,1900~1973)在这里设计,并获得 IBM 的支持而开发成功的。 请大家注意,叫 MARK 的计算机有两种。除哈佛艾肯设计的 ASCC 被叫成 MARK 外,英国曼彻 斯特大学由威廉斯管的发明人 F.C.Williams 和 T.M.Kilburn 等人研制的 MADM 计算机(1848 年)也被叫成 MARKI,这是一台用威廉斯管作存储器并可存储程序的计算机,有时也叫做“婴 儿”机(Baby)。通常提到的 MARKI 指哈佛的那一台。布鲁克斯最终完 成的博士论文题目为 “自动数据处理系统的分析设计”(“TheAnalytic Designof Automatic Data Processing System”)。从博士论文开始,布鲁克斯的一生就与计算机结下了不解之缘。 在哈佛取得博士学位以后,布鲁克斯进入 IBM 公司设立在纽约波凯普茜的实验室当工程师。 这个实验室从 50 年代到 80 年代一直是 IBM 开发计算机的中心。布 鲁克斯在这里参加了 Harvest 和 Stretch 计算机的开发,任体系结构设计师。这两个型号的计算机都引入了一些 新技术,在 50 年代后期至 60 年代初 期有很大影响,尤其是 Stretch 计算机,首创先行控 制方式,最多可重叠执行 6 条连续的指令,后来被发展成流水线方式,因而被认为是世界上 第一台流水线 计算机。布鲁克斯在其中的创造性贡献是解决了程序中断系统的设计,在数 据格式中出现不均匀的字符分布时如何设计其二进制代码等问题,并从而在 1957 年取 得了 他的第一个美国专利“程序中断系统”(Program Interrupt System,专利号 3048332,与 D.W.Sweenly 共有),发表了他最初的两篇学术论文。 1959 年,布鲁克斯曾被调至 IBM 在约克郡高地的研究中心工作,但第二年又重新被调回波 凯普茜的实验室,因为当时 IBM 内部在计算机的研发方向上产生了 重大的分歧。1960 年时, IBM 的计算机生产线上的产品是 8000 系列,但遭到一些人的反对,其领头人是伊万斯。伊 万斯虽然只是衣阿华州立大学电气工程 系的一个本科毕业生,但 1951 年就加盟 IBM,曾参 与或主持过 IBM701、7070、1410、7070 等多种型号计算机的开发,已经积累相当丰富的 知 识和经验。他经过认真分析,认为主要继承 IBM 原有技术的 8000 计算机,即使研制成功并 上市,过不了几年,即到 1964 年就会丧失生命力,缺乏市场竞 争能力。因此他主张 8000 机下马,采用新的技术开发新的计算机,尤其是要开发新的操作系统。伊万斯的意见使 IBM 分裂成为两派,一派支持,一派反对,而 反对派的领头人正是布鲁克斯!两派的争论和对
立非常尖锐,又势均力敌,因为伊万斯的学历没有布鲁克斯高,但资历却比他老,双方的支 持者人数也差不多。以小 沃森(Thomas John Watson, Jr.)为首的 IBM 决策层于 1961 年 5 月担着极大的危险最后采纳了伊万斯的意见,是年秋宣布成立一个名为 SPREAD(系统程序设 计、研究、工程和开 发,Systems Programming, Research, Engineeringand Development) 的委员会作为“taskforce”(类似于我国过去经常采用的所谓“攻关领导小组”),由 13 人组成,主席为汉斯特拉 (John w. haanstra),副主席为伊万斯,布鲁克斯是成员之一。 作为争论中胜方的伊万斯冷静地分析了形势以后,做出了一个令人大感意外的决定,他亲自 找到布鲁 克斯,请布鲁克斯主持日后被称为 IBM/360 的这个新项目。伊万斯这一举动主要 基于以下两点考虑,一是如果由他自己来主持 360,那么原来反对他意见的 另一派人很难 团结在他的周围;二是涉及这样重大改革与创新的项目,应该让年轻人来挑头。他自己虽然 当时也只有 34 岁,但布鲁克斯比他小 5 岁,更加年轻。难 能可贵的是,布鲁克斯作为争论 的负方,慨然接受了伊万斯的邀请,同意负责这个他曾经反对过的项目!这个故事很像我国 京剧舞台上的“将相和”(虽然伊万斯并 未“负荆请罪”)。伊万斯和布鲁克斯双方在这件 事上所表现出来的明智、大度和勇气都十分令人钦佩和赞叹。其结果和效果就是整个 IBM 公司的职工果然团结起 来,实现了痛苦而艰难,然而却是历史性的转变和飞跃。IBM/360 的开发总投资 5 亿美元,达到美国研究原子弹的曼哈顿计划投资 20 亿美元的 1/4。在研 制 期间,布鲁克斯率领着 2000 名程序员夜以继日地工作,单单 360 操作系统的开发就用了 5000 个人年。因此,当 1964 年 4 月 7 日,在 IBM 公司纪念 其成立 50 周年的庆祝大会上宣布 360 系列计算机的时候,小沃森完全有理由声称“这是公司历史上宣布的最重要的产品”。确实, IBM/360 以其通用化、 系列化和标准化的特点,对全世界计算机产业的发展产生了如此深 远的影响,以致被认为是划时代的杰作。而 360 的推出,也使 IBM 在短短两年时间内,即到 1966 年,其资本就增加到 45 亿美元,职工总数净增 6 万,达到 19 万,成为名副其实的“蓝 色巨人”。到 60 年代末,360 系列机的市场占有率达到 15%,到 70 年代中期,超过了 50%。 各计算机生产厂商纷纷以 360 为榜样,推出各自的系列机,有的则直接采用 360 的操作系统, 比如著名的 Amdahl 公司的所谓“插接兼容式”计算机(Plug Compatible Computer)就是这 样。为此,伊万斯和布鲁克斯两人常常被并称为“IBM/360 之父”。 当然,IBM/360 到今天早已是“昨日黄花”了。IBM 公司在 70 年代就推出了 370 系列替代 360,以继续保持其技术上的优势。我们之所以用了一定篇 幅介绍 360 的故事,是因为其中 不乏让我们的企业家、科学家和工程技术人员深思的一些问题。IBM/360 的特点我们只简要 介绍如下:它是集成电路的计算 机,体系结构既适于事务处理,又便于科学计算;系列中 各机型(规模由小到大,功能从弱到强,包括 20、30、40、50、65、75 等 6 个型号,后来扩 充 了 25、85、91、195 等型号)具有兼容性;有标准的输入输出接口和通用的输入输出设备, 它们与中央处理器相对独立;软件既有兼容性又有可扩充性,从 而可最大限度地保护用户 的软件投资。这些特征大多都成为以后计算机设计与开发所遵循的基本原则。 360 成功以后,布鲁克斯离开 IBM 回到其故乡,为北卡大学(UNC)创建了计算机科学系,担 任该系系主任长达 20 年(1964~1984 年)。卸任以后 仍在该系任教至今,因此他培养的学 生很多,可谓“桃李满天下”。除了教学以外,他还致力于发展美国的计算机技术和计算机 在国防等方面的应用,有许多社会兼 职。1966~1970 年,他是 ACM 全国委员会的委员;1973~ 1975 年出任 ACM 体系结构委员会(所谓 SIGCA)的主席;1977~1980 年 布鲁克斯在美国国家 研究院计算机科学技术部任职;1983~1984 年他是美国国防科学委员会人工智能攻关领导 小组的成员,1986~1987 年是上述委 员会另一个攻关领导小组“计算机模拟和训练”的成
分享到:
收藏