今天讀到一些UNIX下的編程哲學，對自己相當?shù)挠袥_擊力，把我覺得有用并且有道理的，自己組織了一下：

“編程的核心是數(shù)據(jù)結(jié)構(gòu)，而不是算法”，即使最簡單的程序邏輯人類來驗證也很困難，但就算復雜的數(shù)據(jù)，對人類來說也相對容易推導和建模。五十個節(jié)點的指針樹要比五十行程序的流程圖更清楚。

“編程的本質(zhì)是控制復雜度”，而流程圖、過程化、結(jié)構(gòu)化、面向?qū)ο笠约捌渌椒ㄕ撉『?#8220;成功”將復雜度提升到人腦不能處理的地步。所以，降低整體復雜度的方法是用清晰的接口把若干簡單模塊組合成一個復雜軟件。

“簡潔最美”，最錯綜復雜的美妙設計，常常使我們的設計能力超出排錯能力，結(jié)果是代價高昂的廢品。

“接口和引擎分離”，把復雜的GUI界面與后臺處理分做兩端，中間用簡單協(xié)議架橋。

“可見才可掌控”，軟件系統(tǒng)的透明性就是說，你能一眼看出它在干什么，要能監(jiān)視到內(nèi)部狀態(tài)。

“撐不下去，馬上退出”，出現(xiàn)異常，補救措施明明又沒成功，還挺在那里，很久才發(fā)現(xiàn)是最壞的一種情況。要么“響亮的倒塌，要么為工作鏈下一環(huán)程序輸出一個嚴謹干凈的正確數(shù)據(jù)”。

“過早的優(yōu)化是萬惡之源”，先要求運行，再求正確，最后再求快。還不知道瓶頸就匆忙優(yōu)化，是唯一一個比亂加功能更損害設計的錯誤。“最強大的優(yōu)化工具是DELETE鍵”。

“善用工具”，教會電腦生成一些簡單的代碼；一旦有人解決了某個問題，就直接拿過來用，盡可能一切都自動化。

“寧花機器一分，不花程序員一秒”。有的程序員寫程序是“為機器寫”，過份追求效率。想方設法讓機器“少做些事”，因此耽誤大量時間精力。與此相對地，我們可以使用一些簡單直接的，即使是相對費時的算法，浪費了一些“機器的時間”，但節(jié)省了程序員的精力。又比如，有的語言，將程序員從內(nèi)存釋放中解脫出來，可以更高效的開發(fā)，這也是一種珍惜程序員精力，讓機器多做事的例子。
BTW：我其實一直以來都是做C＋＋的，從前總覺得這才是最“高效”的語言，一向?qū)AVA和腳本語言不感冒，但漸漸才明白，一把鑰匙開一扇門，有時候，甚至是大多數(shù)時候，選擇后者才是“高效”的做法。機器只不過是通了電一堆晶體管，讓它費點力沒什么。

綜上所述，4個字母：KISS－－Keep It Simple, Stupid!


最后，還是把UNIX哲學的17個原則完整列一下：
1、 模塊性原則：寫簡單的，通過干凈的接口可被連接的部件。
2、 清楚原則：清楚要比小聰明好。
3、 合并原則：設計能被其它程序連接的程序。
4、 分離原則：從機制分離從策略，從實現(xiàn)分離出接口。
5、 簡單原則：設計要簡單；只有當你需要的時候，增加復雜性。
6、 節(jié)儉原則：只有當被證實是清晰，其它什么也不做的時候，才寫大的程序。
7、 透明原則：為使檢查和調(diào)試明顯更容易而設計。
8、 健壯性原則：健壯性是透明和簡單的追隨者。
9、 表現(xiàn)原則：把知識整理成資料，于是程序邏輯能變得易理解和精力充沛的。
10、最小意外原則：在接口設計中，總是做最小意外事情。
11、沉默原則：當一個程序令人吃驚什么也不說的時候，他應該就是什么也不說。
12、修補補救：當你必須失敗的時候，盡可能快的吵鬧地失敗。
13、經(jīng)濟原則：程序員的時間是寶貴的；優(yōu)先機器時間節(jié)約它。
14、產(chǎn)生原則：避免手工堆砌；當你可能的時候，編寫可以寫程序的程序。
15、優(yōu)化原則：在雕琢之前先有原型；在你優(yōu)化它之前，先讓他可以運行。
16、差異原則：懷疑所有聲稱的“唯一真理“。
17、可擴展原則：為將來做設計，因為它可能比你認為來的要快。