1 Unix哲學

Unix 哲學注重實效，立足于豐富的經驗，并不會在正規方法學和標準中找到它，它更接近于隱性的半本能的知識。Unix程序員在探索開發的過程中積累的經驗，非Unix的程序員也能夠從這些經驗中獲益。

(1)  讓每個程序就做好一件事。如果有新任務，就重新開始，不要往原程序中加入新功能而搞得復雜。
(2)  假定每個程序的輸出都會成為另一個程序的輸入，哪怕那個程序還是未知的，輸出中不要有無關的信息干擾。
(3)  盡可能早地將設計和編譯的軟件投入試用，對拙劣的代碼別猶豫，扔掉重寫。
(4)  優先使用工具而不是拙劣的幫助來減輕編程任務的負擔，工欲善其事，必先利其器。

2 編碼原則

Unix 哲學中的內容不是這些先哲們口頭表述出來的，而是由他們所做的一切和Unix 本身所作出的榜樣體現出來的。從整體上來說，可以概括為以下幾點：

1. 模塊原則：使用簡潔的接口拼合簡單的部件。
2. 清晰原則：清晰勝于機巧。
3. 組合原則：設計時考慮拼接組合。
4. 分離原則：策略同機制分離，接口同引擎分離。
5. 簡潔原則：設計要簡潔，復雜度能低則低。
6. 吝嗇原則：除非確無它法，不要編寫龐大的程序。
7. 透明性原則：設計要可見，以便審查和調試。
8. 健壯原則：健壯源于透明與簡潔。
9. 表示原則：把知識疊入數據以求邏輯質樸而健壯。
10. 通俗原則：接口設計避免標新立異。
11. 緘默原則：如果程序沒什么好說的，就保持沉默。
12. 補救原則：出現異常時，馬上退出并給出足量錯誤信息。
13. 經濟原則：寧花機器一分，不花程序員一秒。
14. 生成原則：避免手撕,  盡量編寫程序去生成程序。
15. 優化原則：雕琢前先要有原型，跑之前先學會走。
16. 多樣原則：決不相信所謂“不二法門”的斷言。
17. 擴展原則：設計著眼未來，未來總比預想來得快。
18. 關注微信公眾號【嵌入式系統】

如果剛開始接觸，這些原則值得好好體味一番。談軟件工程的文章常常會推薦大部分的這些原則，但是大多數其它系統缺乏恰當的工具和傳統將這些準則付諸實踐，所以，多數的程序員還不能自始至終地貫徹這些原則。蹩腳的工具、糟糕的設計、過度的勞作和臃腫的代碼對他們已經是家常便飯了。

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

“計算機編程的本質就是控制復雜度” 。排錯占用了大部分的開發時間，一個拿得出手的可用系統，與其說是出自才華橫溢的設計成果，不如說是跌跌撞撞的結果。

匯編語言、編譯語言、流程圖、過程化編程、結構化編程、面向對象、以及軟件開發的方法論，不計其數的解決之道被拋售者吹得神乎其神。實際上這些用處不大，原因恰恰在于它們“成功”地將程序的復雜度提升到了人腦幾乎不能處理的地步。

要編制復雜軟件而又不至于一敗涂地的唯一方法就是降低其整體復雜度，用清晰的接口把若干簡單的模塊組合成一個復雜軟件。如此一來，多數問題只會局限于某個局部，那樣才有希望對局部進行改進而不至牽動全身。

2.2  清晰原則：清晰勝于機巧

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

在 Unix 傳統中，這個建議不僅意味著代碼注釋。良好的 Unix 實踐同樣信奉在選擇算法和實現時，應該考慮到將來的可擴展性。為了取得程序一丁點的性能提升，就大幅增加技術的復雜性和晦澀性，這個買賣做不得，這不僅僅是因為復雜的代碼容易滋生bug，也因為它會使日后的閱讀和維護工作更加艱難。相反，優雅而清晰的代碼不僅不容易崩潰，而且更易于讓后來的修改者立刻理解。這點非常重要，尤其是，說不定若干年后回過頭來修改這些代碼的人可能恰恰就是自己。

永遠不要去吃力地解讀一段晦澀的代碼三次。第一次也許僥幸成功，但如果發現必須重新解讀一遍——離第一次太久了，具體細節無從回想，那就該注釋代碼了，這樣第三次就相對不會那么痛苦了。

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

如果程序彼此之間不能有效通信，那么軟件就難免會陷入復雜度的泥淖。

在輸入輸出方面， Unix 傳統極力提倡采用簡單、文本化、面向流、設備無關的格式。在經典的 Unix 下，多數程序都盡可能采用簡單過濾器的形式，即將一個輸入的文本流處理為一個簡單的文本流輸出。拋開世俗眼光，Unix程序員偏愛這種做法并不是因為他們仇視圖形用戶界面，而是因為如果程序不采用簡單的文本輸入輸出流，它們就極難銜接。

