大教堂與市集二郵件必達

簡體傳統

二郵件必達
自1993年起，我就在賓州西切斯特的一家提供免費網絡服務的小公司CCIL（Chester County InterLink）負責技術工作。我協同創建了公司并編寫了一個專用的多用戶論壇程序——你可以通過telnet連接locke.ccil.org一探究竟。如今它在三十條線路上支持著近三千名用戶。這使我可以每天二十四小時的通過CCIL的56K專線上網——其實，這是工作需要。
我已經慣于使用網絡郵件了，但不時地登錄locke檢查郵件實在很煩人。我所希望的是有辦法能將郵件轉送到我家的機器（snark）上，并在到達的時候通知我，而且可以用本地工具進行處理。
互聯網默認的郵件傳輸協議SMTP顯然不能滿足我的要求，STMP是為全時在線的機器設計的，而我家的機器不可能全天在線——況且它也沒有一個固定的IP。我需要一個程序，讓我能在撥號之后鏈接到服務器上把郵件下載到本地。我知道有這種工具存在，它們大都使用一種稱為POP的簡單協議，現在常用的郵件客戶端軟件都支持這個協議，但那時，我的郵件閱讀軟件并不支持它。
我在網上找到了三四個這樣的POP3客戶端軟件。其中一個我用了一段時間，可是他明顯缺少一個功能：抽取正確的郵件地址。
事情是這樣的，如果locke上一個叫喬的人發給我一封郵件，我將其下載到snark上。可是在回復的時候我的郵件程序會高高興興的把信投寄給一個在snark上并不存在的喬。手工修正地址是件痛苦的事。
顯然這是一件應該由電腦來完成的事情，可是沒有一個現存的POP軟件知道如何解決。這給我們上了第一課：

1. 好軟件都源自解決開發者的切身之痛。
Every good work of software starts by scratching a developer's personal itch.

或許這是眾所周知的（不是有句名諺叫做“需要是發明之母”嗎？），可是有那么多軟件開發者為了薪水把時間都消耗在他們及不喜歡又不需要的程序上了。然而這卻不會發生在Linux世界，或許這就是Linux社區產品平均質量很高的原因吧？
那么我是否應該瘋狂的投入戰斗，編寫一套新的POP軟件來和它們一較高下呢？打死都不干！相反，我仔細地檢視我手中的東西，看看哪個最接近需求。因為：

2. 優秀的程序員知道要寫什么，而偉大的程序員知道要改寫（和重用）什么。
Good programmers know what to write. Great ones know what to rewrite (and reuse).

我不敢自詡偉大，但是我努力效法那些偉大的程序員。他們都有一個重要的特點——建設性的懶惰，因為我們要的是結果而不是過程。從一個優質的部分接手總比你白手起家要容易的多。
以李納斯為例，他并沒有從零開始編寫Linux。相反他借重了Minix的代碼和理念。（Minix是一個用于個人電腦的小型類Unix操作系統）雖然Minix的全部代碼最終被全部摘除或重寫了，但是它畢竟為Linux充當了學步車。
出于同樣的考慮，我開始尋找一個現存的有最有條理的POP程序來作為開發基礎。
Unix世界共享源代碼的傳統讓我們很容易的對它們并重新加以利用。（這也是為什么盡管GNU對Unix成見很深，卻依然采用Unix為基礎開發操作系統的原因）而Linux世界更是把這種傳統發揮到了技術的極限。在浩如煙海的Linux開放代碼中花點時間來尋找一個不錯的程序，總比去別處要強的多。
加上我之前用到的，第二次的搜索讓我有了九個候選對象：fetchpop、PopTart、get-mail、gwpop、pimp、pop-perl、popc、popmail和upop。首先選用的是肖恩[1]的fetchpop，我對其做了一些改動并將改寫郵件地址的功能加了進去。后來他把這些改動加入到了自己的1.9版本中。
幾周之后，我偶然接觸到了卡爾·哈里斯的popclient代碼時，問題出現了。盡管fetchpop有那么多優秀的原創功能（比如他的后臺程序），但是卻只能支持POP3協議，而且代碼不夠老練（肖恩很聰明，但是缺少經驗）。卡爾的代碼則更好，專業而穩固。但是卻缺少很多重要的功能——那些fetchpop中的妙作（包括我加入的部分）。
是繼續使用fetchpop還是改用popclinent？如果轉換的話，就意味著我不得不放棄已經完成的代碼來換取一個更好的開發基礎。
一個實際的轉換動機是去支持更多協議。POP3使用最廣，卻不是唯一。Fetchpop和那個競爭對手同樣不支持POP2、RPOP和APOP。出于好玩，我那時已經有了在其中加入IMAP（最新設計的，最強大的POP協議）的模糊想法。
其實我還有一個更正式的理由支持我更換軟件，這是我在玩Linux之前就學到的：

