Unix哲學17條原則的新感悟

現在，說到作業系統，談論最多的就是Android，ios，Linux，mac os，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 of Parsimony)

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

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

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

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條規則說完了，字還是有點多，你能看到這裡，已經很厲害了。你可能發現了，我並沒有說規則的具體應用，是的，畢竟有這麼多原則，每一個原則都夠寫一篇長文了。今天先按照一般思路解讀一下，以後如果在實踐中用到了，再詳細解釋如何應用已經發展變化。希望這些規則能給你一些新的啟發。