【读书笔记】人月神话

《人月神话》读书笔记人月神话人物简介：美国工程院院士“IBM360系统之父”，曾担任360系统的项目经理，及该项目设计阶段的经理。凭借在此项目中的杰出贡献，在1985年获得美国国家技术奖。1999年荣获美国计算机领域最具声望的图灵奖（A.M.TURINGAWARD）桂冠。

弗雷德里克·布鲁克斯FrederickP.Brooks,Jr.弗雷德里克·布鲁克斯的经典著作——《人月神话》2000年新年伊始，国际计算机协会（ACM）在纽约宣布1999年图灵奖得住为时年为69岁的FrederickP.Brooks,Jr.。评选委员会主席在致辞中提到，“今天我们所看到的计算机体系结构、软件工程及三维计算机图形，均受益于Brooks的开创性工作，是他改变了这些领域的面貌。”Brooks确实是一位在计算机科学各方面均作出杰出贡献的奠基者。然而，他最广为认知的功绩则是在软件领域的重要经典著作——《人月神话》，可以说正是此书让软件工程学进入了人们的视野。弗雷德里克·布鲁克斯的经典著作——《人月神话》《人月神话》40周年纪念版《人月神话》20周年纪念版《人月神话》32周年纪念版书籍简介1975年首次发行软件工程的经典之作收录了作者多年的技术文章为大型的软件开发提供启示软件领域的神话——

一本畅销不衰的著作在计算机这个日新月异的领域中，长盛不衰的书籍几乎是凤毛麟角的。为什么《人月神话》的魅力能不因技术的更替而黯淡，反而能在这多变的时代中证明自己的价值，乃至有了20年，32年，40年的纪念版出现呢？技术并非《人月神话》的着眼点，它更关注的是软件的创造过程、需求的变化无常和管理的永恒困境。《人月神话》的中心思想已经超越了具体的时代和技术。名家谈人月神话这是一本经典著作，与软件开发有关的每一个人都应该不只一遍地读这本书。

——PhilippeKruchtenRational统一过程首席架构师它仍然是计算机书籍中被引用次数最多的书籍，而且即便本书最初出版于1975年，其内容至今仍未过时。在阅读的时候，每隔几页不说一句“对极了！”是很难受的。

——SteeMcConnell,Construx公司首席软件工程师我唯一一本读过一遍以上的书，是FredBrooks的《人月神话》，实际上我每过一两年就会重读一遍。部分原因是这本书文笔很好，另外就是书中的忠告很有价值，即使是25年以后。我非常推崇这本书，这是我唯一能想起来的能从中体会到乐趣和思想的计算机学科书籍。

——BrianKernighan,著名《C程序设计语言》的合著者之一。《人月神话》的由来IBM的System/360是第一个特大型软件项目，它催生了《人月神话》《人月神话》的由来System/360的开发过程被视为计算机发展史上最大的一次豪赌，为了研发System/360这台大型机，IBM决定征召6万多名新员工，创建五5座新工厂，当时的研发费用超过了50亿美元（相当于现在的340亿美元，约2200亿人民币），但出货的时间不断的顺延。当时的专案经理FrederickP.Brooks,Jr.事后根据这项计划的开发经验，写作《人月神话：软件项目管理之道》（TheMythicalMan-Month:EssaysonSoftwareEngineering）记述人类工程史上一项里程碑式的大型复杂软件系统开发经验。在《人月神话》中，Brooks博士为人们管理复杂的项目提供了最具洞察力的见解，既有很多引人深思的观点，又有大量软件工程的实践。人月神话人月：软件开发过程中衡量工作量的常用度量单位。而在实际情况中，增加“人”并不能缩短“月”的量为什么说人月是神话？（1）许多任务是无法拆解的（2）即使任务可以拆解，人员之间的沟通交流时间随着人手的增加以(n-1)*n/2的规模递增

