Unix哲學

模塊原則 (使用簡潔的接口拼合簡單的部件)

計算機編程的本質就是控制複雜度

要編寫複雜軟件而又不至於一敗塗地的惟一方法就是下降其總體複雜度——用清晰的接口把若干簡單的模塊組合成一個複雜的軟件。如此一來，多數問題只會侷限於某個局部，那麼就還有但願對局部進行改進而不至牽動全身。

清晰原則 (清晰勝於技巧)

維護成本是高昂的，在寫程序時，要想到你不是寫給執行代碼的計算機看的，而是給人——未來閱讀維護源碼的人，包括你本身看的。

在Unix傳統中，這個建議不只意味着代碼註釋。良好的Unix實踐一樣信奉在選擇算法和實現時就應該考慮到未來的可擴展性。爲了取得程序一丁點性能的提高就大幅增長技術的複雜性和晦澀性，這個買賣作不得——這不只僅是由於複雜的代碼容易滋生bug，也由於它會使往後的閱讀和維護工做更加艱難。

組合原則 (設計時考慮拼接組合)

若是程序彼此之間不能有效通訊，那麼軟件就不免會陷入複雜度的泥淖。

在輸入方面，Unix傳統極力提倡採用簡單、文本化、面向流、設備無關的格式。在經典的Unix下，多數程序都儘量採用簡單過濾器的形式，即將一個簡單的文本輸入流處理爲一個簡單的文本流輸出。

Unix程序員偏心這種作法並非由於它們仇視視圖界面，而是由於若是程序不採用簡單的文本輸入輸出流，它們就極難銜接。

要想讓程序具備組合性，就要使程序彼此獨立。在文本流這一端的程序應該儘量不要考慮到文本流另外一端的程序。

分離原則 (策略同機制分離，接口同引擎分離)

把策略同機制揉成一團有兩個負面影響：一來會使策略變得死板，難以適應用戶需求的改變，二來也意味着任何策略的改變均可能會動搖機制。

能夠將應用程序分紅能夠協做的前端和後端進程，經過socket專用應用協議進行通信。這種雙端設計方法大大下降了總體複雜度，bug有望減小。

簡潔原則 (設計要簡潔，複雜度能低就低)

來自多方面的壓力經常會讓程序變得複雜(bug更多)，其中一種壓力就是來自技術上的虛榮心理。Unix程序員相互比的是誰可以作到」簡潔而漂亮」並以此爲榮。

更爲常見的是，過分的複雜性每每來自於項目的需求，要避免這種情況，就須要鼓勵一種軟件文化，以簡潔爲美，人人對龐大複雜的東西羣起而攻之。

吝嗇原則 (除非確無它法，不要編寫龐大的程序)

「大」有兩重含義：體積大，複雜程度高。程序大了，維護起來就困難。因爲人們對花費了大量精力才作出來的東西難以割捨，結果致使在龐大的程序中把投資浪費的註定要失敗或者並不是最佳的方案上。

透明原則 (設計要可見，以便審查和調試)

軟件系統的透明性是指你一眼就可以看出軟件是在作什麼以及怎樣作的。顯示性是指程序帶有監視和顯示內部狀態的功能。

設計時若是充分考慮到這些要求會給整個項目全過程都帶來好處。至少，調試選項的設置應該儘可能不要在過後，而應該在設計之初便考慮進去。這是考慮到程序不但應該可以展現其正確性，也應該可以把原開發者解決問題的思惟模型告訴後來者。

程序若是要展現其正確性，應該使用足夠簡單的輸入輸出格式，這樣才能保證很容易地檢驗有效輸入和正確輸出之間的關係是否正確。

出於充分考慮透明性和顯見性的目的，還應該提倡接口簡潔，以方便其餘程序對它進行操做。

健壯原則 (健壯源於透明與簡潔)

軟件的健壯性指軟件不只能在正常狀況下運行良好，並且在超出設計者設想的意外條件下也可以運行良好。

大多數軟件禁不起磕碰，毛病不少，就是由於過於複雜，很難通盤考慮。若是不可以正確理解一個程序的邏輯，就不能確信其是否正確，也就不能在出錯時修復它。

