文章來源：https://m.ituring.com.cn/article/9363

13年前，新興的草根開源軟件運動如火如荼，而Eric Raymond的《大教堂與集市》（O'Reilly Media, 2001）一書則重新定義了我們的詞匯表，幾乎預言了瀑布模型和大型軟件公司的終結。這本書有煽動性，但卻沒有說服我。與此同時，由于我正全身心投入開源運動，也就情不自禁地寧愿相信他是對的。

而今年夏天我帶到海濱別墅來的這本書，同樣有煽動性，比Raymond那本更甚（但這本書在提到《大教堂與集市》時是相當正面的），那就是Frederick P. Brooks的《設計原本》（Addison-Wesley Professional, 2010）。Brooks這本書不斷引發我的共鳴，我也越來越佩服他的語言表達能力和他提出的觀點，然而越是有共鳴，就越感到難過和失望。

![enter image description here][5]

13年前，正值.COM熱潮涌動，年輕的Web程序員比比皆是，輟學創業的大學生也屢見不鮮。在向其中一些人傳授過去那些編程技巧的同時，我也獲得了很多樂趣。像什么測試恢復備份、寫腳本安裝操作系統、版本控制等等。當然，現在再看，也就那么回事（有些事并不像你印象中那么激動人心，對吧）。而且，我們已經無路可逃，整個.COM時代總體上對IT/CS而言就是一場災難，尤其對軟件質量和Unix來說，更是如此。

好像從來沒有人分析過.COM泛濫那些年，IT行業增長了多少。以我個人的經驗，我估計整個行業（包括IT行業由此新增的就業機會）大概增長了兩個數量級，或者更確切地說，達到了原來的百分之一萬（100倍）。

學會計算機編程很容易，就像學會用釘子把兩塊木板釘到一起一樣簡單。但問題是——打個不恰當的比方，市場對“釘在一起的兩塊木板”的需求，除了“自豪的爺爺”的那點天倫之樂以外，真的是太小了。而且，由此再進一步學習釘椅子或做碗櫥，都需要天分、實踐和訓練。我們增長的這99倍恰恰都來自那些既沒有實踐經驗，又沒有受過良好訓練的人。等這些人有時間學習和接受訓練了，聚會已然結束，大多數人失去了工作。可以樂觀地假定那些堅持下來的人最有天分，而且經驗也最多，即便如此我們還是無路可逃，因為作為IT專業人士，由于缺乏基本功，他們大多數都很濫！

不幸的是，Raymond鼓吹的——與.COM泡沫之前精心建造大教堂的理念恰恰相反的集市模因（meme）1——“對付過去就行”（just hack it），并沒有隨.COM泡沫破裂灰飛煙滅。今天，Unix這艘大船正因為難堪重負而迅速沉沒。

1?模因論是基于達爾文進化論的觀點解釋文化進化規律的新理論。[參見這里][6]。——譯者注

我剛升級了自己的筆記本電腦。到現在，我運行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.dircd conftest.dirtouch btouch a cat >confmk << 'END' a: b | c a b c:touch $[]@ ENDtouch cif ${MAKE-make} -s -q -f confmk >/dev/null 2>&1; thenlt_cv_make_order_only=yeselselt_cv_make_order_only=noficd ..rm -rf conftest.dir ]) if test $lt_cv_make_order_only = yes; thenORDER='|' elseORDER='' 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也謹慎地指出了方向：還有更好的方式。

讀書筆記：

千萬不要在集市中迷失自己。

1.“所謂質量，只有在某人對它負責時才有意義，而這個“某人”只能是一個人，不能是幾個人——二重奏除外”。我們要對我們自己制造出來的產品負責任，保證產品的質量。

2.“學會計算機編程很容易，就像學會用釘子把兩塊木板釘到一起一樣簡單。但問題是——打個不恰當的比方，市場對“釘在一起的兩塊木板”的需求，除了“自豪的爺爺”的那點天倫之樂以外，真的是太小了。而且，由此再進一步學習釘椅子或做碗櫥，都需要天分、實踐和訓練。”這句話讓我印象十分深刻，也許學會一門編程語言很簡單，比如c語言的學習。但是盡管我們學會了一門編程語言，但是我們到底能不能夠滿足市場的需求，能不能迎合市場發展趨勢都未可知。

3.“可以樂觀地假定那些堅持下來的人最有天分，而且經驗也最多，即便如此我們還是無路可逃，因為作為IT專業人士，由于缺乏基本功，他們大多數都很濫！”這句話強調了編程基本功的重要性。編程就好比練功,如果學習.net,mfc,vb等具體的語言和工具是外功(招式),對基礎的學習就是內功,只注重招式而內功不扎實是不可能成為高手的。代碼質量既是設計出來的，也是迭代優化出來的。換句話說，無論是前期的產品需求分析、架構設計，還是后期的詳細代碼設計與編碼，都離不開良好的設計。程序設計是每個程序員的基本功。但是，大多數人都只是對新技術充滿熱情，卻很少有人愿意沉下心來,花幾個月甚至- -兩年的時間來重溫基礎知識，修煉基本功。

總結

以上是生活随笔為你收集整理的有人负责，才有质量：写给在集市中迷失的一代的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。