如：20人*5个月>50人*2个月《人月神话》目录第1章焦油坑第2章人月神话第3章外科手术队伍第4章贵族专制、民主政治和系统设计第5章画蛇添足第6章贯彻执行第7章为什么巴比伦塔会失败第8章胸有成竹第9章削足适履第10章提纲挈领第11章未雨绸缪第12章干将莫邪第13章整体部分第14章祸起萧墙第15章另外一面第16章没有银弹-软件工程中的根本和次要问题第17章再论“没有银弹”第18章《人月神话》的观点：是与非第19章20年后的《人月神话》人月神话——焦油坑图为洛杉矶自然历史博物馆GeorgeC.Page馆内布拉雷亚焦油坑的中生代情形想象图原图焦油坑史前吞噬成千上万的巨兽今天围困大型软件项目无数庞大的开发团体软件开发中的焦油坑“史前史中，没有别的场景比巨兽在焦油坑中垂死挣扎的场面更令人震撼。上帝见证着恐龙、剑齿虎在焦油中的挣扎。它们挣扎的越是猛烈，焦油越是缠的越紧，没有任何猛兽足够强壮或具有足够的技巧，能够挣脱束缚，它们最后都沉到了坑底。”——Brooks

大型的系统开发类经常遇到焦油坑！“表面上看起来好像没有任何一个单独的问题会导致困难，每个都能被解决，但是当它们相互纠缠和积累在一起的时候，团队的行动就会变得越来越慢。对问题的麻烦程度，每个人似乎都会感到惊讶，并且很难看清问题的本质。”——Brooks软件开发中的焦油坑WindowsNT5.0(即windows2000)时间：计划开发时间：3年实际开发时间：5年公布数据：程序员人数：5,000人代码行数：35,000,000行代码开发时间：5年每位程序员每年生产多少行代码？软件开发中的焦油坑每位程序员每年生产多少行代码？

以最不幸的情况来估计，每行代码都需要自己编写，得到结果：35,000,000行/(5000人*5年)=1400行/人.年。 这个效率远远低于一名正常程序员的产出量。两种可能：(1)微软雇佣了5000名不合格的程序员去开发windowsNT5.0(2)开发一个大规模的程序系统产品远难于堆砌出单一的程序。作者目的：尽可能地帮助大型系统开发人员走出焦油坑焦油坑之一：进度滞后进度滞后的原因乐观主义的盛行（软件开发是纯思维性的活动）人月神话各项任务的时间安排不当（特别是测试时间）迫于用户压力制定了不合理的进度计划brooks法则焦油坑之一：进度滞后

“使用人月为单位来衡量一份工作的规模是一个危险和具有欺骗性的神话。它暗示着人员数量和时间是可以相互替换的。”——brooks人月神话人月：参与开发的程序员数目*项目持续的月数为什么说人月是神话？（1）许多任务是无法拆解的（2）即使任务可以拆解，人员之间的沟通交流时间随着人手的增加以(n-1)*n/2的规模递增

20人*5个月>50人*2个月焦油坑之一：进度滞后 图一:可以完全分解的任务（在软件开发中不存在) 图二:可以分解但需要沟通交流的任务(一般情况) 图三:关系错综复杂的任务

（极端情况)焦油坑之一：进度滞后各项任务的时间安排不合理作者的经验之谈：测试时间不足的恶果：直到项目的发布时期，才有人发现进度的问题。焦油坑之一：进度滞后Brooks法则定义："Addingmanpowertoalatesoftwareproject makesitlater."--Brooks出现原因： 新增的程序员需要进行培训，同时增加了沟通的成本，使得开发团队增加了更多的开发时间，这个时间超过了新增程序员所做的贡献。结论过于武断？应该附加的前提： (1)项目已经进行了相当长时间的开发

(2)系统比较复杂，新人的学习成本较高焦油坑之一：进度滞后对于进度滞后项目的解决方案(1)在新的进度安排中分配充分的时间，确保工作能彻底、认真地完成(2)当项目延期所导致的后续成本很高时，往往削减系统的功能是唯一的解决方法对于许多小型的开发团队，加派人手是通常的解决方法？焦油坑之二--缺乏沟通巴别塔为什么会失败？巴别塔：圣经中继“诺亚方舟”后人类第二个大工程，以失败告终焦油坑之二--缺乏沟通巴别塔为什么会失败？

现在整个大地都使用同一种语言。在一次迁徙的过程中，人们发现了苏美尔地区，并且在那里定居下来。他们说：“来，让我们建造一座带有高塔的城市，这个塔将高耸云霄，也让我们声名远扬。”于是上帝决定下来看看人们建造的城市和高塔，看了以后，他说：“他们只是一个种族，使用一种语言，如果他们一开始就能造出城市和高塔，那以后就没有什么能难得倒他们了。来，让我们在人类的语言里制造些混淆，让他们相互之间不能听懂。”上帝于是改变并区别开了人类的语言，巴比伦塔不得不停工了。 --旧约第11章