這也就帶來了讓程序健壯的方法，就是讓程序的內部邏輯更易於理解。要作到這一點主要有兩種方法：透明化和簡潔化。

上面曾說過，軟件的透明性就是指一眼就可以看出是怎麼回事，即人們不須要絞盡腦汁就可以推斷出全部可能的狀況，那麼這個程序就是簡潔的。程序越簡潔，越透明，也就越健壯。

表示原則 (把知識代入數據以求邏輯質樸而健壯)

數據要比程序邏輯更容易駕馭。因此若是要在複雜數據和複雜代碼中選擇一個，寧願選擇前者。更進一步：在設計中，應該主動將代碼的複雜度轉移到數據中去。

通俗原則 (接口避免標新立異)

最易用的程序就是用戶須要學習新東西最少的程序，換句話說最易用的程序就是最切合用戶已有知識的程序。

緘默原則 (無話可說？那就沉默)

行爲良好的程序應該默默工做，毫不嘮嘮叨叨，礙手礙腳。沉默是金。

簡潔是Unix程序的核心風格。一旦程序的輸出成爲另外一個程序的輸入，就要很容易把須要的數據挑出來。站在人的角度上來講，重要的信息不該該混雜在冗長的程序內部行爲信息中。

補救原則 (出現異常時，立刻退出並給出足夠錯誤信息)

軟件在發生錯誤時也應該與在正常操做的狀況下同樣，有透明的邏輯。最理想的狀況固然是軟件可以適應和應付非正常操做；而若是補救措施明明沒有成功，卻悄無聲息地埋下崩潰的隱患，這就是最壞的狀況了。

寬容地收，謹慎地發。就算輸入的數據很不規範，一個設計良好的程序也會盡可能領會其中的意義，以儘可能與別的程序協做。而後要麼拋出異常，要麼爲工做鏈的下一環程序輸出一個嚴謹乾淨正確的數據。

經濟原則 (寧花機器一分，不花程序員一秒)

隨着技術的發展，開發公司和大多數用戶都能獲得廉價的機器，因此這一準則的合理性就顯然不用多說了。

若是咱們在軟件開發中嚴格遵循這條原則的話，大多數的應用場合應該使用高級語言，如Perl,Python,Java,Php,甚至Shell——這些語言能夠將程序員從自行管理內存的負擔中釋放出來。

生成原則 (避免手工hack,儘可能編寫程序去生成程序)

人類很不善於幹辛苦的細節工做。所以程序中任何手工hacking都是滋生錯誤和延誤的溫牀。程序規格越簡單越抽象，設計者就越容易作對。

優化原則 (過早優化是萬惡之源)

還不知道瓶頸所在就匆忙進行優化，這多是惟一一個比亂加功能更加損害設計的錯誤。從畸形的代碼到雜亂無章的數據佈局，犧牲透明性和簡潔性而片面追求速度、內存或者磁盤使用的後果隨處可見。

先製做原型，再精雕細琢。優化以前先確保能用。」極限編程」宗師Kent Beck從另外一種不一樣的文化將這點有效地擴展爲：先求運行，再求正確，最後求快。

藉助原型化找出哪些功能沒必要實現，有助於對性能進行優化；那些不用寫的代碼顯然無須優化。

多樣原則 (毫不相信所謂」不二法門」的斷言)

Unix傳統有一點很好，即從不相信任何所謂的」不二法門」。Unix奉行的是普遍採用多種語言、開放的可擴展系統和用戶定製機制。

擴展原則 (設計着眼將來，將來總比預想來得快)

要爲數據格式和代碼留下擴展的空間，不然就會發現本身經常被原先不明智選擇捆住了手腳，由於你沒法既要改變它們又要維持對原來的兼容性。

設計協議或是文本格式時，應使其具備充分的自描述性以即可以擴展。要麼包含進一個版本號，要麼採用獨立、自描述的語句、按照能夠隨時插入新的而不會搞亂格式讀取代碼的方法組織格式。