Unix 中文本流之于工具，就如同在面向對象環境中的消息之于對象。文本流界面的簡潔性加強了工具的封裝性。而許多精致的進程間通訊方法，比如遠程過程調用，都存在各程序牽扯過多的傾向。

要想讓程序具有組合性，就要使程序彼此獨立。在文本流這一端的程序應該盡可能不要考慮文本流另一端的程序。將一端的程序替換為另一個截然不同的程序，而完全不驚擾另一端應該很容易做到。GUI  可以是個好東西，在做 GUI前，應該想想可不可以把復雜的交互程序跟干粗活的算法程序分離開，每個部分單獨成為一塊，然后用一個簡單的命令流或者是應用協議將其組合在一起。

在構思精巧的數據傳輸格式前，有必要實地考察一下，是否能利用簡單的文本數據格式；以一點點格式解析的代價，換得可以使用通用工具來構造或解讀數據流的好處是值得的。

當程序無法自然地使用序列化、協議形式的接口時，正確的 Unix 設計至少是，把盡可能多的編程元素組織為一套定義良好的 API 。這樣至少可以通過鏈接調用應用程序，或根據不同任務的需求粘合使用不同的接口。

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

策略和機制是按照不同的時間尺度變化的，策略的變化要遠遠快于機制。把策略同機制揉成一團有兩個負面影響：一來會使策略變得死板，難以適應用戶需求的改變，二來也意味著任何策略的改變都極有可能動搖機制。相反，將兩者剝離，就有可能在探索新策略的時候不足以打破機制。另外，也更容易為機制寫出較好的測試。

實現剝離的一個方法，將應用程序分成可以協作的前端和后端進程，通過套接字上層的專用應用協議進行通訊。前端實現策略，后端實現機制。比起僅用單個進程的整體實現方式來說，這種雙端設計方式大大降低了整體復雜度 ，bug 有望減少，從而降低程序的壽命周期成本。

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

來自多方面的壓力常常會讓程序變得復雜（由此代價更高， bug  更多)，其中 一種壓力就是來自技術上的虛榮心理。程序員們都很聰明，常常以能玩轉復雜東西和耍弄抽象概念的能力為傲，這一點也無可厚非。但正因如此常常會與同行們比試，看看 誰能夠鼓搗出最錯綜復雜的美妙事物，他們的設計能力大大超出他們的實現和排錯能力，結果便是代價高昂的廢品。

”錯綜復雜的美妙事物”聽來自相矛盾。Unix  程序員相互比的是誰能做到 “簡潔而漂亮”，這一點雖然只是隱含在這些規則之中，但還是很值得公開提出來強調一下。

至少在商業軟件領域里，過度的復雜性往往來自于項目的要求，而這些要求常常基于推銷熱點，而不是基于顧客的需求和軟件實際能夠提供的功能。許多優秀的設計被市場推銷所需要的大堆“特性清單”扼殺，實際上這些特性功能幾乎從未用過。然后，惡性循環開始了，比別人花哨的方法就是把自己變得更花哨。很快，龐大臃腫變成了業界標準，每個人都在使用臃腫不堪、bug 極多的軟件，連軟件開發人員也不敢敝帚自珍。

避免這些陷阱，唯一的方法就是鼓勵另一種軟件文化，以簡潔為美。這是一個非常看重簡單解決方案的工程傳統，總是設法將程序系統分解為幾個能夠協作的小部分，并本能地抵制任何用過多噱頭來粉飾程序的企圖。

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

“大”有兩重含義：體積大，復雜程度高。程序大了，維護起來就困難。由于對花費了大量精力才做出來的東西難以割舍，結果導致在龐大的程序中，把投資浪費在注定要失敗，或并非最佳的方案上。避免不必要的代碼和邏輯，保持代碼精簡。

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

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

軟件系統的透明性是指一眼就能看出軟件在做什么以及怎樣做的。顯見性指程序帶有監視和顯示內部狀態的功能，這樣程序不僅能夠運行良好，而且還可以看出它以何種方式運行。

設計時如果充分考慮到這些要求會給整個項目全過程帶來好處。調試選項的設置盡量不要在事后，而應該在設計之初便考慮進去，程序不但應該能展示其正確性，也應該能把原開發者解決問題的思維模型告訴后來者。

程序如果要展示其正確性，應該使用足夠簡單的輸入輸出格式，這樣才能保證很容易地檢驗有效輸入和正確輸出之間的關系是否正確。出于充分考慮透明性和顯見性的目的，還應該提倡接口簡潔，以方便其它程序對其進行操作，尤其是測試監視工具和調試腳本。關注微信公眾號【嵌入式系統】

2.8  健壯原則：健壯源于透明與簡潔

