第九章源自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檔案顯然就是偽安全。