天天小说网

《人月神话》的观点:是或非?(Propositions of the Mythical Man-Month: True or False?)

我们理解的也好,不理解的也好,描述都应该简短精练。

塞缪尔·巴特勒,讽刺诗

For brevity is very good, where we are, or are not understood.

SAMUEL BUTLER Hudibras

现在我们对软件工程的了解比 1975 年要多得多。那么在 1975 年版本的人月神话中,哪些观点得到了数据和经验的支持?哪些观点被证明是不正确的?又有哪些观点随着世界的变化,显得陈旧过时呢?为了帮助判断,我将 1975 年书籍中的论断毫无更改地抽取出来,以摘要的形式列举在下面——它们是当年我认为将会是正确的:客观事实和经验中推广的法则。(你也许会问,“如果这些就是那本书讲的所有东西,为什么要花 177 页的篇幅来论述?”)方括号中的评论是新增内容。

所有这些观点都是可操作验证的,我将它们表达成刻板的形式是希望能引起读者的思考、判断和讨论。

第 1 章 焦油坑

1.1 编程系统产品(Programming Systems Product)开发的工作量是供个人使用的、独立开发的构件程序的九倍。我估计软件构件产品化引起了 3 倍工作量,将软件构件整合成完整系统所需要的设计、集成和测试又强加了 3 倍的工作量,这些高成本的构件在根本上是相互独立的。

1.2 编程行业“满足我们内心深处的创造渴望和愉悦所有人的共有情感”,提供了五种 乐趣:

◆ 创建事物的快乐

◆ 开发对其他人有用的东西的乐趣

◆ 将可以活动、相互啮合的零部件组装成类似迷宫的东西,这个过程所体现出令人神魂颠倒的魅力

◆ 面对不重复的任务,不间断学习的乐趣

◆ 工作在如此易于驾驭的介质上的乐趣——纯粹的思维活动,其存在、移动和运转方式完全不同于实际物体

1.3 同样,这个行业具有一些内在固有的苦恼:

◆ 将做事方式调整到追求完美,是学习编程的最困难部分

◆ 由其他人来设定目标,并且必须依靠自己无法控制的事物(特别是程序);权威不等同于责任

◆ 实际情况看起来要比这一点好一些:真正的权威来自于每次任务的完成

◆ 任何创造性活动都伴随着枯燥艰苦的劳动,编程也不例外

◆ 人们通常期望项目在接近结束时,(bug、工作时间)能收敛得快一些,然而软件项目的情况却是越接近完成,收敛得越慢

◆ 产品在即将完成时总面临着陈旧过时的威胁

第 2 章 人月神话

2.1 缺乏合理的时间进度是造成项目滞后的最主要原因,它比其他所有因素加起来影响还大。

2.2 良好的烹饪需要时间,某些任务无法在不损害结果的情况下加快速度。

2.3 所有的编程人员都是乐观主义者:“一切都将运作良好”。

2.4 由于编程人员通过纯粹的思维活动来开发,所以我们期待在实现过程中不会碰到困难。

2.5 但是,我们的构思是有缺陷的,因此总会有 bug。

2.6 我们围绕成本核算的估计技术,混淆了工作量和项目进展。人月是危险和带有欺骗性的神话,因为它暗示人员数量和时间是可以相互替换的。

2.7 在若干人员中分解任务会引发额外的沟通工作量——培训和相互沟通。

2.8 关于进度安排,我的经验是为 1/3 计划、1/6 编码、1/4 构件测试以及 1/4 系统测试。

2.9 作为一个学科,我们缺乏数据估计。

2.10 因为我们对自己的估计技术不确定,所以在管理和客户的压力下,我们常常缺乏坚持的勇气。

2.11 Brook 法则:向进度落后的项目中增加人手,只会使进度更加落后。

2.12 向软件项目中增派人手从三个方面增加了项目必要的总体工作量:任务重新分配本身和所造成的工作中断;培训新人员;额外的相互沟通。

第 3 章 外科手术队伍

3.1 同样有两年经验而且在受到同样的培训的情况下,优秀的专业程序员的工作效率是较差程序员的十倍。(Sackman、Erikson 和 Grand)

3.2 Sackman、Erikson 和 Grand 的数据显示经验和实际表现之间没有相互联系。我怀疑这种现象是否普遍成立。

3.3 小型、精干队伍是最好的——尽可能的少。

3.4 两个人的团队,其中一个项目经理,常常是最佳的人员使用方法。[留意一下上帝对婚姻的设计。]

3.5 对于真正意义上的大型系统,小型精干的队伍太慢了。

3.6 实际上,绝大多数大型编程系统的经验显示出,一拥而上的开发方法是高成本、速度缓慢、不充分的,开发出的产品无法进行概念上的集成。

3.7 一位首席程序员、类似于外科手术队伍的团队架构提供了一种方法——既能获得由少数头脑产生的产品完整性,又能得到多位协助人员的总体生产率,还彻底地减少了沟通的工作量。

第 4 章 贵族专制、民主政治和系统设计

4.1 “概念完整性是系统设计中最重要的考虑因素”。

4.2 “功能与理解上的复杂程度的比值才是系统设计的最终测试标准”,而不仅仅是丰富的功能。[该比

更多内容加载中...请稍候...

若您看到此段落,代表章节内容加载失败,请关闭浏览器的阅读模式、畅读模式、小说模式,以及关闭广告屏蔽功能,或复制网址到其他浏览器阅读!