注册 登录  
 加关注
   显示下一条  |  关闭
温馨提示!由于新浪微博认证机制调整,您的新浪微博帐号绑定已过期,请重新绑定!立即重新绑定新浪微博》  |  关闭

Oracle专业打杂

定会重回巅峰……

 
 
 

日志

 
 

人月神话——各章概要和图片说明  

2013-10-08 22:35:12|  分类: 默认分类 |  标签: |举报 |字号 订阅

  下载LOFTER 我的照片书  |
第一章 焦油坑 
   
  史前时代的焦油坑吞噬了成千上万个力大无穷的巨兽,今天的大型软件项目则令无数庞大的开发团队陷入无从逃脱的窘境。软件程序按其规模和目标的不同,对开放过程的要求也有极大的不同,这给软件开放这一职业带来无穷乐趣,同时也是这一行业苦恼的根源。 
   
  【图片评注】图为洛杉矶自然历史博物馆George C Page馆内拉布雷亚焦油坑(La Brea Tar Pits)的中生代情形想象复原图。拉布雷亚地区早在北美殖民时期就以天然焦油沥青矿闻名。在百万年前,南加州的这片土地密布的焦油坑使无数鸟兽遭受没顶之灾,该地区是世界最著名的史前动植物化石集中地区之一。其貌不扬而深不可测的焦油坑吞噬了多少强壮的恐龙和矫捷的飞禽,令它们的同伴惊惧。本章提到的软件项目的焦油坑,也令多少貌似强大的开发团队一筹莫展,这值得整个软件行业深思。 
  
  第二章 人月神话 
   
  软件开发项目常以人月来衡量工作量,这种度量暗示着人手和时间是可以互换的。这种“人多力量大”的想法是一种一厢情愿的虚妄神话,布鲁克斯法则:向滞后的软件项目追加人手会使得进度更迟缓。自本书第一版以来,这一法则在软件业广为传诵。 
   
  【图片评注】图为早年新奥尔良的安东尼奥法式餐厅的菜单,该餐厅创建于1840年,上方白底区域便是本章题词的出处:精美的烹饪需要时间,本章主题即以箴言此引申展开:向软件项目盲目增加人手以求速成,往往是欲速则不达。 
   
  第三章 外科手术队伍 
  虽然优秀的程序员的工作效率往往数倍于平庸的程序员,但若是缺乏合理的配置,优秀的成员未必能构成优秀的团队。大型软件开发项目的团队需要和外科手术组一样妥善分工,各司其职协调配合。 
   
  【图片评注】图为合众社发布的一帧外科手术新闻照片。建立一个外科手术团队那样分工明晰,合作有序的开发团队,是高效率软件开发的重要保障之一。 
   
  第四章 元老制、民主制和系统设计 

  概念完整性是系统设计中最重要的因素,尤其对于大型软件系统,概念完整性是项目顺利完成的必要保障,为获得概念完整性,架构设计由精简的架构设计小组负责,具体实现则围绕核心概念展开,架构设计和具体实现既相分离,又相辅相成。以建筑工程为类比,概念完整性也是软件项目通往成功的保证。 
   
  【图片评注】图为Reims大教堂内景,位于巴黎的Reims是建筑史上最负盛名的哥特式教堂建筑之一。自从设计师Jean d’Ordais制定蓝图以后,继任的八位建筑师都理解并遵从这一初始设计的原则,保持了整体设计概念的完整性,最终Reims成为无与伦比的艺术精品。 
   
  第五章 第二个系统效应 

  人们在第一个系统成功完成后,往往会在开发后续的第二个系统时犯冒进的错误。第二个系统经常成为过度设计或画蛇添足的牺牲品。要避免这种错误,必须在第二个系统开发时审慎地考查技术环境的变化,广泛进行交流和沟通,聆听各方面的建议,确立严谨的估算和规划。 
  【图片评注】1882年画家A. Robida发表于比利时《二十世纪报》上的插画:一个想象中的极尽复杂的活动空中楼阁。设计者往往不肯放弃任何一个细枝末节创意,从而堆砌出不胜繁复的设计,这些设计往往成为头重脚轻的空中楼阁,看似完美,并无现实可行性。这种过度设计的错误,往往在设计者在踌躇满志地开始做系统改良设计时出现。软件项目的规划必须进行严谨理性的估算才能为项目的顺利进展打下牢固的根基,避免不必要的复杂化风险。 
   
  第六章 沟通顺畅 

  架构设计通常由核心设计小组完成,将设计概念传达到整个开发团队是贯彻概念完整性的必然要求。以System 360的开发经验为例,要贯彻概念完整性,需要在团队中保持良好顺畅的沟通和交流,采用形式化定义等技术来确保概念被精确地定义和传达。独立的测试小组是系统质量的良好保证。 
  【图片评注】图为14世纪宗教湿壁画Wells启示录中七天使号手。号角声在七位天使间依次传递,前一位吹响号角后,后一位将照样吹响下一声,有条不紊,号声传递得十分精准。作者以此图比喻团队间沟通畅通有序,只有这样概念完整性才能被正确贯彻到各处。 
   
  第七章 巴别塔为何失败 

  如果缺乏良好有效的沟通和协作,成员间难以有效的配合,团队项目的目标就无法实现。清晰的工作文档,明确的组织结构,合理的职责分配,都是大型软件项目最终成功的保证。 
   
  【图片评注】图为维也纳Kunsthistorisches博物馆馆藏的16世纪奥地利兄弟画家大Breughel所绘“巴别塔的建造”。在基督教传说中,人类发现可用砖和沥青代替天然的石块和灰泥来建筑房屋后,便打算建筑一座通往天堂的巴别塔。图中的巴别塔工程恢宏壮丽,工地欣欣向荣,确有直指云霄之势。上帝使人类各部族语言不通,才阻止了这项工程。在软件开发中,也许现有的技术已经可以所向披靡,但是如果整个团队不能进行良好有效的沟通,项目很可能功败垂成。 
   
  第八章 掌控之中 

  对大型软件系统产品的开发所需的时间和资源进行准确的估测,能让我们在项目进度和前景胸有成竹。软件代码的开发效率和代码模块之间所需的交互相关。界面交互复杂的程序需要更多的测试和调试时间,单纯地增加人手并不能有助于开发效率的提高。 
   
  【图片评注】图为美国历史上最伟大的职业棒球运动员贝比·鲁斯(Babe Ruth)在球场上发号施令。鲁斯是1936年首批选入美国棒球名人堂的五人之一。效力于波士顿红袜队和纽约扬基队时大放异彩,促使了1920、30年代美国职业棒球的兴盛。著名的“班比诺的诅咒”(the Curse of the Bambino)更使他的传奇声名至今不衰。他不仅是杰出的击球手,在球场上他也是指挥若定的球队核心。本章以此隐喻有效的管理和决策是致胜的关键。 
   
  第九章 袖里乾坤 

  最大化资源利用率,减少不必要的资源占用,合理规划,使软件系统在资源有限的情况下依然保证了良好的性能,从而实现良好的可伸缩性和健壮性,这能体现软件开发人员精湛的设计技巧。巧妙的数据结构往往能大幅度地俭省资源耗费,提高系统运行的性能。 
  【图片评注】图为维多利亚时期英国画家Heywood Hardy的作品,在大洪水到来之前,飞鸟走兽们进入诺亚方舟。 上帝许可每种鸟兽至少保留一公一母进入方舟逃避即将到来的灭顶之灾。小小诺亚方舟承担了各种群延续的希望,在有限的空间中装载整个世界,这需要精巧的规划,绝不可轻易耗费资源。 
   
  第十章 文档先行 

  在软件项目开发过程中,文档是不可或缺的,文档为整个团队规范了概念,以便团队中的沟通协作,以及进度校验。本章阐述了软件系统项目中至关重要的几类文档。这些关键文档应及时地更新,始终作为项目进展的有效指南。 
  【图片评注】图为1897年美国老国会图书馆内景。作者以汗牛充栋的图书形象地比喻软件项目中海量的文档令人目不暇给,明智地把握好关键的几类文档,才能不在浩瀚的信息中迷失,才能够迅速了解项目,进而准确地规划下一步工作。 
   
  第十一章 准备抛弃 

  变化是永恒的,用户的需求和期望在变化,开发者对用户需求的理解在变化,适用的技术也在变化,故而最佳的解决策略也可随之变化。软件开发团队应灵活地配置人力和资源,适应开发过程中的种种问题。程序的复杂性、用户需求的不确定性、软硬件技术环境的发展等因素导致了软件维护工作并非总是能够百分之百地获得回报。 
  【图片评注】图为纽约湾的Tacoma桥由于空气动力学上的错误设计而坍塌的新闻照片。1940年11月7日中午时分,建成仅仅数月的Tacoma桥坍塌,这是桥梁工程史上著名的悲剧。在做项目设计和规划时,一定要考虑到各种不确定的变化因素,灵活适应多变的环境,否则很可能酿成悲剧后果。 
   
  第十二章 良工利器 

  软件开发项目所选择的技术和工具对保障项目能否令人满意地如期完成至关重要。合适的开发工具、评测技术能有事半功倍之效果,切于项目实用的工具和技术是项目团队的重要财富。本章提供了当年软件开发项目选择技术和工具的重要原则和建议。 
  【图片评注】图为佛罗伦萨著名的圣母百花大教堂钟塔(Campanile di Santa Maria del Fiore)上的装饰浮雕――A.Pisano于1335年制作的“雕刻者”。得心应手的工具,是艺术大师造就初巧夺天工之作的必要条件之一,所谓“工欲善,必先利其器”。 
   
  第十三章 整体和局部 
  大而无当的笼统见地并不能表现你真正地理解了一个软件系统,应该具体而系统地深入了解各个局部的技术。良好的自顶向下的设计,不仅能保证概念完整性,也能及早消灭许多隐患。及早在软件项目中引入测试, 错误发现得越早,修复错误的代价越小。 
  【图片评注】图为迪斯尼公司著名的米老鼠魔术师形象。作者认为某些泛泛号称自己能完成庞大软件项目的业界人士,和旧时马戏团中以夸张吹嘘来吸引观众注意力的魔术师一样,其表演的东西并不能进行实质追究。良好的软件项目管理,应准确把握全局,严谨审核细节。 
   
  第十四章 潜伏的祸患 

  项目进度的滞后经常来自不易察觉的点滴延误的累积。软件项目的经理应该尽量建立可以明确量化的阶段性目标,定期进行严谨而规范的项目阶段性验收,了解项目的进展状况,并及时进行计划、资源和人力的调整。关键路径图等技术有助于观察项目的进度。 
  【图片评注】图为1802年A. Canova所作的雕塑:英雄赫拉克勒斯(Hercules)摔死带来死亡之袍的信使利卡斯(Lycas)。半人马涅索斯临终前为了报复赫拉克勒斯,哄骗赫拉克勒斯的妻子说以它的血染过的衣袍能保持丈夫的忠诚。一次战争大捷后,妻子让利卡斯将这件染过毒血的袍子带给赫拉克勒斯,他穿上后即痛苦难忍,在愤怒中摔死了并不知情的利卡斯,这也是英雄赫拉克勒斯在人世的结局。赫拉克勒斯是希腊神话中最伟大的半人半神英雄,一生业绩辉煌,却因为微小的家庭细故而走向英雄末路。本章中作者以此比喻潜藏的小祸患看似微不足道,而有朝一日可能葬送了原本看起来坚不可摧的事物。 
   
  第十五章 另一面 

  虽然用户直接使用软件系统,但在许多应用领域中,用户不可能仅仅凭借与软件的直接交互就迅速掌握其所有功能。故而提供给用户的使用说明等文档是软件呈现给用户的另外一面,它也能直接影响用户对软件的满意度和可用性评价。文档的用途决定它的形式和内容。 
   
  【图片评注】 图为英国巨石阵的想象复原图。巨石阵是世界上最大的没有文档说明的“计算机器“。4000-5000年前古人没有留下只言片语说明巨石阵的用途,至今考古学家对古人建筑巨石阵的目的莫衷一是,其中有一种可能是为了天文观测或者计算所用。本章中作者以此比喻文档匮乏会使软件产品难以为用户接受,故而使用文档在软件项目中相当重要。 
   
  第十六章 没有银弹――软件工程的必然和偶然
 
  本文最初发表于1985年的IFIP第十届世界计算机大会上,此时距《人月神话》初版发行已有十年,其间计算机技术领域的变化令人振奋,但作者在此提出,由于软件的复杂性,一致性,变化性和不可见性,解决软件危机的银弹并不存在。作者点评了二十世纪80年代前期为业界寄予厚望的一些新技术,讨论了它们在克服软件危机中所具备的优势和缺憾。作者预言在近十年内,没有任何单独的软件工程进展可以使软件生产率有数量级的提高。 
  【图片评注】图为1685年德国线刻版画的人狼故事。传说中凶残恐怖的人狼只有用银弹才能杀死。本章写于《人月神话》初版后的10年,10年内初版中提到的“焦油坑”危机依然如难以杀死的人狼游荡世间,危害软件项目。本章即谈论是否存在能一劳永逸地消灭人狼的法宝――银弹。 
   
   
  第十七章 再议“没有银弹” 

  相比《人月神话》初版而言,1986年发表的“没有银弹”(第十六章)发表后引发了热烈的争论,本章结合20世纪80年代后期到90年代前期之间软件复用、面向对象程序开发等等新技术的发展状况,回应了对《没有银弹》一文各种主要异议,认为由于《没有银弹》一文归纳的软件的几大特性,人们期待中的重大突破不可能在近期内到来。 
  【图片评注】图为儿童在搭建组合式构造玩具。利用成型的配件,能方便地搭建起大型的架构。本章以此讨论软件工程领域的最新发展,包括面向对象技术和软件复用等等,这些便利的新技术是否就是软件业界在寻找的银弹呢? 
   
  第十八章 人月神话的提议:是耶非耶 

  在撰写《人月神话》的回顾和更新过程中,作者发现初版中断言的观点甚少被软件工程研究和实践所抨击、证实或证伪,因此在本章中作者提炼了初版中十五个章节中的概要,结合近年来软件技术的发展状况,对这些观点进行强调、修正和反思。 
   
  【图片评注】图为1967年本书作者Brooks在做主题陈述。本章是对前面诸章要点的提炼陈述。 
   
  第十九章 人月神话二十年 

  在《人月神话》初版发布二十周年后,计算机技术领域已有很大变化,《人月神话》体现出深远的影响力,初版中的许多观点依然经常被人们谈论和引用,其中有些断言至今仍被软件开放人员奉为圭臬。作者结合当前软件工程领域的发展现状重新梳理了初版中的各核心观点,强调了概念完整性,重新评议了第二个系统效应,反省了瀑布模型的局限性,结合初版中的观点,作者评述了图形桌面系统、信息隐藏、面向对象高级语言等技术的发展,以及近年来软件工程领域的重要成果。 
  【图片评注】本章为《人月神话》二十周年纪念版的总结和更新陈述。鱼跃激流飞渡的图片,似在比喻计算机技术领域近二十年来令人兴奋的迅捷发展,借鉴历史,展望未来,在计算机技术这条年轻而遄急的河道上,我们当激流勇进,永不言退。 
  评论这张
 
阅读(94)| 评论(0)
推荐 转载

历史上的今天

在LOFTER的更多文章

评论

<#--最新日志,群博日志--> <#--推荐日志--> <#--引用记录--> <#--博主推荐--> <#--随机阅读--> <#--首页推荐--> <#--历史上的今天--> <#--被推荐日志--> <#--上一篇,下一篇--> <#-- 热度 --> <#-- 网易新闻广告 --> <#--右边模块结构--> <#--评论模块结构--> <#--引用模块结构--> <#--博主发起的投票-->
 
 
 
 
 
 
 
 
 
 
 
 
 
 

页脚

网易公司版权所有 ©1997-2017