有人負責，才有質量：寫給在集市中迷失的一代

原文：A Generation Lost in the Bazaar （發表於 ACM Queue vol. 10, no. 8, 2012）
作者：保爾－亨寧·凱普（Poul-Henning Kamp） 翻譯：@李鬆峰
感謝 @蔡學鏞 @蔣濤CSDN 老師在新浪微博上推薦

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指令碼的偽裝才讓人感覺它可移植的，而實際上並非真正可移植。可以說它是配置思想的餘孽。

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行程式碼仍然還要檢測<sys/stat.h>和<stdlib.h>是否存在，即便是沒有這兩個檔案的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這樣大訪問量網站的響應速度。

譯文原址：https://www.ituring.com.cn/article/9363