3.“為舍棄而計劃，無論如何，你都要這樣做。”（弗雷德里克·布魯克斯，《人月神話》第十一章，）[2]
“Plan to throw one away; you will, anyhow.” (Fred Brooks, The Mythical Man-Month, Chapter 11)

換言之，當你開始嘗試解決一個問題的之后，你通常并不知道癥結所在。再次著手，或許能夠游刃有余。所以想把事情做好，你得準備“至少重來一次”。【注】
好吧，（我對自己說）對fetchpop的修改就算是我的第一次吧。于是，放棄了它。
1996年6月25日，我給卡爾寄去了第一批程序補丁。才發現他對這個程序基本失去了興趣。代碼已經乏人照料很久了，小錯誤流連不去，有很多改動要做。我們一拍即合，由我接手。
不經意間，工作的規模擴大了。我不再只是真對一個POP客戶端進行修補，而是要負責維護整個程序。一些可能會引發變革的想法在我腦海中浮現。
在鼓勵代碼共享的軟件文化里，這樣的演進方式是自然而然的。我只是將這些原理付諸實踐：

4.只要你態度正確，有趣的問題就會找上門來。
If you have the right attitude, interesting problems will find you.

而卡爾的態度更加重要，他懂得：

5.對一個項目失去興趣的時候，你的最后責任就是找一個稱職的接班人。
When you lose interest in a program, your last duty to it is to hand it off to a competent successor.

為了創造一個最佳的解決方案，我和卡爾不謀而合。唯一的問題是，我是否能證明我的能力。一旦我做到了，卡爾便優雅而迅速的交托給我。希望有一天輪到我這么做的時候，我能同樣的出色。

注：
著名的計算機學家喬·本特利（Jon Bentley）在其著作《編程珠璣》（Programing Pearls）對其做了如下評注：“如果你舍棄了一個，你還會舍棄第二個”。他的話完全正確，布魯克斯和本特利指出：不要期望一蹴而就，以一個好主意重頭來過通常要比梳理一團亂麻要好的多。

譯者按：
1.肖恩，Sean Oh，fetchpop的作者，書中出現的名稱是Seung-Hong Oh。Sean是其英文名。有譯者將其音譯作“歐松宏”，我認為這個譯音有失精當。因為Oh Seung Hong這三個拼寫在韓英互譯時是很常見的。與其對應的韓文大致是“오승홍”，譯成漢語則大致是“吳承弘”。在沒有辦法聯系到作者本人的情況下，為了行文不出差錯，我選用了其英文名。
2.The Mythical Man-Month，Frederick P. Brooks。《人月神話》，作者弗雷德里克·布魯克斯。計算機學家，被稱作“IBM 360之父”，曾獲得圖靈獎和美國國家技術獎——兩個計算機界舉足輕重的獎項。《人月神話》是其隨筆集，其在書中對繁復的工程管理做了洞見的觀察。在第十一章《未雨綢繆》（Plan to Throw One Away）中其提出了舍棄型原型的概念。本文引言是強調“為舍棄而計劃”，“one”用來指代一個計劃或者原型，我認為不能直接譯為“一個”所以用了代詞“它”放寬其概念。