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

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

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

[[212220]]

說到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條規則說完了，字還是有點多，你能看到這里，已經很厲害了。

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

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

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