《人月神话》各章.docxVIP

人月神话》各章精选 第 1 章 焦油坑 史前史中，没有别的场景比巨兽在焦油坑中垂死挣扎的场面更令人震撼。上帝见证着恐龙、 猛犸象、剑齿虎在焦油中挣扎。它们挣扎得越是猛烈，焦油纠缠得越紧，没有任何猛兽足够 强壮或具有足够的技巧，能够挣脱束缚，它们最后都沉到了坑底。 过去几十年的大型系统开发就犹如这样一个焦油坑，很多大型和强壮的动物在其中剧烈地挣 扎。他们中大多数开发出了可运行的系统——不过，其中只有非常少数的项目满足了目标、 时间进度和预算的要求。各种团队，大型的和小型的，庞杂的和精干的，一个接一个淹没在 了焦油坑中。表面上看起来好像没有任何一个单独的问题会导致困难，每个都能被解决，但 是当它们相互纠缠和累积在一起的时候， 团队的行动就会变得越来越慢。 对问题的麻烦程度， 每个人似乎都会感到惊讶，并且很难看清问题的本质。不过，如果我们想解决问题，就必须 试图先去理解它。 第 2 章 人月神话 Brooks 法则： 向进度落后的项目中增加人手，只会使进度更加落后。 第 3 章 外科手术队伍 在计算机领域的会议中，常常听到年轻的软件经理声称他们喜欢由头等人才组成的小型、精 干的队伍，而不是那些几百人的大型团队，这里的“人”当然暗指平庸的程序员。其实我们 也经常有相同的看法。 但这种幼稚的观点回避了一个很困难的问题——如何在有意义的时间进度内创建大型的系统 那么就让我们现在来仔细讨论一下这个问题的每一个方面。 第 4 章 贵族专制、民主政治和系统设计 设计法国城市兰斯(Reims)在建筑风格上的一致性和上面所说的大教堂形成了鲜明的对比。 设计 的一致性和那些独到之处一样，同样让人们赞叹和喜悦。如同旅游指南所述，风格的一致和 完整性来自 8 代拥有自我约束和牺牲精神的建筑师们， 他们每一个人牺牲了自己的一些创意， 以获得纯粹的设计。同样，这不仅显示了上帝的荣耀，同时也体现了他拯救那些沉醉在自我 骄傲中的人们的力量。 第 5 章 画蛇添足 在开发第一个系统时，结构师倾向于精炼和简洁。他知道自己对正在进行的任务不够了解， 所以他会谨慎仔细地工作。 在设计第一个项目时，他会面对不断产生的装饰和润色功能。这些功能都被搁置在一边，作 为“下一个”项目的内容。第一个项目迟早会结束，而此时的结构师，对这类系统充满了十 足的信心，熟练掌握了相应的知识，并且时刻准备开发第二个系统。 第二个系统是设计师们所设计的最危险的系统。 第 6 章 贯彻执行 假设一个项目经理已经拥有行事规范的结构师和许多编程实现人员，那么他如何确保每个人 听从、理解并实现结构师的决策对于一个由 1000 人开发的系统，一个 10个结构师的小组如 何保持系统概念上的完整性在 System/360 硬件设计工作中， 我们摸索出来一套实现上述目标 的方法，它们对于软件项目同样适用。 第 7 章 为什么巴比伦塔会失败 那么，既然他们具备了所有的这些条件，为什么项目还会失败呢他们还缺乏些什么两个方面 ——交流，以及交流的结果——组织。他们无法相互交谈，从而无法合作。当合作无法进行 时，工作陷入了停顿。通过史书的字里行间，我们推测交流的缺乏导致了争辩、沮丧和群体 猜忌。很快，部落开始分裂——大家选择了孤立，而不是互相争吵。 第 8 章 胸有成竹 系统编程需要花费多长的时间需要多少的工作量如何进行估计 第 9 章 削足适履 创造出自精湛的技艺，精炼、充分和快速的程序也是如此。技艺改进的结果往往是战略上的 突破， 而不仅仅是技巧上的提高。 这种战略上突破有时是一种新的算法， 如快速傅立叶变换， 或者是将比较算法的复杂度从 n2 降低到 n log n 。 更普遍的是，战略上突破常来自数据或表的重新表达——这是程序的核心所在。 第 10 章 提纲挈领 我记得曾经有一个项目，在三年的开发周期中，机器指令计数器的设计每六个月变化一次。 在某个阶段，需要好一点的性能时，指令计数器采用触发器来实现；下一个阶段，成本降低 是主要的焦点，指令计数器采用内存来实现。在另一个项目中，我所见过的最好的一个项目 经理常常充当一个大型调速轮的角色，他的惯性降低了来自市场和管理人员的起伏波动。 第 11 章 未雨绸缪 因此，管理上的问题不再是“是否构建一个试验性的系统，然后抛弃它”你必须这样做。现 在的问题是“是否预先计划抛弃原型的开发，或者是否将该原型发布给用户”从这个角度看 待问题，答案更加清晰。将原型发布给用户，可以获得时间，但是它的代价高昂——对于用 户，使用极度痛苦；对于重新开发的人员，分散了精力；对于产品，影响了声誉，即使最好 的再设计也难以挽回名声。 因此，为舍弃而计划，无论如何，你一定要这样做。 第 12 章 干将莫邪 就工具而言，即使是现在，很多软件项目仍然像一家五金店。每个骨干人员都仔细地保管自 己工作