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

　　1980年代出现过很多不同的Unix实现：Cray-1s及其24位指针、Amdahl UTS主机Unix、来自微机制造商的大量的SysV+BSD混搭、Data General等公司开发的准Unix“垫片”，甚至连油漆厂Mark Williams都有纯粹的Unix克隆Coherent。

　　当时的configure脚本是手写的，用于检测当前系统是BSD还是SysV风格的Unix，然后根据检测结果把一个或另一个Makefile(有时候还带一个.h文件)复制到指定位置。后来，这个configure脚本的神通越来越大，而且不折不扣地印证了彼得定律。我们没有看到Unix采用标准做法来消除对该脚本的依赖，反倒是有人写了一个叫autoconf的程序，用来自动生成configure脚本。

　　今天，Unix/Posix一脉的操作系统，就连IBM的z/OS主机版，都跟1980年代那些完全一样;libtool这个configure脚本中的31 085行代码仍然还要检测和是否存在，即便是没有这两个文件的Unix变体，在既没有足够内存执行libtool，也没有足够硬盘保存其16MB源代码的情况下。

　　为什么会这样呢?

　　由于尚不知晓的原因，autoconf是用晦涩的M4宏语言写的，因而实际的测试代码如下：

　　## Whether `make' supports order-only prerequisites.

　　AC_CACHE_CHECK([whether ${MAKE-make} supports order-only prerequisites],

　　[lt_cv_make_order_only],

　　[mkdir conftest.dir

　　cd conftest.dir

　　touch b

　　touch a

　　cat >confmk << 'END'

　　a: b | c

　　a b c:

　　touch $[]@

　　END

　　touch c

　　if ${MAKE-make} -s -q -f confmk >/dev/null 2>&1; then

　　lt_cv_make_order_only=yes

　　else

　　lt_cv_make_order_only=no

　　fi

　　cd ..

　　rm -rf conftest.dir

　　])

　　if test $lt_cv_make_order_only = yes; then

　　ORDER='|'

　　else

　　ORDER=''

　　fi

　　AC_SUBST([ORDER])

　　毋庸讳言，这超出了大多数程序员的承受能力。即便有人有这个能力，但给autoconf指定输入文件都是用复制粘贴的，所以那些涵盖前述“标准测试”的标准宏代码日益膨胀也就很难被发现，而这些宏都是为了处理20年前并不存在的兼容性问题。

　　我一直不明白：为什么针对我系统里根本没有的Fortan编译器，但libtool的配置探针仍然有不少于26个名字，而且还要再执行26个测试，检测这些根本不存在的Fortran编译器分别支不支持-g选项。也许这就是原因所在。

　　这是由Raymond在其书中称颂的集市模式导致的悲哀的现实：一坨脓包似的权宜代码，被一群盲目的根本不知IT架构为何物的所谓IT“专业人士”永无休止地复制着，粘贴着。这事儿放在今天你也许很难相信，但就是在这令人无比尴尬的混沌之下，沉睡着美轮美奂的Unix大教堂的遗迹，而Unix恰恰是以设计简约、功能实用、执行优雅而著称于世的。(世间荣耀就此消失……)

　　Brooks提出了很多有见地的观点，其中一个就是所谓质量，只有在某人对它负责时才有意义，而这个“某人”只能是一个人，不能是几个人——二重奏除外。我有点奇怪，为什么Brooks不把Unix作为他这个观点的论据，因为我们可以精确地指出Unix开始走向碎片化的时间点：1990年代初，AT&T抛弃Unix，将其商业化，抢走其架构师的那一刻。

　　最近几年，不止一个人像Brooks一样得出相同的结论。有些人企图粉饰太平，假装正经，还有人通过制定技术标准的形式来达到类似立法的目的，希冀着在集市中引入秩序和结构。到目前为止，他们的努力全部以失败告终，因为在集市中迷失的这一代.COM神奇小子，从来就没有见过大教堂，也不可能知道你为什么需要大教堂，更不用说去想象教堂是个什么样子了。这么挖苦别人，其实我心里也很难过。真的，那些最需要看看《设计原本》的人，可能会发现这本书完全无法理解。但对于那些怀疑过构建一个Web浏览器居然要使用M4宏来配置autoconf，要写shell脚本，要检测26种Fortran编译器，而且又觉得这怎么说都有点南辕北辙的人，Brooks也谨慎地指出了方向：还有更好的方式。

　　作者简介：Poul-Henning Kamp (phk@FreeBSD.org) ，26年的计算机程序员，个人网站http://bikeshed.org。他编写的软件以底层构建块的形式被开源和商业产品广泛采用。他最近正在做的项目叫Varnish HTTP加速器，用来加快Facebook这样大访问量网站的响应速度。

　　(译文完)

　　微博评论选摘一(时间戳：2012-08-23 12:56)

　　@出版人周筠

　　或可对比读一读这篇“敏捷的酒后问答”：http://t.cn/hdrXFY 一味地肯定开源，和一味地肯定商业，maybe是上坡和下坡，走的是一条路，是时候该转弯了 (今天 08:34)

　　@陈茂9811

　　主要是《市集与大教堂》里面高估了农民修建市集的能力。等等看吧貌似西方的现实生活，市集早就被Mall取代了。市集的效率远远不如大教堂。 (今天 08:51)

　　@玉伯也叫射雕

　　@李松峰 翻译的这篇文章不错 http://t.cn/zWRmdWu 对于前端来说，我们需要大教堂(YUI 等)，也需要集市(jQuery 插件社区)，更需要有品质保障的优质商场(Arale 2)。(今天09:41)

　　@简悦云风

　　"所谓质量，只有在某人对它负责时才有意义，而这个“某人”只能是一个人". 努力迅速无错的制造轮子, 你就可以对所有部分的质量负责. 去掉无所谓的依赖. 保持简洁. 当你想要一个特性时,自己写一个, 而不是去找一个现成的将就. 就可以避免臃肿的系统了. (今天 10:37)

　　"代码越重用，浪费越严重". 要用的时候就写一个. 提高自己编写代码速度, 想要什么, 迅速做一个出来才是王道啊. 这样就不会有依赖, 不会有纠缠, 不会有浪费. (今天 10:45)

　　回复@卷毛-雅布齐:问题在于设计一个封装良好的接口需要的能力和时间以及经验, 比实现一个恰巧对付,且仅满足你当下需求的模块要难的多,需要反复的时间多的多. 大多数和你项目无关的前人做的东西都达不到要求. 当然两者都是需要努力的. //@卷毛-雅布齐:如果封装得好，完全可以重用啊，节约开发时间。(今天 11:24)

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