四
四库全书
Unregistered / Unconfirmed
GUEST, unregistred user!
----------- 程序员工作量的讨论 -----------------
介绍
出版于1975 年的《人月神话》是软件开发方面的经典作品。1995 年版包括了令人感兴趣的
新的几章，但原
来的随笔依然是这本书的心脏与灵魂。在这本书中，Brooks(注《人月神话》作者) 解决了如何
组织和管理大规模编程项目的问题。这些
项目要求成百上千的程序员，产生几百万行代码（想想SAP、Oracle 数据库引擎、Windows2000
）。这部书由一系
列简明的随笔组成。在这篇评论中我将讨论开篇随笔――我的最爱之一。
焦油坑
Brooks 将大系统编程作比喻作史前的焦油坑来开始他的第一篇随笔：“记忆中，我们看到恐龙
、猛犸象、剑
齿虎正在挣脱沥青的魔爪。挣扎得越剧烈，陷入的越深，没有哪只野兽足够强壮或熟练，它们最
终都沉没了。大
系统编程在过去的十年间就像焦油坑，许多大而强有力的野兽在其中已经惨烈地失败了。大部分
已实现并在运行
的系统，很少有达到目标、时间表和预算的。大和小、厚重和细实，一个接一个的团队卷入了沥
青（陷阱）。没有
什么事情似乎会导致这个困难――任何特殊的手掌都能被拉出来。但同时并相互作用的因数的相
互聚集导致运动
越来越慢。每个人似乎都惊讶于问题的难缠，难于面对它的本质。”
记住，这些话写于1975 年。今天它们仍然可用吗？考虑一下WindowsNT5.0。第一次计划于1997
年发布，随后延迟到1998 年早期，1998 年末，然后是1999 年（为此它被重新命名为Windows2000）。这儿
是一些公开的估计：
5,000 程序员。
35,000,000 行代码。
显然，NT5.0 是个大系统编程项目。同样显而易见，Brooks 的焦油坑在今天同1975 年一样普遍
！
让我们继续NT5.0 的例子。假设最糟糕的情况，全部35,000,000 行代码都是新编的。有理由假
设开发工作大致在1994 年开始。所以我们有：
5,000 程序员 X 5 年= 25,000 程序员年
35,000,000 行代码/ 25,000 程序员年= 1,400 行／程序员年。
如果你是个程序员，或者你只接受过编程课程的教育，这个数字（1,400 行每年）似乎令人惊异
的低。我们当
中的大部分人都能在一两天内堆积出接近一千行的代码。什么使得Microsoft 的程序员一整年才
产出1,400 行代
码？
两种可能性跃入我们的脑海：
Microsoft 雇用了5,000 名不合格的程序员去开发NT 5.0。
或者
写一个大规模的程序系统产品远难于堆砌出单一的程序。
Brooks 将讨论认为后一个答案是正确的。他由定义术语开始：
（1）程序
一个独立的程序是我们两天编程狂欢的结果。它是准备自己运行于我们编程的那台机器上的。如
果我们加上
文档、通用化代码、编写测试用例、使得代码可以由其他无关的编程人员来维护，我们就有了：
（2）程序产品
另外，如果我们接受我们的程序，并且完整地定义了它的接口使得它达到预定义的规范，并且测
试了它和大
量的其它组件的交互作用，我们就有：
（3）程序系统组件
并且如果我们都做了（加上文档、通用化代码、编写测试用例、使得代码可维护、定义了接口、
测试了交互
作用），我们就有：
（4）程序系统产品组件
Brooks 用手边的三倍规则说明在上述每个步骤中的工作要求：
（2）＝3 倍（1）的人力
（3）＝3 倍（1）的人力
（4）＝9 倍（1）的人力
或者，换句话说，开发一个独立的程序仅仅要求开发一个程序系统组件的1／9 的人力。
回到Microsoft 的例子，如果我们将这个9 倍的因子乘以1,400 行每程序员年的生产力测量，我
们得到12,600
行每程序员年（举例来说，假设我们掌握每一程序员，并且使得他们独立工作，堆砌在单一的程
序上）。在一篇独
立的随笔中，Brooks 引用一个发现这点的经理的话说，平均他的每个程序员仅能将他的一半时
间用于开发――其
它时间由文书工作、会议和各种其它任务所占据。把这些因素考虑到Microsoft 的例子中，我们
达到了25,200 行
每程序员年。那么，Microsoft 的程序员开始看来非常可敬。另一个测量自1975 年来有了很小
的改变，Brooks 引
用的估计是1,000 行每程序员年。如果上面引用的1,400 行每程序员年是精确的，那么，它表现
了在1975 年到1995
年20 年间，生产力仅仅提升了1.75%每年。这个结果证实了Brooks 的另一个假定――程序员的
生产力相对是个
常量，它不受开发所用的语言的影响。因此，实际的生产力收获来自于迁移到高级语言编程，这
些语言每行表达
了更多的实际工作。尽管目标是大系统项目，Brooks 的解释常常被广泛的应用。例如，这个第
一篇随笔用标有“手
艺的快乐”和“手艺的悲哀”的小节来结束。在悲哀中，他讨论了荒废的问题：
“…这个人们已经工作了很长时间的产品，显然在完成前将被废弃。同事和竞争者已经在热烈地
用新的和更
好的主意反击。人们的孩童般想法的取代已经不仅仅在构思，而且付诸时间表。这一切总是似乎
比它的实际更糟
糕。新的和更好的想法通常在完成之前不被应用；它仅仅被谈论。真老虎永远不能和纸老虎相比
。”
小结
Brooks 的随笔涉及到了大系统编程所固有的多种挑战，但对任何投身于软件开发的人来说读这
本书都是有用
的。题名的随笔（《人月神话》）讨论了许多编程任务的不可分割性，和为什么增加人力到软件
项目中无法产生效
用。我的另一篇最爱是“贵族、民主和系统设计”（概念完整性的讨论）和“计划和投放之路”
（在付运前多次交
付的明确计划的益处）。一些问题已经因为技术的进步而废弃，例如关于如何在一个大型团队中
分发写好的文档。
然而，你可能惊讶Brooks 面对的许多问题今天如何阻止我们。另外的益处是Brooks 简洁、清
晰的作品读起来令人愉快。如果你是个程序员，如果你和程序员一起工作，如果你管理程序员，
你应该阅读这本书。
－－－－摘自《人月神话》20 周年纪念版评论集Frank Chance的评论
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
各位dfw，对此有和看法，大家觉得3倍规则正确吗？
大家每年的代码量大约是多少呢？
介绍
出版于1975 年的《人月神话》是软件开发方面的经典作品。1995 年版包括了令人感兴趣的
新的几章，但原
来的随笔依然是这本书的心脏与灵魂。在这本书中，Brooks(注《人月神话》作者) 解决了如何
组织和管理大规模编程项目的问题。这些
项目要求成百上千的程序员，产生几百万行代码（想想SAP、Oracle 数据库引擎、Windows2000
）。这部书由一系
列简明的随笔组成。在这篇评论中我将讨论开篇随笔――我的最爱之一。
焦油坑
Brooks 将大系统编程作比喻作史前的焦油坑来开始他的第一篇随笔：“记忆中，我们看到恐龙
、猛犸象、剑
齿虎正在挣脱沥青的魔爪。挣扎得越剧烈，陷入的越深，没有哪只野兽足够强壮或熟练，它们最
终都沉没了。大
系统编程在过去的十年间就像焦油坑，许多大而强有力的野兽在其中已经惨烈地失败了。大部分
已实现并在运行
的系统，很少有达到目标、时间表和预算的。大和小、厚重和细实，一个接一个的团队卷入了沥
青（陷阱）。没有
什么事情似乎会导致这个困难――任何特殊的手掌都能被拉出来。但同时并相互作用的因数的相
互聚集导致运动
越来越慢。每个人似乎都惊讶于问题的难缠，难于面对它的本质。”
记住，这些话写于1975 年。今天它们仍然可用吗？考虑一下WindowsNT5.0。第一次计划于1997
年发布，随后延迟到1998 年早期，1998 年末，然后是1999 年（为此它被重新命名为Windows2000）。这儿
是一些公开的估计：
5,000 程序员。
35,000,000 行代码。
显然，NT5.0 是个大系统编程项目。同样显而易见，Brooks 的焦油坑在今天同1975 年一样普遍
！
让我们继续NT5.0 的例子。假设最糟糕的情况，全部35,000,000 行代码都是新编的。有理由假
设开发工作大致在1994 年开始。所以我们有：
5,000 程序员 X 5 年= 25,000 程序员年
35,000,000 行代码/ 25,000 程序员年= 1,400 行／程序员年。
如果你是个程序员，或者你只接受过编程课程的教育，这个数字（1,400 行每年）似乎令人惊异
的低。我们当
中的大部分人都能在一两天内堆积出接近一千行的代码。什么使得Microsoft 的程序员一整年才
产出1,400 行代
码？
两种可能性跃入我们的脑海：
Microsoft 雇用了5,000 名不合格的程序员去开发NT 5.0。
或者
写一个大规模的程序系统产品远难于堆砌出单一的程序。
Brooks 将讨论认为后一个答案是正确的。他由定义术语开始：
（1）程序
一个独立的程序是我们两天编程狂欢的结果。它是准备自己运行于我们编程的那台机器上的。如
果我们加上
文档、通用化代码、编写测试用例、使得代码可以由其他无关的编程人员来维护，我们就有了：
（2）程序产品
另外，如果我们接受我们的程序，并且完整地定义了它的接口使得它达到预定义的规范，并且测
试了它和大
量的其它组件的交互作用，我们就有：
（3）程序系统组件
并且如果我们都做了（加上文档、通用化代码、编写测试用例、使得代码可维护、定义了接口、
测试了交互
作用），我们就有：
（4）程序系统产品组件
Brooks 用手边的三倍规则说明在上述每个步骤中的工作要求：
（2）＝3 倍（1）的人力
（3）＝3 倍（1）的人力
（4）＝9 倍（1）的人力
或者，换句话说，开发一个独立的程序仅仅要求开发一个程序系统组件的1／9 的人力。
回到Microsoft 的例子，如果我们将这个9 倍的因子乘以1,400 行每程序员年的生产力测量，我
们得到12,600
行每程序员年（举例来说，假设我们掌握每一程序员，并且使得他们独立工作，堆砌在单一的程
序上）。在一篇独
立的随笔中，Brooks 引用一个发现这点的经理的话说，平均他的每个程序员仅能将他的一半时
间用于开发――其
它时间由文书工作、会议和各种其它任务所占据。把这些因素考虑到Microsoft 的例子中，我们
达到了25,200 行
每程序员年。那么，Microsoft 的程序员开始看来非常可敬。另一个测量自1975 年来有了很小
的改变，Brooks 引
用的估计是1,000 行每程序员年。如果上面引用的1,400 行每程序员年是精确的，那么，它表现
了在1975 年到1995
年20 年间，生产力仅仅提升了1.75%每年。这个结果证实了Brooks 的另一个假定――程序员的
生产力相对是个
常量，它不受开发所用的语言的影响。因此，实际的生产力收获来自于迁移到高级语言编程，这
些语言每行表达
了更多的实际工作。尽管目标是大系统项目，Brooks 的解释常常被广泛的应用。例如，这个第
一篇随笔用标有“手
艺的快乐”和“手艺的悲哀”的小节来结束。在悲哀中，他讨论了荒废的问题：
“…这个人们已经工作了很长时间的产品，显然在完成前将被废弃。同事和竞争者已经在热烈地
用新的和更
好的主意反击。人们的孩童般想法的取代已经不仅仅在构思，而且付诸时间表。这一切总是似乎
比它的实际更糟
糕。新的和更好的想法通常在完成之前不被应用；它仅仅被谈论。真老虎永远不能和纸老虎相比
。”
小结
Brooks 的随笔涉及到了大系统编程所固有的多种挑战，但对任何投身于软件开发的人来说读这
本书都是有用
的。题名的随笔（《人月神话》）讨论了许多编程任务的不可分割性，和为什么增加人力到软件
项目中无法产生效
用。我的另一篇最爱是“贵族、民主和系统设计”（概念完整性的讨论）和“计划和投放之路”
（在付运前多次交
付的明确计划的益处）。一些问题已经因为技术的进步而废弃，例如关于如何在一个大型团队中
分发写好的文档。
然而，你可能惊讶Brooks 面对的许多问题今天如何阻止我们。另外的益处是Brooks 简洁、清
晰的作品读起来令人愉快。如果你是个程序员，如果你和程序员一起工作，如果你管理程序员，
你应该阅读这本书。
－－－－摘自《人月神话》20 周年纪念版评论集Frank Chance的评论
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
各位dfw，对此有和看法，大家觉得3倍规则正确吗？
大家每年的代码量大约是多少呢？
][