第九章 源自Fetchmail的更多經驗

在我們回到廣義的軟體工程問題之前，還有幾條fetchmail開發中的獨特細節需要深思。非技術性的讀者可以安心跳過本章。

rc（fetchmail使用者配置）檔案文法中包含了一些完全不需解析的，可選的“噪音”關鍵詞。與傳統“關鍵詞-對應值”比對關系相比，它們所帶來的趨近于英語文法的配置檔案更具可讀性。

這源自一個深夜的實驗，當時我注意到rc檔案的配置指令非常像一門微型指令語言。（這也是我把關鍵字“server”改成“poll”的原因）[1]

在我看來，努力使這個微型指令語言更像英語可以讓其更便于使用。現在我雖然支援“讓它成為一門語言（make it a language）”的設計流派（諸如Emacs、HTML和很多資料庫引擎那樣），但是并不熱衷于“類英語”的文法。

傳統上，程式員們傾向選用簡潔緊湊、完全沒有備援的文法。這是計算資源昂貴時期的文化遺留，以緻解析過程必須盡可能的簡潔廉價。是以如果采用像英語這樣有50%備援的文法模組化，在當時顯然是很不合時宜的。

這并不是我通常避免使用“類英語”文法的原因。我在這裡提及就是為了打破這種觀點。有了更廉價的緩存和處理器，簡潔就沒有必要稱為最終的追求了。現在一門語言的人性化遠比降低計算成本要重要。

然而，我們仍然有要謹慎為之的原因。其一就是解析過程的複雜度帶來的成本——你總不希望這個成本上升到足以滋養錯誤和迷惑使用者吧？另外，讓一門文法趨近英語的作法，通常會令其所謂的“英語”走形。以至于對自然語言的表面的模仿會導緻如同傳統文法一般的混亂。（你可以在很多号稱“第四代”的和商業資料庫查詢語言中看到這種惡果）

Fetchmail的控制文法之是以能避免這些問題，是因為它的語言空間極為有限。它離一門多用途的語言還差得遠呢；其所描述的問題也很簡單。是以大可不擔心穿梭于微小的英語子集和實際控制語言會造成什麼迷惑。我覺得這裡有一則可以推而廣之的經驗：

16.當你的語言還遠不足以達到圖靈完備的時候，不妨為文法蘸上一層“糖衣”。[2]

When your language is nowhere near Turing-complete, syntactic sugar can be your friend.

另一則經驗是有關隐藏的安全性的。一些使用者要求我改寫軟體，以便能對rc檔案加密。這樣入侵者就不會在無意間看到它們。

我沒有照做，因為這并不會帶來實際的保護。因為隻要有人能獲得你rc檔案的使用權，他就能和你一樣運作fetchmail檢視郵件——如果真的想要你的密碼，他就可以從fetchmail代碼中剝離出必要的解碼器。

言而總之，在rc檔案中注入密碼隻是給那些沒有深入思考的人一種安全的假象。進而，我們得出通用的規則：

17.安全系統的效用隻取決于對秘密的保護，謹防僞安全。[3]

A security system is only as secure as its secret. Beware of pseudo-secrets.

譯者按：

1.這個關鍵字後面對應的是郵件伺服器名稱。計算機中，“Poll”是動詞“輪詢”的意思，也就是依次向伺服器發送封包，收取郵件。而“Server”是名詞“伺服器”。顯然使用“Poll”更符合英語文法。

2.圖靈完備：又稱圖靈完備性。如果一門語言達到“令一切可計算的問題都能計算”的程度就可以說其達到了圖靈完備或說具有圖靈完備性。

3.“秘密”是指所要隐藏的标的；“安全系統”是指保護這個标的不洩露的手段；“僞安全”是指将标的寫入手段的做法。讓我們以fetchmail為例，“秘密”就是要保護rc檔案，“安全系統”就是密碼，把密碼寫入rc檔案顯然就是僞安全。