2. 我把每一個和我討論fetchmail的人加入一個beta表中。<br>　　　　3. 每當我發布我都向beta表中的人發出通告，鼓勵人們參與。<br>　　　　4. 我聽取beta測試員的意見，向他們詢問設計決策，對他們寄來的補丁和反饋表示感謝。<p><br>　　這些簡單的手段立即收到的回報，在工程的開始，我收到了一些錯誤報告，其質量足以使開發者因此被殺掉，而且經常還附有補丁、我得到了理智的批評，有趣的郵件，和聰明的特征建議，這導致了：<p><br>　　10. 如果你象對待最寶貴的資源一樣對待你的beta測試員，他們就會成為你最寶貴的資源。<p><br>六. popclient變成了Fetchmail<p><br>　　這個工程的真正轉折點是Harry Hochleiser寄給我他寫的代碼草稿，他把郵件轉發到客戶端機器的SMTP端口，我立即意識到這個特征的可靠實現將淘汰所有其他的遞送模式。<p><br>　　幾個星期以來我一直在修改而不是改進fetchmail，因為我覺得界面設計雖然有用但是太笨拙瑣碎了，到處充滿了太多的粗陋的細小選項。<p><br>　　當我思考SMTP轉發時我發現popclient試圖做的事太多了，它被設計成既是一個郵件傳輸代理(MTA)也是一個本地遞送代理(MDA)。使用SMTP轉發，它就可以從MDA的事務中解脫出來而成為一個純MTA，而象sendmail一樣把郵件交給本地遞送程序來處理。<p><br>　　既然端口25在所有支撐TCP／IP的平臺上早已被預留，為什么還要為一個郵件傳輸代理的配置或為一個郵箱設置加鎖的附加功能而操心呢?尤其是當這意味著抽取的郵件就象一個正常的發送者發出的SMTP郵件一樣，而這就是我們需要的。<p><br>　　這里有幾個教益：第一，SMTP轉發的想法是我有意識地模擬Linus的方法以來的最大的單個回報，一個用戶告訴我這個非同尋常的想法——我所需做的只是理解它的含義。<p><br>　　11. 想出好主意是好事，從你的用戶那里發現好主意也是好事，有時候后者更好。<p><br>　　很有趣的是，你很快將發現，如果你完全承認你從其他人那里得到多少教益的話，整個世界將會認為所有的發明都是你做出的，而你會對你的天才變得謙虛。我們可以看到這在Linus身上體現得多明顯!(當我在1997年8月的Perl會議上發表這個論文時，Larry Wall坐在前排，當我講到上面的觀點時，他激動的叫了出來：“對了!說對了!哥們!”所有的聽眾都哄堂大笑起來，因為他們知道同樣的事情也發生在Perl的發明者身上)。<p><br>　　于是在同樣精神指導下工程進行了幾個星期，我開始不光從我的用戶那兒也從聽說我的系統的人那兒得到類似的贊揚，我把一些這種郵件收藏起來，我將在我開始懷疑自己的生命是否有價值時重新讀讀這些信。:)<p><br>　　但是有兩個更基本的，非政治性的對所有設計都有普遍意義的教益。<p><br>　　12. 最重要和最有創新的解決方案常常來自于你認識到你對問題的概念是錯誤的。<p>　　一個衡量fetchmail成功的有趣方式是工程的beta測試人員表(fegtchmail的朋友們)的長度，在創立它的時候已經有249個成員了，而且每個星期增加兩到三個。<p><br>　　實際上，當我在1997年5月校訂它時，這張表開始因為一個有趣的原因而縮短了，有幾個人請求我把他們從表中去掉，因為fetchmail已經工作的如此之好，他們不需要看到這些郵件了!也許這是一個成熟的市集風格工程的生命周期的一部分。<p>　　我以前一直在解決錯誤的問題，把popclient當作MTA和具有許多本地遞送模式的MDA的結合物，Fetchmail的設計需要從頭考慮為一個純的MTA，做為一個普通Internet郵件路徑的一部分。<p><br>　　當你在開發中碰了壁時(當你發現自己很難想通下一步時)，那通常不是要問自己是否找到正確答案，而是要問是否問了正確問題，也許需要重新構造問題。<p><br>　　于是，我重新構造了我的問題，很清楚，要做的正確的事是(1)把SMTP轉發支持放在通用驅動程序中，(2)把它做為缺省模式，(3)最終分離所有其他的遞送模式，尤其是遞送到文件和標準輸出的選項。<p><br>　　我在第三步上猶豫了一下，擔心會讓popdiant的長期用戶對新的遞送方法感到煩心，在理論上，他們可以立即轉而轉發文件或者他們的非sendmail等價物來得到同樣的效果，在實際中這種轉換可能會很麻煩。<br>但是當我這么做之后，證明好處是巨大的，驅動程序代碼的冗余的部分消失了，配置完全變得簡單了——不用屈從于系統MDA和用戶的郵箱，也不用為下層OS是否支持文件鎖定而擔心了。<p><br>　　而且，丟失郵件的唯一漏洞也被堵死了，如果你選擇了遞送到一個文件而磁盤已滿，你的郵件就會丟失，這在SMTP轉發中不會發生，因為SMTP偵聽器不會返回OK的，除非郵件可以遞送成功或至少被緩沖留待以后遞送。<p><br>　　還有，性能也改善了(雖然在單次執行中你不會注意到)，這個修改的另一個不可忽視的好處是手冊變得大大簡單了。<p><br>　　后來，為了允許處理一些罕見的情況，包括動態SLIP，我必須回到讓用戶定義本地MDA遞送上來，但是我發現了一個更加簡單的方法。<p><br>　　所有這些給了我們什么啟發呢?如果可以不損失效率，就要毫不猶豫拋棄陳舊的特性，Antonine de Saint-Exupery(在他成為經典兒童書籍作家之前是一個飛行員和飛機設計師)曾說過：<p><br>　　13. “最好的設計不是再也沒有什么東西可以添加了，而是再也沒有什么東西可以去掉。”<p><br>　　當你的代碼變得更好和更簡單時，這就是你知道它是正確的時候了，而且在這個過程中，fetehmail的設計具有了自己的特點，而區別于其前身popclient。<p><br>　　現在是改名的時候了，這個新的設計看起來比老popclient更象一個sendmail的復制品，它們都是MTA，但是Senmail是推然后遞送，而新的popclient是拉然后遞送。于是，在兩個月之后，我把它重新命名為fetehmail。<p><br>七. Fetchmail成長起來<p><br>　　現在我有了一個簡潔和富有創意的設計，工作得很好的代碼，因為我每天都用它，和一直在增長的beta表，它讓我漸漸明白我已經不是在從事只能對少數其他人有用的工作中，我寫了一個所有有一個Unix郵箱和SLIP／PPP郵件連接的人都真正需要的程序。<p><br>　　通過SMTP轉發功能，它成為一個潛在的“目錄殺手”，遠遠領先于它的競爭者，這個程序如此能干以至于其他的程序不但被放棄簡直被忘記了。<p><br>　　我知道你不可以真得瞄準或計劃出這樣的結果，你只能努力去設計這些強大的思想，以后這些結果就好象是不可避免的、自然的、注定了的，得到這種思想的唯一辦法是獲取許多思想，或者用工程化的思考其他人的好主意而超過原來想到它的人的設想。<p><br>　　Andrew Tanenbanm原來設想建造一個適合386的簡單的Unix用做教學，Linus Torvalels把Andrew的可能想到的Minix可以做什么的概念推進了一步，成長為一個極好的東西，同樣的(雖然規模較小)，我接受了Card Harris和Harry Hochheiser的想法，把它們變得更強大，我們都不是人們所浪漫幻想的天才的創始人，但是大多數科學和工程和軟件開發不是被天才的創始人完成的，這和流傳的神話恰恰相反。<p><br>　　結果總是執著的原因——實際上，它是每個黑客為之生存的成功!而且它們意味著我必須把自己的標準定高一點，為了把fetchmail變得和我所能設想的那樣好，我必須不僅為我自己的需要寫代碼，而且也要包括對在我生活圍主頁外的人們的需求的支持，而且同時也要保證程序的簡單和健壯。<p><br>　　在實現它之后我首先寫的最重要的特征是支持多投——從集中一組用戶的郵件的郵箱中取出郵件，然后把它路由到每個人手中。<p><br>　　我之所以加上多投功能部分是因為有些用戶一直在鬧著要它，更是因為我想它可以從單投的代碼中揭露出錯誤來，讓我完全一般地處理尋址，而且這被證明了。正確解釋RFC822花了我相當長的時間，不僅因為它的每個單獨部分都很難，而且因為它有一大堆相互依賴的苛刻的細節。<p><br>　　但是多投尋址也成為一個極好的設計決策，由此我知道：<p><br>　　14. 任何工具都應該能以預想的方式使用，但是一個偉大的工具提供你沒料到的功能。<p><br>　　Fetchmant多投功能的一個沒有料到的用途是在SLIP／PPP的客戶端提供郵件列表、別名擴展。這意味著一個使用個人機器的人不必持續訪問ISP的別名文件就能通過一個ISP帳戶管理一個郵件列表。我的beta測試員提出的另一個重要的改變是支持8位MIME操作，這很容易做，因為我已經仔細的保證了8位代碼的清晰，不僅因為我預見到了這個特性的需求，而且因為我忠實于另一準則：<p><br>　　15. 當寫任何種類的網關型程序時，多費點力，盡量少干擾數據流，永遠不要拋棄信息，除非接收方強迫這么作!<p><br>　　如果我不遵從這個準則，那么8位MIME支持將會變得困難和笨拙，現在我所需要做的，是只讀一下RFC 1652，在產生信頭的邏輯加上一點而已。<p><br>　　一些歐洲用戶要求我加上一個選項來限制每次會話取得消息數(這樣他們就可以從昂貴的電話網中控制花費了)，我很長一段時間拒絕這樣做，而且我仍然對它不很高興，但是如果你是為了世界而寫代碼，你必須聽取顧客的意見——這并不隨他們不付給你錢而改變。<p><br>八. 從Fetchmail得來的另一些教益<p><br>　　在他們回到一般的軟件工程問題以前，還有幾個從fetchmail得到的教益需要思考。<p><br>　　rc文件語法包括可選的“noise”關鍵字，它被掃描器完全忽略了，當你把它們全抽取出的時候，關鍵字／值對更具可讀性。<p><br>　　當我注意到rc文件的聲明在多大程度上開始象一個微型命令語言時，這是一個Late-night的體驗(這也是我為什么把popclient原來的“server”關鍵字改成了“poll”)。<p><br>　　對我來說似乎把這個微型命令語言變得更象英語可能會使它更容易使用。現在，雖然我對經過Emacs和HTML及許多數據庫引擎所證實的“把它做成一個語言”的設計方式確信不疑，但是我并不是一個通常的“類英語”語法的狂熱擁護者。<p><br>　　傳統程序員容易控制語法使它盡量精確和緊湊，完全沒有冗余，這是計算機資源還很昂貴時遺留下的一種文化傳統，所以掃描策略需要盡可能的廉價和簡單，而具有50%冗余度的英語，看來好象是一個非常不合適的模型。<p><br>　　這并不是我不用類英語語法的原因，我提到這一點是為了推翻它，在更廉價的時鐘周期與核心的時代，簡潔并沒有走到盡頭，今天對一個語言來說，對人更方便比對機器更廉價來的更加重要。<p><br>　　然而，有幾個原因提醒我們小心一點，一個是掃描策略的復雜度開銷——你并不想把它變成一個巨大的錯誤來源和讓用戶困惑，另一個是試圖使語言表面上的類似可以和傳統語言一樣令人困惑(你可以在許多4GL和商業數據庫查詢語言上看到這一點)。<p><br>　　Fetchmail的控制語法避免了這些問題，因為語言的領域是極其有限的。它一點也不象一個一般性的語言，它很簡單地描述的東西并不復雜，所以很少可能在英語的一個小子集與實際的控制語言之間發生混淆，我想這有一個更廣泛的教益：<p><br>　　16. 如果你的語言一點也不象是圖靈完備的，嚴格的語法會有好處。<p><br>　　另一個教益是關于安全的，一些fetchmail用戶要求我修改軟件把口令加密存貯在rc文件里，這樣覷探者就不能看到它們了。<p><br>　　我沒有這樣做，因為這實際上起不到任何保護作用，任何有權讀取你的rc文件的人都可以以你的名義運行fetchmail——如果他們要破你的口令，它們可以從fetchmail的代碼中找到制作解碼器的方法。<p><br>　　所以fetchmail口令的加密都會給那些不慎重思考的人一種安全的錯覺，這里一般性的準則是：<p><br>　　17. 一個安全系統只能和它的秘密一樣安全，當心偽安全。<p><br>九. 集市風格的必要的先決條件<p><br>　　本文的早期評審人員和測試人員堅持提出成功的市集模式開發的先決條件，包括工程領導人的資格問題和在把項目公開和開始建造一個協作開發人員的社團的時候代碼的狀態。<p><br>　　相當清楚，不能以一個市集模式從頭開發一個軟件，我們可以以市集模式、測試、調試和改進，但是以市集模式從頭開始一個項目將是非常困難的，Linus沒有這樣做，我也沒有，初期的開發人員的社團應該有一此可以運行和測試的東西來玩。<p><br>　　當你開始創建社團時，你需要演示的是一個諾言，你的程序不需要工作的很好，它可以很粗糙、很笨拙、不完整和缺少文檔、它不能忽略的東西是要吸引哪些人卷入一個整潔的項目。<p><br>　　Linux和fetchmail都是以一個吸引人的基本設計進入公共領域的，許多和我一樣在思考市集模式的人已經正確的認為這是非常關鍵的，然后得出了一個結論，工程領導者的高度的設計直覺和聰穎是必不可少的。<p><br>　　但是Linus是從Unix得到他的設計的，我最初是從先前的popmail得到啟發的(雖然相對Linux而言，它最后改變巨大)，所以市集風格的領導人／協調人需要有出眾的設計才能，或者他可以利用別人的設計才能?<p><br>