關於Unix哲學17條原則的新感悟

持續踐行，我們一路同行

全文 4622 字 | 建議閱讀 9 分鐘

文 | mickjoust

現在，說到操作系統，談論最多的就是Android，ios，Linux，macos，windows，已經很少有人會使用到unix系統了，除了一些企業內部的系統，和編程愛好者社區會交流外，基本上已經絕跡於江湖了。

但是，像某些行業里，因為會和高端的伺服器配合使用，而惠普和IBM又是伺服器裡面的王者，所以，類UNIX系統像AIX，其實還是在使用的，orcale，emc等公司其實還是會用。

可能你沒有聽懂，但是沒有關係，可以選擇強行記憶，下次你也好給朋友吹個牛什麼的。

說到unix，就要提到一個人，埃里克·史蒂文·雷蒙德，他是一個老黑客，一個作家，一個自由軟體的倡導和開創者，可能很多人都對他不是很了解，但是這本書卻是大名鼎鼎的——《UNIX編程藝術》，就算你沒看過，可能在網上閑逛時都瞄到這本書的名字。

最近，我也在看他寫的另一本書《大教堂與大集市》，深受啟發。

《UNIX編程藝術》一書，我在讀書時看過，但那時完全看不懂，裡面全都是講如何更好的編程的一些很抽象的東西，不過，還是咬牙勉強看完，後來編程實踐多了后，漸漸就能體會其中的精髓了。

現在想起，其中關於思維的原則，有很多值得參考的地方，於是拿出來和大家一起細細再品味一下。

最著名的就是他提出的17條編程原則，經過時間和實踐的錘鍊，發展成為Unix哲學17條原則，在維基百科能搜到。

下面就來說說我對這17要原則的解讀——

1、模塊化原則（Rule of Modularity）

原文：開發人員應該使用定義良好的界面連接簡單的部分來構建程序，所以問題是本地的，部分程序可以在未來的版本中替換以支持新的功能。此規則旨在節省調試複雜，長期且不可讀的代碼的時間。

解讀：這條規則，現在但凡學編程的人都知道，代碼要模塊化，這樣不僅方便別人復用，自己也能更便捷的替換新代碼。而實際上，不管是學習還是實踐中，模塊化原則都是非常好的一條原則，比如，我們學習寫作，如果能將一篇文章分模塊，並通過邏輯線索串聯起來，就能形成一篇不錯的文章，其實就是模塊化原則在起作用，我們常說的格式化寫作，就是這樣的。因為模塊是可以替換的，模塊是組成一堵牆的單元結構，可以是漂亮的空心磚，也可以是純色的實心磚。同樣，工作中也很實用，將不同的大任務分解成不同的小人物和模塊，逐個擊破，也是非常實用的，關鍵點就在於模塊化是可復用和可替換的。

2、清晰原則（Rule of Clarity）

原文：開發人員應該編寫清晰的程序，就好像最重要的溝通是向開發人員讀取和維護程序，而不是計算機。這個規則的目的是使代碼在將來的代碼中儘可能易讀和易理解。

解讀：清晰在編程中意味著當別人看你寫的代碼時，能明白其中的含義，同樣的，學習中也應該這樣，就像我們寫作就是為了梳理清楚我們的思考，表達出來讓別人理解一樣，看上去是在碼字，實際上是在和別人溝通交流。說一些模糊和含混的話是容易的，但是要想表達出想法，清晰是非常重要的。

3、和解原則（Rule of Composition）

原文：開發人員應該編寫能夠與其他程序輕鬆通信的程序。這條規則的目的是讓開發人員把項目分解成小而簡單的程序，而不是過於複雜的單片程序。

解讀：也叫適當妥協原則，這個原則在人際交往中應用得更多，還有就是自我思維中用得多，比如，一天我們想要鍛煉身體，跑5公里，於是感性會說，算了吧，有點冷，難得換衣服了吧，被窩很舒服，理性則會說，必須堅持，為了保持健康。於是，兩者開始協商，最後協商好了以後，就變成了穿保暖一點的衣服去跑步，適當降低運動量。而在與人的交流中，我們有時也會面臨自己的時間和別人時間衝突的時候，這時就會需要進行適當的和解以達成共識。和解原則更像一種處世原則，讓我們不能一味的強調自己，而要照顧別人的感受。

4、分離規則（Rule of Separation）

原文：開發者應該將程序的機制與程序的策略分開;一種方法是將程序分成與該介面通信的前端介面和後端引擎。這條規則旨在通過允許改變策略，儘可能降低操作機制的不穩定性來防止錯誤引入。

