大教堂與集市：一本不管你是不是鍵盤俠都該讀的軟件行業圣經
http://www.huxiu.com/article/106397/1.html
|
“如果你有正確的態度，有趣的事情自然會找到你”，這是Eric在“大教堂與集市”一文中給出的一條經驗。Eric S.Raymond在開源運動和黑客文化中有著很高的地位，可能是迄今為止最有名的黑客，一個更正式的頭銜則是：互聯網黑客的觀察者/參與者人類學家。 作為黑客文化的第一理論家，他極力為“黑客”（hacker）一詞正名，強調“黑客”并不是媒體報道中的計算機違法分子，而是那種著迷 于計算機技術并通過編程提供極具價值軟件的人。《大教堂與集市》是他長期觀察和研究行業后撰寫的軟件工程方法論，這本書首版于1999年，被軟件從業者奉 為“圣經”。 而今天，不僅僅是程序猿，當“開源運動正積極投身于定義21世紀的計算基礎設施，任何一個對計算機有所依賴的人，都很有必要去理解它。” 以下書摘節選自《大教堂與集市》，有刪減 前言你手頭這本書是關于黑客行為和文化的，本書收集了一系列文章，最早是寫給程序員和技術管理人員的，你可能很自然（并且再正常不過）要 問：“我為什么要關心這些？”最顯而易見的答案是：計算機軟件在世界經濟和商業戰略決策中扮演著越來越重要的角色。不管你是由于什么原因打開這本書，大概 你對那些關于信息經濟、數據時代、互聯世界的說法都聽得太多了，我不想在這里復述那些。我只是想說，如果我們能對如何編寫更優質、更穩定的軟件有更深入一 點的認識，都將會產生滾雪球般的深遠影響。 本書并沒有給出基礎理論上的創新，只是描述了這樣的事實：開源軟件系統性地利用開放式開發和分布式同行評審（peer review），不僅降低了成本，還提高了軟件質量。開源軟件并不是一個新概念（這種文化可以追溯到30年前互聯網剛誕生的時候），但直到最近，才在技術 和市場的合力下，從小眾的圈子中走了出來。今天，開源運動正積極投身于定義21世紀的計算基礎設施，任何一個對計算機有所依賴的人，都很有必要去理解它。 我之所以提到“開源運動”，是因為它有著其他更有意思的原因值得讀者關注。30多年來，互聯網原生的一群充滿活力的倡議者團體，一直在 追求、實現并珍愛著開源思想。這些人以自稱“黑客”為榮，這里所說的“黑客”并非是記者們濫用的電腦犯罪分子的代稱，而是指對某種事物的狂熱愛好者、藝術 家、古怪的天才發明家、問題解決高手和技術專家。 數十年來，默默無聞的黑客團體不僅要奮力解決技術難題，還要忍受來自于社會主流的冷漠和排斥，直到最近他們才迎來了自己的春天。他們創 建了互聯網、創建了UNIX、創建了WWW，他們還正在創建Linux和開源軟件，經歷上世紀90年代中期互聯網爆炸式的發展后，人們才終于明白這個世界 原本早該好好對待黑客們。 黑客文化及其所取得的成功，對于研究人類動機、工作組織方式、專業主義的未來、公司形態等一些基礎性問題，以及這些內容在21世紀信息 充裕的后稀缺經濟時代中如何變化和演進，都提供了一個很好的研究范例。此外，黑客文化還頗具說服力地預示了人類在適應和重塑經濟環境方面將會發生的一些深 刻變革，因此，對任何一個要在未來工作和生活的人，懂一些黑客文化都是很有意義的。 這本書是我早前發布在互聯網上的一些文章的合集，“黑客圈簡史”最早寫于1992年，此后多次被更新和修訂，其他文章寫于1997年2 月至1999年5月間，在1999年10月做了一些修改和補充，并在2001年1月本書第二版修訂時又做了一次更新，但并沒有刪掉其中比較技術化的部分或 者讓文章變得更通俗易懂一些。在我看來，能讓讀者產生一些疑問和思索，比起讓讀者感覺厭煩或者被低估智商更有禮貌。如果你在文中遇到一些特定的技術話題、 歷史典故或者偏僻的計算機術語縮寫，盡管跳過去好了，整本書是在講一個故事，讀到后面的時候，也許你就理解了前面沒弄明白的地方。 精彩書摘第二章大教堂與集市Linux有一套令人吃驚的軟件工程理論，fetch-mail作為一個專門對這些理論進行實驗的開源項目，所取得的成功讓我感到驚 訝。我將在本文討論這些理論，并對比兩種完全不同的開發模式：絕大多數商業公司所采用的“大教堂”模式和Linux世界采用的“集市”模式。兩種模式的根 本不同點在于他們對軟件排錯有著完全對立的認識。我從Linux的經驗出發，證實了這樣一個命題：“只要眼睛多，bug容易捉。”這和那些由利己個體組成 的自糾錯系統有著異曲同工之妙。在本文的最后，我探討了在這種觀念的影響下，軟件可能擁有的未來。 2.1 集市模式的成功Linux是顛覆性的，就在5年前（1991年），誰能想到，幾千名散布在全球各地的開發者們，利用業余時間，僅僅是通過 Internet這種脆弱的合作，就鬼斧神工般地造就了一個世界級的操作系統？我肯定想不到。在1993年初Linux進入我視野的時候，我已經在 UNIX和開源領域有10年開發經驗了。我是20世紀80年代中期GNU最早的貢獻者之一，當時我已經在網上發布了一些開源軟件，而且還正在開發或者與人 合作開發一些程序（如nethack、Emacs的VC和GUD模式、xlife等），這些程序直到現在仍然被廣泛使用著，我想我懂這個。 Linux推翻了很多我以為我懂的東西,多年以來,我一直在宣揚“小工 具”、“快速原型法”以及“演化式編程”等UNIX信條。但我也相信, 如果超過了一定的復雜度,更集中式的管理和更嚴格的流程是有必要的。 我相信大多數重要軟件(操作系統和真正大型工具如Emacs編輯器)需要 像建造大教堂那樣,在與世隔絕的環境下,由天才式專家或幾個行家里手 精心打造,不成熟時絕不發布beta測試版。 Linus Torvalds的開發風格是:早發布、常發布、委托所有能委托的事、開 放到幾乎是混亂的程度,這些都令人感到驚訝不已。在Linux社區里,沒 有建筑大教堂那樣的安靜和虔誠,倒更像是一個亂糟糟的大集市,充滿了 各種不同的計劃和方法(Linux的文件服務器就是個很好的例子,這里可 以接受任何人的代碼和文檔提交),而既穩定又一致的一個操作系統就這 么誕生了,這真是奇跡中的奇跡。 而事實上,集市模式真的管用,而且非常管用,這讓所有人震驚。我開始 以自己的方式去了解這種模式,除了在我的個人項目中努力探索外,我也 試著去理解為什么Linux世界沒有在混亂中四分五裂,反而以大教堂建筑 者們難以想象的速度變得越來越強大。 1996年年中,我慢慢開始理解了,而且有幸擁有了一個可以測試我的理論 的機會,這個機會使我可以有意識地在集市模式下嘗試一個開源項目,我 這么做了,更有意義的是,它成功了。 我要講述的就是這個項目的故事,通過這個故事,我將引出一些在開源開 發中很有用的格言警句。雖然對我來說,這些不都是從Linux中學到的, 但我們可以看看Linux是怎樣淋漓盡致地運用這些理論。如果我是對的, 這些格言警句會幫助你準確地理解到底是什么讓Linux社區能夠源源不斷 地產生這么多好軟件,而且,也許這些格言還能幫助你成為一個富有成效 的人。 2.2 郵件必達“切斯特互聯”(Chester County InterLink,CCIL)位于美國賓夕法尼亞州 (Pennsylvania)的西切斯特郡(West Chester),是一家小型的免費互 聯網服務提供商。1993年以來,作為聯合創始人,我曾一直負責CCIL的 技術部分,并編寫了我們獨創的多用戶論壇程序——你可以通過telnet連 到locke.ccil.org來試試看。時至今日,這個程序通過三十多條線路支持近 三千名用戶訪問。這份工作使我能夠使用CCIL的56K線路保持每天24小時 連在網絡上,當然,這是工作需要! 我已經習慣了使用電子郵件,但每過一會兒就telnet到locke上查一下郵 件,是一件比較煩人的事。我很希望郵件能夠自動地遞送到snark(我家 里的機器)上,這樣,郵件來的時候就會通知我,然后我就能用本地工具 來處理它。 互聯網原生的郵件轉發協議SMTP(Simple Mail Transfer Protocol,簡單郵 件傳輸協議)并不適用,因為它最適用于機器一直在線的情況,而我家 里的機器并不總是在線,而且也沒有一個靜態IP地址。我需要這樣一個程 序,它可以在我時斷時續的撥號上網期間,把我的郵件取到本地。我知道 有這種軟件,它們大多使用了應用層協議POP(Post Office Protocol,郵局 協議)。現在絕大多數常見郵件客戶端都支持POP,但在那個年代,我所 用的郵件閱讀器并不支持。 看來我需要一個POP3客戶端。于是我便到網上找了一個(事實上我找到 了三四個),使用了一段時間后,我發現它有個明顯的缺陷:它不能正確 地解析取回郵件的郵箱地址,導致我不能正確回復。 問題是這樣的:比如locke上有個叫joe的人給我寫信,我把信取到snark上 并試圖回復時,郵件程序會傻乎乎地想把它發給snark上并不存在的joe。 所以我不得不每次把回復郵件地址修改為@ccil.org的樣子,這實在有點痛 苦。 很明顯這種事應該由計算機搞定,但沒有任何一個現成的POP客戶端能做 到這點!這給我們上了第一課:
按說這是顯而易見的(正如老話說“需要是發明之母”),但太多的軟件 開發人員并不需要也不熱愛他們正在開發的軟件,他們把編程當差事,為 的只是拿薪酬。Linux世界里可不是這樣——也許這可以解釋為什么Linux 社區里原創軟件的平均質量是如此之高。 那么,我是不是應該立即投入到瘋狂的編程中,做出一個全新的POP3客 戶端和其他程序一較高下?千萬不要!我把手頭的POP程序看來看去,認 真思索“哪個最接近我想要的”,因為:
2. 優秀的程序員知道寫什么,卓越的程序員知道改寫(和重用)什么。
</h4>
<p>
我不敢說自己是卓越的程序員,我只是模仿他們。卓越程序員們有個很重 要的特征是“建設性懶惰”,他們知道人們要的是結果而不是勤奮,而從 一個部分可行的方案開始,明顯要比從零開始容易得多。
</p>
<p>
以Linus Torvalds為例,他并沒有嘗試從零開始寫Linux,而是以重用Minix
(一個用于PC機的迷你型UNIX類操作系統)的代碼和理念作為開始,雖 然Linux中所有Minix代碼最終都被移除或重寫,但它在Linux成長初期確實 起到了類似腳手架的作用。 </p> 基于同樣的理念,我試圖找到一些代碼寫得還不錯的POP程序,作為我開發的基礎。 UNIX世界共享源代碼的傳統使得代碼重用變得很便利(這正是GNU選擇 UNIX作為基礎OS的原因,且不論它對UNIX本身的保留意見),Linux世 界則把這個傳統發揮到了技術上的極限。相比其他地方,從Linux世界多 達數T字節的開放源碼中,找到一些他人寫的“足夠好”的代碼要可行得多。 不出意外,連同上次找到的,我一共找到九個備選程序:fetchpop、 PopTart、 get-mail、gwpop、pimp、pop-perl、popc、popmail和upop。 我首先選擇了Seung-Hong Oh寫的fetchpop。我給程序加上了“郵件頭重 寫”功能,并做了一些其他改進,這些改進被作者接受并在1.9版本中發布。 幾周以后,我偶然發現了Carl Harris寫的popclient代碼,同時帶來的是一 個難題:盡管fetchpop有一些很好的創意(比如使用后臺進程模式),但 只能處理POP3協議,代碼也略顯業余(Seung-Hong Oh在那時是個聰明但 缺乏經驗的程序員,這兩點都看得出來)。Carl Harris的代碼要好一些, 專業而穩健,但缺乏fetchpop中一些重要而精巧的特性(包括我寫的那部 分)。 繼續完善fecthpop還是轉換到popclient?如果轉換,我寫的那些代碼就可 惜了,但同時能換來一個更好的開發基礎。 一個更實際的轉換動機是popclient對多協議的支持。POP3是最常用的郵 件服務器協議,但并不是唯一的。fetchpop以及其他備選程序并不支持 諸如POP2、RPOP或AROP這些協議,而我還有點想加上對IMAP(Internet Message Access Protocol,互聯網消息訪問協議,這是最新設計的、功能最強大的郵局協議的支持,僅僅是為了好玩。 另外,還有一個理論上的原因讓我決定轉換,這可是早在Linux之前我就 學到的: 3.“計劃好扔掉一個吧,遲早你會這么做的。”(Fred Brooks,《人月神話》第11章)或者可以這么說:在你第一次把問題解決的時候,你往往并不了解這個問 題,第二次你才可能知道怎么把事情做好。所以,如果你想做對事情,至 少要再做一次。好吧,我對自己說,改寫fetchpop是我的第一次嘗試,現在我可以換了。 1996年6月25日,我把自己對popclient所做的第一批補丁發給Carl Harris, 發現他基本已經失去了對popclient的興趣。由于popclient代碼有點陳舊, 還有些小bug沒有解決,很多地方都值得改進,我和Carl Harris很快達成一 致:由我來接手這個程序。項目在不經意間升級了,我不再是對現有POP客戶端做一些小打小鬧的補 丁工作,而是開始維護整個程序。新的想法不時冒出來,我意識到自己也 許可以對程序做些大改動了。在一個鼓勵代碼共享的軟件文化中,這是一種很自然的項目演化方式。我見證了下面這條:
4. 如果你有正確的態度,有趣的事情自然會找到你。
</h4>
<p>
當然,Carl Harris的態度更重要,因為他明白:
</p>
<p>
5. 當你對一個程序不再感興趣時,你最后的責任就是把它交給一個可 以勝任的接棒者。
</p>
<p>
盡管并沒有明確提及,但Carl Harris和我都知道,我們的共同目標是做出 最好的解決方案。唯一的問題是我能否證明自己是可靠的,一旦我做到這 點,Carl Harris就優雅而利落地把程序交接給我。如果有一天輪到我時, 希望我也能交接得這么棒。
</p>
<p>
……
</p>
<p>
小編注：若您愛讀書愛讀點，我們歡迎您關注虎嗅網旗下的微信公眾號“書入法”（Roobook）。你的一部分是你讀過的書決定的，書入法精心挑選好書和美文，愿你在此每日遇新知予你歡喜。
</p>
</td>
</tr>
</tbody>
</table>
</div> 本文由用戶 jopen 自行上傳分享，僅供網友學習交流。所有權歸原作者，若您的權利被侵害，請聯系管理員。
轉載本站原創文章，請注明出處，并保留原始鏈接、圖片水印。
本站是一個以用戶分享為主的開源技術平臺，歡迎各類分享！
相關資訊 |