一次隻做一件事，并做到極緻。
《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)
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)
原文：開發人員應該通過使其協定可擴充來設計未來，允許輕松插件，而無需修改其他開發人員的程式架構。
![Cloud Studio初體驗[圖]](data:image/gif;base64,R0lGODlhAQABAIAAAP///wAAACwAAAAAAQABAAACAkQBADs=)