巴别：在希伯来语中是"变乱"的意思焦油坑之二--缺乏沟通如果大型编程项目中交流不足，很可能面临和巴别塔一样的结局。大型编程项目中的交流方法(1)成员之间非正式途径的经常性讨论(2)定期召开的项目会议(3)项目工作手册焦油坑之二--缺乏沟通在树状组织架构中进行交流

传统的沟通方式是网状的，n个人之间的交流需要(n-1)*n/2个接口。然而团队的组织架构总是树状的，可以利用这种树状的组织结构减少沟通成本。需要为每棵子树定义一些基本要素：(1)每棵子树需要完成的任务(2)子树的产品负责人（对外沟通）(3)子树的技术主管（对内技术指导）(4)进度(5)人员的划分(6)子树对外接口的定义焦油坑之三--文档问题撰写关键的文档书面的决策更加精确文档可作为沟通交流的手段文档可为系统将来的优化和扩展提供指导项目经理的文档可作为项目的数据基础和检查表不提倡过度文档给用户使用的最终产品并非是文档焦油坑之三--文档问题需要提供哪些关键的文档？做什么：开发目标怎么做：产品技术说明。以建议书开始，以内部文档和用户手册结束时间：进度表资金：预算地点：工作空间分配人员：组织图焦油坑之三--文档问题自文档化的程序为什么提倡自文档化程序？

数据处理的基本原理告诉我们，试图把信息放在不同文件中，并试图维护它们的同步是件费力不讨好的事情。在软件开发里，我们却试图维护一份机器可读的程序，以及一系列包含记述性文字和流程图的文档。如何产生自文档化的程序？ (1)在程序源代码里附加尽可能多的信息，例如变量名，函数名等 (2)尽可能使用空格和一致性的格式来提高程序的可读性，表现从属和嵌套关系 (3)以段落注释的格式，向程序插入必要的记述性文字人月神话——精美的烹饪需要时间图为早年新奥尔良的安东尼奥法式餐厅的菜单精美的烹饪需要时间软件开发项目常以人月来衡量工作，这种度量暗示着人手和时间是可以互换的。这种“人多力量大”的想法是一种一厢情愿的虚妄神话。Brooks法则：向滞后的软件项目追加人手会使得进度更迟缓。美酒的酿造需要年头，美食的烹调需要时间；片刻等待，更多美味，更多享受。GoodCookingtakestime.Ifyouaremadetowait,itistoserveyoubetter,andtopleaseyou.人月神话——外科手术队伍图为合众社发布的外科手术新闻照片建立一个外科手术团队那样分工明细、合作有序的开发团队，是高效率软件开发的重要保障之一。人月神话——贵族专制、民主政治和系统设计

图为Reims大教堂内景，位于巴黎的Reims是建筑史上最富盛名的哥特式教堂建筑之一。自从设计师Jeand’Ordais制订蓝图以后，继任的8位建筑师都理解并遵从这一初始设计的原则，保持了概念的完整性，最终Reims成为无与伦比的艺术精品。概念完整性是系统设计中最重要的因素，尤其对大型软件系统来说，概念完整性是项目顺利完成的必要保障。人月神话——画蛇添足

设计者往往不肯放弃任何一个细枝末节的创意，从而堆砌出不胜繁复的设计，看似完美，并现实无可行性，往往会成为头重脚轻的空中楼阁。软件项目的规划必须进行严谨理性的估算才能为项目的顺利进展打下牢固的根基，避免不必要的复杂化风险。图为1882年画家A.rOBIDA发表于比利时《二十一世纪报》上的插画：一个想象中极尽复杂的活动空中楼阁人月神话——贯彻执行

图为14世纪宗教湿壁画Wells启示录中的七天使号手号角声在七位天使间依次传递，前一位吹响后，后一位将照样吹响下一声，有条不絮，号角传递得十分精准。团队间沟通顺畅有序，只有这样，概念完整性才能被正确贯彻到各处人月神话——

为什么巴比伦塔会失败