解讀：這個有點不好理解，實際上後來發展出來就是java里的按照介面編程，簡單說，就是A按照介面統一的協議來通信B，B提供相對應的具體功能實現，兩者是分開的，互補干擾，但是對達成的共識是沒有任何異議的，一旦要改變這個共識，需要重新協商並做好約束。舉個例子，比如汽車的輪胎，分離規則，就是說輪胎的製造商只需要按照統一的介面生產對應尺寸的輪胎就可以了，至於在哪裡生產，用什麼材料生產，汽車組裝時並不用關心，而和軸承對接的發動機同樣也可以是多樣化的。

5、簡單規則（Rule of Simplicity），6、簡約規則（Rule ofParsimony）

5原文：開發人員應該設計簡單的方法，通過尋找方法將程序系統分解成小而直接的合作件。這條規則的目的是阻止開發者寫作「複雜而美麗的複雜性」，這是現實中容易出錯的程序。

6原文：開發人員應該避免編寫大型程序。這一規則的目的是防止由於項目的所有者不願拋棄顯著的大量工作而導致失敗或次優方法的過度投資。較小的程序不僅易於編寫，優化和維護，棄用時更容易刪除。

解讀：這兩條規則是同一個意思，如果按照現在時髦的話說，就是一切都要盡量的小，盡量的簡便可執行。因為一旦沒有朝著簡單的方向去做，就會越來越龐大，這一點對於編程來說尤其重要，越是簡單的程序，越是容易維護，也容易發現問題。而那些看上去很複雜的程序，大多數都是冗餘和不必要的，而實際上，要想簡單，有時需要的反而是更強大的歸納總結能力。

持續踐行，我們一路同行

7、透明度原則（Rule of Transparency）

原文：開發人員應該設計可見性和可發現性，通過編寫這樣一種方式，他們的思維過程可以清楚地被未來的項目開發人員所看到，並使用輸入和輸出格式，以便識別有效輸入和正確輸出。此規則旨在減少調試時間並延長程序的使用壽命。

解讀：這條原則容易被誤解，對外部使用的人來說，只需要知道輸入和輸出就行了，比如計算器，按下數字進行加減乘除，只不過對於程序內部來說，透明是意味著要公開代碼，這樣才能更好的理解程序，方便改進程序。這條原則適用於自我提升，在反思中特別有用，比如寫下了一天的工作思考，然後自己順著寫下的思路開始復盤自己一天的思考邏輯，哪些做得好，哪些做的不好。但是同樣意味著，這樣私密的東西，不一定都要告訴別人。

8、穩健性規則（Rule of Robustness）

原文：開發人員應該通過設計透明和可發現性來設計強大的程序，因為易於理解的代碼更容易對複雜程序中無法預見的意外情況進行壓力測試。此規則旨在幫助開發人員構建強大，可靠的產品。

解讀：可靠性是我們一直都非常重視的，即便是移動互聯網如此發達今天，我們依然會遇見，程序APP崩潰，手機卡機的情況，實際上，這也是我們常說的反脆弱性，遇見一些特定的意外情況時，我們能不能夠應對和處理，就是我們平時在編寫我們自己這個「程序」時最重要的事了，有的人可靠性很高，一般的小打擊都是打不倒的，而有的人可靠性不那麼高，一點點挫折就會奔潰。說的就是這樣穩健性。

9、表示規則（Rule of Representation）

原文：開發人員在面對選擇時應該選擇使數據更複雜，而不是程序的邏輯，因為與複雜的邏輯相比，人類更容易理解複雜的數據。這條規則的目的是使任何開發項目的開發人員都可以使程序更易讀，從而使程序得以維護。

解讀：這條規則放在現在不是很適用了，因為有大數據，雖然人類擅長區分複雜的數據，但前提是數據量不是特別大，而按照今天大數據的量，還是更適合用機器去分析，有一門專業叫數據挖掘，專門干這個數據分析工作的。當然，邏輯清晰，數據詳實，是很好的說明文體，也是更多增加文章的可信性的，我們現在的調查研究和綜述報告就是這樣的。換句話說，就是要有清晰的思路，多樣的故事。

10、最小驚喜規則（Rule of Least Surprise）

原文：開發人員應該根據潛在用戶的預期知識設計程序。例如，計算器程序中的「+」應該總是指「加法」。該規則旨在鼓勵開發人員構建易於使用的直觀產品。

解讀：意味著要盡量的讓每個單元有一個獨立的功能，也是現在發展出來的微服務一說最早的出處了，現在因為大數據和分散式的關係，微服務越來越普及，換句話說，不僅是在編程里，即便在我們平時的生活中，也應該遵循這樣的原則，在某個時間裡，盡量的專心只做一件事，而不是想著要一心多用。