軟件的健壯性指軟件不僅能在正常情況下運行良好，而且在超出設想的意外條件下也能夠運行良好。

大多數軟件禁不起磕碰，毛病多，就是因為過于復雜，很難通盤考慮。如果不能正確理解一個程序的邏輯，就不能確信其是否正確，也就不能在出錯的時候修復它。讓程序健壯的方法，就是讓程序的內部邏輯更易于理解，要做到這一點主要有兩種方法：透明化和簡潔化。

就健壯性而言，設計時要考慮到能承受極端輸入，這一點也很重要。在有異常輸入的情況下，保證軟件健壯性的一個相當重要的策略就是避免在代碼中出現特例，bug  通常隱藏在處理特例的代碼以及處理不同特殊情況的交互操作部分的代碼中。

軟件的透明性就是指一眼就能夠看出來是怎么回事。如果“怎么回事”不算復雜，即不需要絞盡腦汁就能夠推斷出所有可能的情況，那么這個程序就是簡潔的。程序越簡潔，越透明，也就越健壯。

模塊化(代碼簡樸，接口簡潔)是組織程序以達到更簡潔目的的一個方法。

2.9  表示原則：把知識疊入數據以求邏輯質樸而健壯

數據要比編程邏輯更容易駕馭，在設計中，應該主動將代碼的復雜度轉移到數據之中去。

此種考量并非 Unix 的原創，但是許多 Unix 代碼都顯示受其影響。特別是C 語言對指針使用控制的功能，促進了在內核以上各個編碼層面上對動態修改引用結構。在結構中用非常簡單的指針操作就能夠完成的任務，在其它語言中，往往不得不用更復雜的過程才能完成。

進行數據驅動編程時，需要把代碼和代碼作用的數據結構劃分清楚，這樣，在改變程序的邏輯時，只要編輯數據結構而不是代碼。數據驅動編程有時會跟面向對象混淆起來，后者是另一種以數據組織為中心的風格。它們之間至少有兩點不同。第一，在數據驅動編程中，數據不僅僅是某個對象的狀態，實際上還定義了程序的控制流；第二，面向對象首先考慮的是封裝，而數據驅動編程看重的是編寫盡可能少的固定代碼。

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

也就是眾所周知的“最少驚奇原則”。最易用的程序就是用戶需要學習新東西最少的程序，就是最切合用戶已有知識的程序。因此，接口設計應該避免毫無來由的標新立異和自作聰明。

如果你編制一個計算器 程序，  ‘+’應該永遠表示加法。設計接口的時候，盡量按照用戶最可能熟悉的同樣功能接口和相似應用程序來進行建模。

關注目標受眾，他們也許是最終用戶，也許是其他程序員，也許是系統管理員。對于這些不同的人群，最少驚奇的意義也不同。關注傳統慣例，這些慣例的存在有個極好的理由：緩和學習曲線。

最小立異原則的另一面是避免表象相似而實際卻略有不同。這會極端危險， 因為表象相似往往導致人們產生錯誤的假定。所以最好讓不同事物有明顯區別，而不要看起來幾乎一模一樣。

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

行為良好的程序應該默默工作，決不嘮嘮叨叨。沉默是金，這個原則的起始是源于Unix 誕生時還沒有視頻顯示器，每一行多余的輸出都會嚴重消耗用戶的寶貴時間。現在這種情況已不復存在， 但一切從簡的這個優良傳統流傳至今。

簡潔是 Unix 程序的核心風格。一旦程序的輸出成為另一個程序的輸 入，就很容易把需要的數據挑出來。站在人的角度上來說，重要信息不應該混雜在冗長的程序內部行為信息中。如果顯示的信息都是重要的，那就不用找了。設計良好的程序將用戶的注意力視為有限的寶貴資源，只有在必要時才要求使用，避免不必要的信息對用戶的打擾。

2.12  補救原則：出現異常時，馬上退出并給出足量錯誤信息

軟件在發生錯誤的時候也應該與在正常操作的情況下一樣，有透明的邏輯。最理想的情況當然是軟件能夠適應和應付非正常操作；而如果補救措施明明沒有成功，卻悄無聲息地埋下崩潰的隱患，直到很久以后才顯現出來，這就是最壞的一種情況。

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

“寬容地收，謹慎地發”。就算輸入的數據不規范，設計良好的程序也會盡量領會其中的意義，盡量與別的程序協作；然后，要么響亮地倒塌，要么為工作鏈下一環的程序輸出一個嚴謹干凈正確的數據。

設計時要考慮寬容性，不是用過分縱容的實現來補救標準的不足，否則一不留神你會死得很難看。

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

在 Unix.早期的小型機時代，這一條觀點還是相當激進的；隨著技術的發展，開發公司和大多數用戶都能夠得到廉價的機器，所以這一準則的合理性就不用多說。

