《人月神话》各章精选

无双

转自uml china

第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年前软件开发经验的书，如何能够依然和现实情况相关？更不用说有所帮助了。

无双

项目并不总是增加人就可以解决问题的
那么各位做项目时是什么统计要使用的时间呢

一无所有
我想你应该做过不少项目

你平时什么决定项目要使用的时间的
特别是不熟悉的项目的话

一无所有

无双兄太客气了，
   项目需要用的时间，我们一般是在做完需求分析后，
   根据以前项目的经验，当前人员情况做出一个项目完成时间的
   实际上做完需求后，就基本上可以安排各阶段的时间图。

无双

对于熟悉的项目可以这样
但是比较不熟悉的项目的话就比较难把握

客户的需求总是会改变
可能现在的需求是这样
但是下一个版本的新需求要对整个软件结构的重写

还有
许多问题在测试过程中出现而影响了项目的进程

如果有这种情况的话
你怎么处理呢

gadfly

一般来说需求分析做好以后，就不应该产生要求结构变化的需求了

我觉得如果到了软件的结构需要重写的话, 这个项目就需要重新计划了

至于测试出现问题，我想一般在做项目计划的时候，就应该有个时间富余量的估计, 也就是说估计能多长时间做完，实际制定计划的时候, 得增加一定的百分比

无双

有时需求是变动的
就是说以后客户可能还会提出更多的要求
而且认为在做商用软件（专门给单位做的）的话
这种情况应该比较普遍

也有可能是在软件已完成，并交货后过了几个月用户要求下一个版本支持新功能
这种情况下当然可以重写一个，但是会浪费很多的人力物力，而且客户也未必想让你有时间重写，可能要的很急

我觉得设计一个软件时这方面应该考虑

至于测试问题
许多问题在代码整合后会发现，而且在改了旧bug后也可能引发新BUG

还有就是在真实情况或是大负荷测试时
也会发现软件的问题

在现实情况比较难模拟的条件下，测试时间比较难把握吧

gadfly

如果是需求发生大的变化，就看你已开发出软件框架能否适应这种变化。我觉得只要框架本身不需要做大的改动，那这个新版本的工作量、开发时间就可估算，质量也能有所保证。这实际上对系统架构的设计有比较高的要求。另外子系统的通用性和可复用性也是一个很重要的因素。

测试的目的就是尽可能的发现软件中的问题, 生产出高质量的软件产品。

设计完成后就得规划好测试计划，包括集成测试，系统测试，
安全性测试，性能测试，压力测试等。测试是一项很有技巧性，有难度的工作，
测试组长必须是有一定测试经验，并且得熟悉整个的系统设计。不过感觉上许多公司对测试的重视程度并不高。

无双

中型以上的公司都重视测试的

需求变化时最可怕的就是要求软件框架变化

如果框架变化的话那么可重用的代码就比较少，所以工作量很大。因此开始时应该怎样设计框架很重要，如果对一个行业不熟悉的话，很难一下子做出合适的框架来
另外使用C++面向对象编程可以在框架变化时可重用更多的代码，还有就是要求模块之间关联不要太强，正确的划分模块也很重要

软件框架不变化时，如果要做比较大的改动
那么时间也比较难把握
主要是代码的关联性，就是改了一个地方后，其它地方可能会出现问题
同样由于代码经过多次修改，原来的良好结构会被破坏，因此维护会变得困难
XP编程中提倡的代码重构就是这了这个原因

所以总的来说
要使软件维护可控，可维护，开始时的软件设计很重要，并且应该适当的划分模块，减少模块间依赖性
另外为了以后的维护方便，也应该写适量文档,以及代码注释

当发现软件结构越来越复杂时
适时的重构是有必要的（对中小软件）

pallam

请问楼上的，哪儿有《人月神话》的全部下载？

无双

没有找到
找到了告诉我一声