模板
教程
環境
性能
功能
管理
有人負責,才有質量:寫給在集市中迷失的一代(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)