11、沉默的規則（Rule of Silence）

原文：開發人員應該設計程序，以免列印不必要的輸出。這個規則旨在允許其他程序和開發者從程序的輸出中挑出他們需要的信息，而不必分析冗長。

解讀：意思本來是說，為了調試方便，程序員常常打很多日誌，這樣容易造成信息泄露或引起性能問題，但是，我覺得這條規則更像是簡單規則的擴展，不過換個角度看，我們在思考的時候，需要適當的沉默，並不是所有的思考都要說出來，有的沒有醞釀好的思考可以暫時放一放，不要急於去表達對一個觀點的看法，應該儘可能多的搜集信息，再下結論。

12、修理規則（Rule of Repair）

原文：開發人員應該設計失敗的程序，易於本地化和診斷，換句話說就是「失敗」。這條規則旨在防止程序的錯誤輸出成為輸入，並破壞未被檢測到的其他代碼的輸出。

解讀：有錯誤的輸入沒有關係，關鍵是我們能不能調整並修復，就像現在很多人每天都接受很多垃圾信息一樣，並沒有意識到自己在接受拉結，更沒有處理應對的方法，這個原則告訴我們，當我們有了可以修理的意識后，對於輸入錯誤的輸入是可以控制的，在軟體測試里又叫邊界測試——通過輸入一些超過範圍的數值或非常規操作來測試輸入——這樣可以驗證系統的可靠性，一個軟體系統是一定存在某種問題的，有問題不可怕，可怕的是不知道問題出在哪裡。

持續踐行，我們一路同行

13、經濟規則（Rule of Economy）

原文：開發人員應該重視開發人員在機器上的時間，因為與上世紀70年代的價格相比，今天的機器周期相對便宜。這條規則旨在降低項目的開發成本。

解讀：這個規則有點矛盾，一方面想要說人力成本的問題，一方面又說隨著硬體價格的下降，成本的降低，我認為可以解釋為，投入的成本和產出的成本，程序員的工作就是耗費時間和機器作鬥爭，讓機器能按照人的意志而運行。付出成本是必然的，只要能在可接受的範圍內就行了。

14、生成規則（Rule of Generation）

原文：開發人員應該避免手動編寫代碼，而是編寫抽象的高級程序來生成代碼。此規則旨在減少人為錯誤並節省時間。

解讀：現在很多集成編程環境都有這樣的功能，對於一些固定規則的代碼，可以快速自動生成，避免手工編寫程序的錯誤。換句話說，就是我們常說的能用自動化替代的工作就用自動化，機器比人更能做好這些工作。但不是說人工的編寫就沒有意義，人工的操作就是為了糾正一些可能出現的錯誤，並處理核心邏輯。

15、優化規則（Rule of Optimization）

原文：開發人員應該在打磨軟體之前製作原型。這條規則旨在防止開發者花費太多時間來獲得邊際收益。

解讀：現在的軟體產品的製作，都會經過產品經理提出原型設計，在動手編寫程序前，已經會優化很多了。這個規則特別適合思維的迭代升級過程，因為當使用這樣的原則時，你會發現，自己的思考並不是完美的，而是存在很多漏洞的，但是有漏洞沒有關係，慢慢找到並優化，提升，最後達到更好的效果。

16、規則的多樣性（Rule of Diversity）

原文：開發者應該設計他們的程序是靈活的，開放的。這條規則的目的是使程序更加靈活，使其能夠以開發者所期望的方式使用。

解讀：規則的多樣性，就是我們的視角更多了，能應用的武器也更多了，因為思維武器是越多越好，因為視角就會越來越多，看待問題也會越來越精確。

17、可擴展性規則（Rule of Extensibility）

原文：開發人員應該通過使其協議可擴展來設計未來，允許輕鬆插件，而無需修改其他開發人員的程序架構。

解讀：擴展有點像多學一門技能和跨界，現在我們都提倡跨界，說的就是一個人的人生可能性，換句話說就是，人生的可擴展性很多，有的人不斷學習成長，可擴展性非常大，有的人剛開始很厲害，可沒有什麼擴展性，只能在原有的基礎上打轉。

好了，17條規則說完了，字還是有點多，你能看到這裡，已經很厲害了。

你可能發現了，我並沒有說規則的具體應用，是的，畢竟有這麼多原則，每一個原則都夠寫一篇長文了。

今天先按照一般思路解讀一下，以後如果在實踐中用到了，再詳細解釋如何應用已經發展變化。

希望這些規則能給你一些新的啟發。

持續踐行，從每天完成一件事開始。