Unix 哲學－－<<Unix編程藝術>>摘要


要良好的運用Unix 哲學，你就應該不斷追求卓越。你必須相信，軟件設計是一門技藝，值得你付出所有的智慧、創造力和激情。否則，你的視線就不會超越那些簡單、老套的設計和實現；你就會在應該思考的時候急急忙忙跑去編程。你就會在該無情刪繁就簡的時候反而把問題複雜化——然後你還會反過來奇怪你的代碼怎麼會那麼臃腫、那麼難以調試。

要良好地運用Unix 哲學，你應該珍惜你的時間決不浪費。一旦某人已經解決了某個問題，就直接拿來利用，不要讓驕傲或偏見拽住你又去重做一遍。永遠不要蠻幹；要多用巧勁，省下力氣到需要的時候再用，好鋼用在刀刃上。善用工具，盡可能將一切都自動化。

軟件設計和實現應該是一門充滿快樂的藝術，一種高水平的遊戲。如果這種態度對你來說聽起來有些荒謬，或者令你隱約感到有些困窘，那麼請停下來，想一想，問問自己是不是已經把什麼給遺忘了。如果只是為了賺錢或是打發時間，你為什麼要搞軟件設計而不是別的什麼呢？你肯定曾經也認為軟件設計值得你付出激情……


所有的Unix 哲學濃縮為一條鐵律，那就是各地編程大師們奉為圭臬的「K.I.S.S」原則：
              
Keep It Simple, Stupid!

==================================================

也許Unix 最持久的異議恰恰來自Unix 哲學的一個特性，這一條特性是X window 設計者首先明確提出的。X 致力於提供一套「機制，而不是策略」，以支持一套極端通用的圖形操作，從而把使用工具箱和界面的「觀感」（策略）推後到應用層。
Unix 其它系統級的服務也有類似的傾向：行為的最終邏輯被盡可能推後到使用端。Unix用戶可以在多種shell 中進行選擇。而Unix 應用程序通常會提供很多的行為選項和令人眼花繚亂的定制功能。
這種傾向也反映出Unix的遺風：原本是為技術人員設計的操作系統；同時也表明設計的信念：最終用戶永遠比操作系統設計人員更清楚他們究竟需要什麼。

然而這種選擇機制而不是策略的代價是：當用戶「可以」自己設置策略時，他們其實是「必須」自己設置策略。非技術型的終端用戶常常會被Unix 豐富的選項和接口風格搞得暈頭轉向，於是轉而選擇那些偽稱能夠給他們提供簡潔性的操作系統。
只看眼前的話，Unix 的這種自由放縱主義風格會讓它失去很多非技術型用戶。但從長遠考慮，最終你會發覺這個「錯誤」換來至關重要的優勢：策略相對短壽，而機制才會長存。現今流行的界面觀感常常會變成明日進化的死胡同（去問問那些使用已經過時的X 工具包的用戶，他們會有一肚子苦水倒給你！）。說來說去，只提供機制不提供方針的哲學能使Unix 長久保鮮；而那些被束縛在一套方針或界面風格內的操作系統，也許早就從人們的視線中消失了。


雖然成型於TOPS-10 的TCP/IP 標準（互聯網的基礎） 在理論上可以與Unix 分開, 但當應用在其它操作系統上時，一直都飽受兼容性差、不穩定、bug 太多等問題的困擾。實際上，理論和規格說明人人都可以獲取, 但是只有Unix 世界中你才見得到這些穩固可靠的現實成果。


從頭到腳的靈活性:
許多操作系統自詡比起Unix 來有多麼的「現代」，用戶界面又是多麼的「友好」。 它們漂亮外表的背後，卻是以貌似精巧實則脆弱狹隘難用的編程接口，把用戶和開發者禁錮在單一的界面方針下。在這樣的操作系統中，完成設計者（指操作系統）預見的任務很容易，但如果要完成設計者沒有預料到的任務，用戶不是無計可施就是痛苦不堪。
相反，Unix 具有非常徹底的靈活性。Unix 提供眾多的程序粘合手段，這意味著Unix基本工具箱的各種組件連縱開合後，將收到單個工具設計者無法想像的功效。
Unix 支持多種風格的程序界面（通常也因為給終端用戶增加了明顯的系統複雜度而被視為Unix 的一個缺點），從而增加了它的靈活性；只管簡單數據處理的程序而無需背上精巧圖形界面的擔子。
Unix 傳統將重點放在盡力使各個程序接口相對小巧、簡潔和正交——這也是另一個提高靈活性的方面。整個Unix 系統，容易的事還是那麼容易，困難的事呢，至少是有可能做到的。



