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

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

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

清晰原則：清晰勝于機巧

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

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

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

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

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

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

• 過度的復雜性往往來自項目的要求，而這些要求常?；诋斣碌耐其N熱點，而不是給予顧客的需求和軟件實際能提供的功能。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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