<script type="text/javascript"><!--google_ad_client = "pub-0241434510974184";/* 博客文章广告728x90, */google_ad_slot = "7316585398";google_ad_width = 728;google_ad_height = 90;// --></script><script src="http://pagead2.googlesyndication.com/pagead/show_ads.js" type="text/javascript"></script>

不曾破灭的神话

本文发表于2002年12月《中华读书报》

十年以后，如果软件开发领域还有哪一个神话不曾破灭的话，那它一定是弗雷德里克·布鲁克斯先生为我们描绘的《人月神话》了。

当然，作为一名程序员，我晓得十年的时光对于软件开发来说意味着什么。不用上溯太远，仅仅在1965年，IBM的开发人员还在OS/360系统成堆的Bug里苦苦挣扎，到1975年时，贝尔实验室的专家们就已经为UNIX和C语言的迅速普及而沾沾自喜了；比尔·盖茨1985年时还在考虑是否为微软的操作系统引入鼠标和图形界面，但到了1995年，Netscape的浏览器就已经开始向纳斯达克和中关村的骨髓里灌注网络泡沫了。在这三四十年的时间里，各种各样的软件神话充斥了软件开发的每一个角落，但每一种神话又都在转瞬之间就走向幻灭和消亡。软件测试神话、Goto神话、面向对象神话以及B2C神话轮番占据主流刊物的大小版面，又轮番偃旗息鼓、销声匿迹，程序员们好像早已习惯了在一个现实与神话交替更迭的世界中生存。因此，当我们蓦然发现有一本关于软件开发的小书竟在20年里先后两次引发轰动效应的时候，我们似乎难以相信，看上去垂垂老矣的布鲁克斯先生居然可以让好几代程序员都沉浸在关于OS/360的那几个老故事里流连忘返。的确，在程序员的圈子里，对这本书的褒贬并不一致：有人还在对《人月神话》的软件工程专著的地位表示质疑，有人则在大肆宣扬印度的软件工程师们人手一本《人月神话》的不争事实。但无论如何，布鲁克斯先生对"人月"问题的精辟论证都会深深印在大多数人的脑海里，至少我本人是非常想在2025年看到《人月神话》的五十周年纪念版的。

从某种意义上说，1975年出版的《人月神话》更像是一份精致的项目总结报告。作为IBM史无前例的巨型软件系统--OS/360的项目经理，布鲁克斯有资格也有权利把项目中的成败总结出来，公之于众。尽管布鲁克斯这份总结报告的内容早已超出了OS/360项目的范围，延伸到了项目管理和软件工程的方方面面，但我还是乐于把这本书放在OS/360项目的大背景中去阅读--毕竟蓝色巨人IBM在巨型项目中深陷泥潭的情形并不多见，毕竟OS/360系统早已成为了众所周知的软件工程萌芽和发展的代名词。仅仅从项目总结的角度来看，布鲁克斯的分析和论断也是相当深刻和颇具建设性的。想像一下，既然1975年的布鲁克斯就已经说过，3个人4个月的工作和12个人1个月的工作绝不能划上等号，那我们为什么直到今天还在用"人月"的简单换算关系来计算工期，安排进度呢？既然1975年的布鲁克斯就已经为我们介绍了克服时间压力和团队合作之间矛盾的有效方法，我们为什么还会在今天的产品开发中屡屡延期交付呢？既然布鲁克斯早就提醒过我们要注意软件开发中普遍存在和频繁出现的目标舍弃、功能调整、预算紧缩等变数，我们为什么还总能在项目计划阶段保持乐观，蔑视一切潜在的风险呢？也许，我们应该重新跟着布鲁克斯先生，走进OS/360项目的迷宫里，重温一下20世纪60年代那几千个充满激情和梦魇的日子。中国人说，"以古为鉴，可知兴替"，我想，《人月神话》大概就是这样一本关于软件开发的"青铜时代"的断代史吧。

今天我们看到的《人月神话》是1995年出版的二十周年纪念版。与20年前的版本相比，新的《人月神话》增加了《没有银弹》等几篇文章，并在原有章节中补充了许多新的内容。我是这么理解"二十周年纪念版"的含义的：布鲁克斯先生并不想仅仅提供一份精美绝伦的项目总结报告了事，如果是那样的话，《人月神话》恐怕就会更多地偏向技术性的阐述，而不会拥有现在这种通俗、晓畅的文风了；布鲁克斯肯定希望能通过再版时的修订和增补，将全书的主旨升华到一个更普遍、更有代表性的层面上来。举例来说，新增的《没有银弹》虽然算不上是一篇新文章，但它在全书中的地位却是举足轻重的：对于一本先后阐述了进度管理、角色划分、管控机制、团队沟通、软件度量、文档编撰、设计理念、风险管理等软件工程基本概念、基本技巧的书籍来说，能有一篇高屋建瓴、提纲挈领的文字，帮读者在掩卷之前收摄心神、理清思路，这倒是一件至关重要的事情；而且，无论从何种意义上说，《没有银弹》一文所提出的理念对全书而言都可以起到画龙点睛的作用--概括地讲，《没有银弹》试图在软件工程的神话和现实这两种完全不同的情境之间，寻找到一个对于大多数人都普遍适用的平衡点，当然，这种努力的结果目前还无法预见，也许那是一条通向天国的捷径，也许那只是另一个充满梦幻色彩的神话罢了。

十年以前，我根本不愿相信，在软件开发领域除了编程以外，还有一门叫做软件工程的学问；五年以前，我做梦都想成为软件工程专家，并且执著地认为，软件工程可以解决我在开发中遇到的一切难题；今天，我忽然意识到我此前的每一种确定无疑的想法都仿佛是一种虚幻的神话，可望而不可及。或许，我在认识上的改变是因为看了《人月神话》的缘故，或许，我和所有程序员一样，都正在期待着一种永不破灭的神话吧。

[王咏刚，2002年12月]