有人负责,才有质量:写给在集市中迷失的一代

　　13年前，新兴的草根开源软件运动如火如荼，而Eric Raymond的《大教堂与集市》(O'Reilly Media, 2001)一书则重新定义了我们的词汇表，几乎预言了瀑布模型和大型软件公司的终结。这本书有煽动性，但却没有说服我。与此同时，由于我正全身心投入开源运动，也就情不自禁地宁愿相信他是对的。

　　而今年夏天我带到海滨别墅来的这本书，同样有煽动性，比Raymond那本更甚(但这本书在提到《大教堂与集市》时是相当正面的)，那就是Frederick P. Brooks的《设计原本》(Addison-Wesley Professional, 2010)。Brooks这本书不断引发我的共鸣，我也越来越佩服他的语言表达能力和他提出的观点，然而越是有共鸣，就越感到难过和失望。

　　13年前，正值.COM热潮涌动，年轻的Web程序员比比皆是，辍学创业的大学生也屡见不鲜。在向其中一些人传授过去那些编程技巧的同时，我也获得了很多乐趣。像什么测试恢复备份、写脚本安装操作系统、版本控制等等。当然，现在再看，也就那么回事(有些事并不像你印象中那么激动人心，对吧)。而且，我们已经无路可逃，整个.COM时代总体上对IT/CS而言就是一场灾难，尤其对软件质量和Unix来说，更是如此。

　　好像从来没有人分析过.COM泛滥那些年，IT行业增长了多少。以我个人的经验，我估计整个行业(包括IT行业由此新增的就业机会)大概增长了两个数量级，或者更确切地说，达到了原来的百分之一万(100倍)。

　　学会计算机编程很容易，就像学会用钉子把两块木板钉到一起一样简单。但问题是——打个不恰当的比方，市场对“钉在一起的两块木板”的需求，除了“自豪的爷爷”的那点天伦之乐以外，真的是太小了。而且，由此再进一步学习钉椅子或做碗橱，都需要天分、实践和训练。我们增长的这99倍恰恰都来自那些既没有实践经验，又没有受过良好训练的人。等这些人有时间学习和接受训练了，聚会已然结束，大多数人失去了工作。可以乐观地假定那些坚持下来的人最有天分，而且经验也最多，即便如此我们还是无路可逃，因为作为IT专业人士，由于缺乏基本功，他们大多数都很滥!

　　不幸的是，Raymond鼓吹的——与.COM泡沫之前精心建造大教堂的理念恰恰相反的集市模因(meme)1——“对付过去就行”(just hack it)，并没有随.COM泡沫破裂灰飞烟灭。今天，Unix这艘大船正因为难堪重负而迅速沉没。

　　1 模因论是基于达尔文进化论的观点解释文化进化规律的新理论。参见这里。——译者注

　　我刚升级了自己的笔记本电脑。到现在，我运行FreeBSD开发版已经足足有18个年头了，但从源代码编译我的Spartan工作环境仍然要花一整天时间，因为它必须理清头绪，在Raymond那乱糟糟的软件集市中建起一座大教堂来。

　　宏观上讲，FreeBSD的Ports Collection会尽力为这个集市画一幅地图，以便FreeBSD用户轻易找到自己的应用。目前来看，这幅地图由22 198个文件构成，而这些文件就是集市中每个摊位的简要说明：用寥寥数语告诉你某个摊位卖什么，要了解详细信息再去哪里找。此外，还有23 214个Makefile，告诉你可以对每个摊位上的软件做什么。这些Makefile还想告诉你都有哪些选择，要选择什么，以及不作选择时用什么默认值比较明智。为方便起见，这幅地图还提供24 400个补丁文件，以便弥补这些玩艺儿在制作工艺上的瑕疵，但一般来说，还是因为它们携带(portability )不便，所以才催生了这些补丁。

　　最后，地图提供一些建设性意见，比如要是你想要www/firefox，那得先得到devel/nspr、security/nss、databases/sqlite3，等等。在你手拿地图，查到这些依赖，以及这些依赖的依赖之后，你会发现自己的购物清单上已经记满了122个包，你必须在能买www/firefox之前买全它们。

　　当然啦，模块化和代码重用都是好主意。可是，就算在最简单的情况下，CS/IT的代码重用信条在集市里也没有用武之地：FreeBSD Ports Collection中的软件最少都包含1342个复制粘贴加密算法。

　　如果有人奋不顾身或者偏听偏信，非要代码重用，结果真制造出了自身完备且无依赖的软件包，那要换得这个容易管理的包，享受代码重用的成果，就算多花点银子也值啊!但这样的事并没有发生过：各种包把Web搞得一团糟， 随便依赖，互相纠缠，代码越重用，浪费越严重。

　　举个浪费的例子吧。Sam Leffler的graphics/libtiff是前面提到在安装www/firefox之前必须安装的122个包中的一个，但安装后的Firefox浏览器却无法渲染TIFF图片。问题出在哪里我还没来得及查清楚，但这122个包中的10个需要Perl，7个需要Python;这其中又有一个devel/glib20，同时依赖着Perl和Python，至于为什么，我到现在都没想通。

　　继续往下看你的购物清单，你会不断发现满足彼得定律的应用。所谓彼得定律，就是说在一个根据人的业绩、成就和价值来提拔人的组织中，最终会把一些人提拔到他们并不胜任的位置上。这个定律经常被通俗地说成“把员工提拔到他们不胜任的职位”。软件行业也一样，你会发现自己需要三个不同版本的make程序、一个宏处理器、一个汇编器和其他一些必要的包。而在这个“食物链”末端，则是libtool，它试图掩盖一个事实，即在Unix中没有构建共享库的标准方式。的确没有适用于所有Unix变体的标准方式——比如给ld(1)命令加个标签之类的;而此时彼得定律就适用了：这个工作被交给了libtool。此时此刻，彼得定律确实牛，devel/libtool的源代码达到了414 740行，而其中有一半是测试用例。原则上讲，这倒是值得称赞的，但实际上这却是彼得定律的结果：这些测试煞费苦心地在那里验证一个本来就不该存在的问题的复杂方案是否功能齐备!更让人抓狂的是，其中31 085行代码都保存在一个叫configure的shell脚本里，代码格式之乱，任谁也难看明白。这样做是想让configure脚本执行大约200个自动测试，从而免除用户手工配置libtool之苦。这个想法很滥，早在1980年代刚刚出现时，就招来很多非议。因为源代码是靠configure脚本的伪装才让人感觉它可移植的，而实际上并非真正可移植。可以说它是配置思想的余孽。

原文转自：http://www.ltesting.net