Unix 哲學起源於Ken Thompson 早期關於如何設計一個服務接口簡潔、小巧精幹的操作系統的思考，隨著Unix 文化在學習如何盡可能發掘Thompson 設計思想的過程中不斷成長，同時一路上還從其它許多地方博采眾長。


Unix 管道的發明人、Unix 傳統的奠基人之一Doug McIlroy 在[McIlroy78]中曾經說過：

（i）讓每個程序就做好一件事。如果有新任務，就重新開始，不要往原程序中加入新功能而搞得複雜。
（ii）假定每個程序的輸出都會成為另一個程序的輸入，哪怕那個程序還是未知的。輸出中不要有無關的信息干擾。避免使用嚴格的分欄格式和二進制格式輸入。不要堅持使用交互式輸入。
（ii）盡可能早地將設計和編譯的軟件投入試用, 哪怕是操作系統也不例外，理想情況下, 應該是在幾星期內。對拙劣的代碼別猶豫，扔掉重寫。
（iv）優先使用工具而不是拙劣的幫助來減輕編程任務的負擔。工欲善其事，必先利其器。

Unix 哲學是這樣的：一個程序只做一件事，並做好。程序要能協作。程序要能處理文本流，因為這是最通用的接口。


Rob Pike, 最偉大的C 語言大師之一, 在《Notes on C Programming》中從另一個稍微不同的角度表述了Unix 的哲學[Pike]：

原則1: 你無法斷定程序會在什麼地方耗費運行時間。瓶頸經常出現在想不到的地方，所以別急於胡亂找個地方改代碼，除非你已經證實那兒就是瓶頸所在。
原則2：估量。在你沒對代碼進行估量，特別是沒找到最耗時的那部分之前，別去優化速度。
原則3: 花哨的算法在n 很小時通常很慢，而n 通常很小。花哨算法的常數複雜度很大。除非你確定n 總是很大，否則不要用花哨算法（即使n 很大，也優先考慮原則2）。
原則4：花哨的算法比簡單算法更容易出bug、更難實現。盡量使用簡單的算法配合簡單的數據結構。
原則5：數據壓倒一切。如果已經選擇了正確的數據結構並且把一切都組織得井井有條，正確的算法也就不言自明。編程的核心是數據結構，而不是算法6。
原則6：沒有原則6。

Ken Thompson——Unix 最初版本的設計者和實現者，禪宗偈語般地對Pike 的原則4作了強調：
        拿不準就窮舉。



Unix 哲學中更多的內容不是這些先哲們口頭表述出來的，而是由他們所作的一切和Unix 本身所作出的榜樣體現出來的。從整體上來說，可以概括為以下幾點：
1. 模塊原則：使用簡潔的接口拼合簡單的部件。
2. 清晰原則：清晰勝於機巧。
3. 組合原則：設計時考慮拼接組合。
4. 分離原則：策略同機制分離，接口同引擎分離。
5. 簡潔原則：設計要簡潔，複雜度能低則低。
6. 吝嗇原則：除非確無它法，不要編寫龐大的程序。
7. 透明性原則：設計要可見，以便審查和調試。
8. 健壯原則：健壯源於透明與簡潔。
9. 表示原則：把知識疊入數據以求邏輯質樸而健壯。
10. 通俗原則：接口設計避免標新立異。
11. 緘默原則：如果一個程序沒什麼好說的，就沉默。
12. 補救原則：出現異常時，馬上退出並給出足夠錯誤信息。
13. 經濟原則：寧花機器一分，不花程序員一秒。
14. 生成原則：避免手工hack，盡量編寫程序去生成程序。
15. 優化原則：雕琢前先要有原型，跑之前先學會走。
16. 多樣原則：決不相信所謂「不二法門」的斷言。
17. 擴展原則：設計著眼未來，未來總比預想來得快。


更多內容看這裡：

http://www.lslnet.com/linux/f/docs1/i32/big5249529.htm
http://blog.leezhong.com/reading ... ix-programming.html

英文版：

http://www.faqs.org/docs/artu/ch01s06.html