图为维也纳Kunsthistorisches博物馆馆藏的16世纪奥地利兄弟画家中大Breughel所绘“巴别塔的建造”。在基督教传说中，人类打算建筑一座通往天堂的巴别塔，上帝使人类各族语言不通，才阻止了这项工程。在软件开发中，也许现有的技术已经可以所向披靡，但如果整个团队不能进行良好有效地沟通，项目就有可能功败垂成。人月神话——胸有成竹

图为美国历史上最伟大的职业棒球运动员贝比.鲁斯（BabeRuth）在球场上发号施令。有效的管理和决策是致胜的关键。人月神话——

削足适履

图为维多利亚时期英国画家HeywoodHardy的作品，在大洪水到来之前，飞禽走兽们进入诺亚方舟。在有限的空间中装载整个世界，这需要精巧的策划，绝不可轻易耗费资源。最大化资源利用率，减少不必要的资源占用，合理规划，巧妙的数据结构往往大幅度地俭省资源耗费，提高系统运行的性能。人月神话——

提纲挈领图为1897年美国老国会图书馆内景。作者以汗牛充栋的图书馆形象地比如软件项目中海量的文档令人目不暇接。明智地把握好关键的几类文档，才能不在浩瀚的信息中迷失，才能迅速了解项目，进而准确地规划下一步工作。人月神话——未雨绸缪

图为纽约湾的Tacoma桥由于空气动力学上的错误设计而坍塌的新闻照片在做项目设计和规划时，一定要考虑到各种不确定的变化因素，灵活适应多变的环境，否则很可能酿成悲剧后果。人月神话——干将莫邪图为佛罗伦萨著名的圣母百花大教堂钟楼上的装饰浮雕——A.Pisano于1335年制作的“雕刻者”。“工欲善其事，必先利其器”适合的开发工具、评测技术能有事半功倍的效果，切合实用的工具和技术是项目团队的重要财富。人月神话——整体部分

图为迪士尼公司著名的米老鼠魔术师形象。作者认为某些泛泛号称自己能完成庞大软件项目的业界人士，与旧时以夸张吹嘘来吸引观众注意的魔术师一样，其表演的东西经不起实质追究。良好的软件项目管理，应该准确把握全局，严谨审核细节。人月神话——另外一面

图为位于英格兰东南部的巨石阵的想象复原图。巨石阵是世界上最大的没有文档说明的“计算机器”。古人没留下任何说明，至今考古学家对古人建巨石阵的目的莫衷一是。提供给用户的使用说明等文档是软件呈现给用户的另一面，它也能直接影响用户对软件的满意度和可用性评价。人月神话——祸起萧墙

图为1802年A.Canova所作雕塑：英雄海格力斯（Herculues）摔死带来死亡之袍的信使力卡斯（Lycas）。海格力斯是希腊神话中最伟大的半人半神英雄，一生业绩辉煌，却因微小的家庭变故摔死不知情的力卡斯而走向了英雄末路。潜藏的小祸患看似微不足道，有朝一日却可能葬送原本看起来坚不可摧的事物。项目进度的滞后经常源自不易擦觉的点滴延误的积累。应尽量明确量化阶段性目标，定期验收、调整。没有银弹-软件工程中的根本和次要问题

图为1685年德国线刻板画的人狼故事是否存在消灭人狼的法宝——银弹？由于软件的复杂性、一致性、变化性和不可见性，解决软件危机的银弹并不存在没有任何一种单独的软件工程可以让软件开发的效率提高一个数量级。银弹人狼“焦油坑”危机软件项目消灭攻克银弹之争无风不起浪：一篇《没有银弹》在学术界掀起了一场不大不小的风浪，从而引发了再论“没有银弹”。再论“没有银弹”

图为儿童在搭建组合构造玩具。利用成型的配件，搭建大型的架构。完美的东西其实就是过去不曾出现、现在不存在、将来也不可能出现的东西：不要指望《没有银弹》是完美的。《没有银弹》中提到的观点是以10年为限的。本章结合软件工程领域的最新发展，包括面向对象技术和软件复用等回应了争议：人们期待的重大突破不可能在近期内到来。是否存在终极利器？--银弹之争人狼、银弹与软件项目人狼：满月时会由人形变成狼形的怪兽。银弹：唯一可以杀死人狼的武器。软件项目：类似于人狼，常常看似简单明了的东西，却有可能变成一个落后进度、超出预算、存在大量缺陷的怪物。是否存在终极利器？--银弹之争没有银弹（“NoSilverBull