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

• 計算機編程的本質(zhì)就是控制復雜度。

• 用清晰的接口把若干簡單的模塊組合成一個復雜軟件。如此一來，多數(shù)問題只會局限于某個局部，那么就還有希望對局部進行改進而不至牽動全身。

清晰原則：清晰勝于機巧

• 維護如此重要而成本如此高昂；在寫程序時，要想到你不是寫給執(zhí)行代碼的計算機看的，而是給人——將來閱讀維護源碼的人，包括你自己——看的。

組合原則：設計時考慮拼接組合

• 在輸入輸出方面，Unix傳統(tǒng)極力提倡采用簡單化、文本化、面向流、設備無關的格式。

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

簡潔原則：設計要簡潔，復雜度能低則低

• 來自多方面的壓力常常會使程序變得復雜，其中一種就是來自技術上的虛榮心理。

• 過度的復雜性往往來自項目的要求，而這些要求常常基于當月的推銷熱點，而不是給予顧客的需求和軟件實際能提供的功能。

• 要避免這些陷阱，唯一的辦法就是鼓勵另一種軟件文化，以簡潔為美，人人對龐大復雜的東西群起而攻之——這是一個非常看重簡單解決方案的工程傳統(tǒng)，總是設法將程序系統(tǒng)分解為幾個能夠協(xié)作的小部分，并本能的抵制任何用過多噱頭來粉飾程序的企圖。

吝嗇原則：除非別無他法，不要編寫龐大的程序

透明性原則：設計要可見，以便審查和調(diào)試

• 因為調(diào)試通常會占用四分之三甚至更多的開發(fā)時間，所以一開始就多做點工作以減少日后調(diào)試的工作量會很劃算。一個特別有效的減少調(diào)試工作量的方法就是設計時充分考慮透明性和顯見性。

健壯性：健壯源于透明和簡潔

表示原則：把知識疊入數(shù)據(jù)以求邏輯質(zhì)樸而健壯

• 數(shù)據(jù)要比編程邏輯更容易駕馭。所以接下來，如果要在復雜數(shù)據(jù)和復雜代碼中選擇一個，寧愿選擇前者。更進一步：在設計中，你應該主動將代碼的復雜度轉(zhuǎn)移到數(shù)據(jù)之中去。

通俗原則：接口設計避免標新立異

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

緘默原則：如果一個程序沒有什么好說的，就保持沉默

補救原則：出現(xiàn)異常時，馬上退出并給出足量錯誤信息

• 軟件要盡可能從容的應付各種錯誤輸入和自身的運行錯誤。但是，如果做不到這一點，就讓程序盡可能以一種容易診斷錯誤的方式終止。

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

生成原則：避免手工hack，盡量編寫程序去生成程序

優(yōu)化原則：雕琢前先得有原型，跑之前先學會走

• 90%的功能現(xiàn)在能實現(xiàn)，比100%的功能永遠實現(xiàn)不了強。做好原型設計可以幫助你避免為蠅頭小利而投入過多的時間。

• 先制作原型，再精雕細琢。優(yōu)化之前先確保能用。

• 先給你的設計做個未優(yōu)化的、運行緩慢、很耗內(nèi)存但是正確的實現(xiàn)，然后進行系統(tǒng)地調(diào)整，尋找那些可以通過犧牲最小局部簡潔性而獲得較大性能提升的地方。

多樣原則：決不相信所謂的“不二法門”的斷言

擴展原則：設計著眼未來，未來總比預想快

• 要為數(shù)據(jù)格式和代碼留下擴展的空間。

• 設計協(xié)議或者文件格式時，應使其具有充分的自描述性以便可以擴展。