Unix哲學

Unix哲學是一套基於Unix作業系統頂級開發者們的經驗提出的軟體開發的準則和哲學。

來源

UNIX 哲學由 Doug McIlroy 在1978年的《Bell System Technical Journal 》中發表:^[1]

McIlroy：A Quarter Century of Unix

道格拉斯·麥克羅伊是Unix系統上管道機制的發明者，也是Unix文化的締造者之一。他歸納的Unix哲學如下：

程式應該只關注一個目標，並儘可能把它做好。讓程式能夠互相協同工作。應該讓程式處理文字資料流，因為這是一個通用的介面。

更加簡化的版本是：只做一件事，將其做至極致。雖然只有第三條是特指Unix系統的，但Unix開發者們常常同時強調這三個信條。

Pike：Notes on Programming in C

羅勃·派克在他的《Notes on Programming in C （頁面存檔備份，存於網際網路檔案館）》中提到了以下格言。雖然這些規則是關於程式設計的，但作為Unix哲學絲毫不為過：

1. 你永遠不會知道你的程式會在什麼地方耗費時間。程式的瓶頸常常出現在意想不到的地方，因此在你確信找到瓶頸後再動手最佳化（英語：Optimization (computer science)）代碼吧。
2. 測試代碼。只有在你詳細測試了代碼，並且發現一部分代碼耗費了絕大部分的執行時間時再對程式作速度最佳化。
3. 功能全面的演算法（fancy algorithm）在處理小規模問題時效率很低，這是因為演算法時間效率中的常數很大，而問題往往規模很小。除非你知道你遇到的常常是複雜的情況，否則就讓代碼醜陋但是簡單而高效吧。（即使問題規模確實很大，也首先嘗試第二條規則。）
4. 功能全面的演算法比簡單的演算法更容易產生bug，更難實現。儘量使用簡單的演算法和資料結構。
5. 資料決定一切。如果選擇的資料結構能很好的管理資料，演算法部分往往不言自明。記住，資料結構，而非演算法，才是編程的關鍵。
6. 沒有第六條規則。

派克的第一、二條規則重申了高德納的著名格言：「過早的最佳化是一切罪惡的根源。」^[2] 派克的第三、四條規則被肯·湯普遜改述成：「疑惑不定之時最適合窮舉。」事實上，這兩條規則也是KISS原則的具體表現。規則五在之前Fred Brooks的人月神話中也被提及。喬恩·本特利的《Programming Pearls（英語：Programming Pearls）》中也有一章闡述了相同的設計哲學。此規則作為「如果你的資料結構很好，那麼控制它的演算法就無關痛癢了」的例子常常被簡化成「簡約地寫代碼，聰明地用資料」。第六條規則當然只是派克針對蒙提·派森之小品Bruces sketch（英語：Bruces sketch）的幽默發揮而已了。

Mike Gancarz的《UNIX哲學》

1994年，X Window系統開發組的成員Mike Gancarz根據他自己的Unix系統經驗以及和其他領域使用Unix系統的資深程式設計師們的討論結果，寫成了The UNIX Philosophy，提出了9條訓格之言：

1. 小即是美。
2. 讓程式只做好一件事。
3. 儘可能早地建立原型。
4. 可移植性比效率更重要。
5. 資料應該儲存為文字檔案。
6. 儘可能地榨取軟體的全部價值。
7. 使用shell指令碼來提高效率和可移植性。
8. 避免使用可客製化性低下的使用者介面。
9. 所有程式都是資料的過濾器。

此外還有十條原則則並不為所有人認同，甚至還是爭論的焦點（如單核心和微核心之爭）：

1. 應該允許使用者客製化操作環境。
2. 讓作業系統核心小而輕。
3. 使用小寫字母並儘量簡短。
4. 節約紙張，保護樹林。
5. 沉默是金。
6. 並列地思考。
7. 部分加部分大於整體。
8. 尋找問題的帕雷托法則。
9. 程式隨需求而增長（更糟就是更好）。
10. 層級地思考。

糟糕的更好

理察·P·加布里埃爾（英語：Richard P. Gabriel）提議Unix的一個關鍵優勢是他稱作「糟糕的更好」的設計哲學。在「糟糕的更好」的設計風格下，介面和實現的簡單性比系統的任何其他屬性都更重要，包括準確性、一致性和完整性。加布里埃爾主張這種設計風格擁有關鍵的進化優勢，儘管他也懷疑一些結果的品質。

參考文獻