在保證質量的前提下，盡量使用計算機資源完成任務，減輕程序員負擔，另一個可以顯著節約程序員時間的方法是，教會機器如何做更多低層次的編程工作。關注微信公眾號【嵌入式系統】

2.14  生成原則：避免手撕, 盡量編寫程序去生成程序

眾所周知，人類很不善于干辛苦的細節工作。程序中的任何手工操作都是滋生錯誤和延誤的溫床，由程序生成代碼幾乎總是比手寫代碼廉價并且更值得信賴。

對于代碼生成器來說，需要手寫的重復而麻木的高級語言代碼，與機器碼一樣是可以批量生產的。當代碼生成器能夠提升抽象度時，即當生成器的說明性語句要比生成碼簡單時，使用代碼生成器會很合算，而生成代碼后就根本無需再費力地去手工處理。在 Unix 中大量使用代碼生成器使易于出錯的細節工作自動化。

2.15  優化原則：雕琢前先得有原型，跑之前先學會走

原型設計最基本的原則，“90%的功能現在能實現，比100%的功能永遠實現不了強”。做好原型設計可以避免為蠅頭小利而投入過多的時間。

“ 不應考慮蠅頭小利的效率提升，過早優化是萬惡之源”，不知道瓶頸所在就匆忙進行優化，這可能是唯一一個比亂加功能更損害設計的錯誤。從畸形的代碼到雜亂無章的數據布局，犧牲透明性和簡潔性而片面追求速度，滋生無數 bug,   耗費以百萬計的人時，這點芝麻大的好處，遠不能抵消后續排錯所付出的代價。

過早的局部優化實際上會妨礙全局優化，從而降低整體性能。在整體設計中可以帶來更多效益的修改常常會受到一個過早局部優化的干擾，導致出來的產品既性能低劣又代碼過于復雜。

在 Unix 世界里，有一個非常明確的悠久傳統：先制作原型，再精雕細琢。優化之前先確保能用，先能走，再學跑。從另一種不同的文化將這一點有效地擴展為：先求運行，再求正確，最后求快。

所有這些話的實質其實是一個意思：先設計做個未優化的、運行緩慢、很耗內存但是正確的實現，然后進行系統地調整，尋找那些可以通過犧牲最小的局部簡潔性而獲得較大性能提升的地方。

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

即使最出色的軟件也常常會受限于設計者的想象力。沒有人能聰明到把所有東西都最優化，也不可能預想到軟件所有可能的用途。

對于軟件設計和實現來說，Unix 傳統有一點很好，即從不相信任何所謂的“不二法門”。Unix 奉行的是廣泛采用多種語言、開放的可擴展系統和用戶定制機制；吸收并借鑒各種優秀的設計思想，不斷完善自己的設計方法和風格。

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

為數據格式和代碼留下擴展的空間，否則，就會發現常常被原先的不明智選擇捆住了手腳，因為無法既要改變它們又要維持對原來的兼容性。

設計協議或文件格式時，應使其具有充分的自描述性以便可擴展。要么包含版本號，要么采用獨立、自描述的語句，按照可以隨時插入新的、換掉舊的，而不會破壞格式讀取代碼的方法組織格式。Unix 經驗表示：稍微增加一點讓數據部署具有自描述性的開銷，就可以在無需破壞整體的情況下進行擴展，小的付出也可得到成千倍的回報。

設計代碼時，要有很好的組織，讓將來的開發者增加新功能時無需拆毀或重建整個架構。這個原則并不是說隨意增加根本用不上的功能，而是建議在編寫代碼時要考慮到將來的需要，使以后增加功能比較容易。程序接合部要靈活，在代碼中加入“如果擴展...需要…”的注釋,有義務給之后使用和維護自己編寫的代碼的人做點好事，也許將來就是自己來維護代碼，設計為將來著眼，節省的有可能就是自己的精力。

3 應用Unix哲學

這些富有哲理的原則決不是模糊籠統的泛泛之談。在Unix 世界中，這些原則都直接來自于實踐，并形成了具體的規定。

運用Unix 哲學，就應該不斷追求卓越。軟件設計是一門技藝，值得付出智慧、創造力和激情。否則就不會超越那些簡單、老套的設計和實現；就會在應該思考的時候急急忙忙去編程，就會在該無情刪繁就簡的時候反而把問題復雜化，就會反過來抱怨代碼怎么那么臃腫、難以調試。

要良好地運用 Unix 哲學，永遠不要蠻干；要多用巧勁，省下力氣到需要的時候再用，好鋼用在刀刃上。善用工具，盡可能將一切都自動化。

4 態度

軟件設計和實現是一門充滿快樂的藝術， 一種高水平的游戲。為什么要從事軟件設計而不是別的呢?可能現在只是為了賺錢或打發時間，也可能曾經也認為軟件設計改變世界，值得付出激情。