提公升程式設計師效率

筆者工作多年，總結了一些經驗，可以幫助大家成為乙個更加高效的程式設計師。

程式設計法則，與設計和工程的原理密切相關。下面這些程式設計法則幫助我讓我獲益匪淺，所以我想分享給大家，希望也能幫助大家更高效，生產出的**更容易維護，並且bug和缺陷更少。

dry原則

不要重複(don』t repeat yourself)——程式設計中乙個最根本的原則就是要避免重複。許多程式設計結構(比如迴圈、函式、類等)的存在就是為了避免重複。一旦重複(例如，乙個長表示式，一系列語句，相同的概念)的話，就會建立乙個新的抽象。

抽象原則

「每個在程式中有意義的功能片段應該只在源**的一處地方實現。」

kiss(keep it ******, stupid!)原則

簡單性(避免複雜性)應該永遠當作是乙個重要的目標。寫簡單的**，不但花費的時間少，錯誤少，而且修改起來也容易。

避免建立yagni(you aren』t going to need it)原則

只有當你需要的時候才去新增額外的功能，不需要就不要畫蛇添足。

方法要最簡單，效果要一樣好

在程式設計時，我們需要問問自己：「有沒有最簡單的完成任務的途徑?」這有助於我們保持一直行走在簡約設計的道路上。

不要讓我思考

這實際上是由steve krug寫的一本書的書名。關鍵要點是，**應該盡可能地易於閱讀和理解。如果閱讀人需要大量的思考才能理解**，那麼或許這**還需要被簡化。

開/閉原則

軟體實體(類，模組，函式等)在擴充套件時應該開放，在修改時應該關閉。換句話說，你寫的類大家可以擴充套件，但不能修改。

為維護者寫**

值得寫的**要保證將來一定值得維護。未來的你由於經歷的**太多，也許再回過頭來看這些**的時候，也和其他人一樣，已經成為了乙個完全的陌生人。請記住，「寫**的時候，就假設將來要維護的人是個知道你住在**的暴力型精神病患者吧。」

最小驚訝原則

最小驚訝原則通常引用於使用者介面方面，但這一原則也適用於編寫**。**應該盡可能地不要讓閱讀者驚訝。遵守標準約定，注釋說什麼**就做什麼，命名是什麼意思**就是什麼意思，盡可能地避免驚訝導致的潛在的負面影響。

單一職責原則

**(如類或函式)的組成部分執行的應該是乙個單一的明確的任務。

最小化耦合原則

**的任何部分(**塊，函式，類等)都應該儘量減少對其他**的依賴。這可以通過盡量不要使用共享變數來實現。「低耦合常常是計算機系統構造良好和設計良好的標誌，並且當和高內聚力相結合的話，還可以大大支援高可讀性和可維護性的整體目標。」

最大化內聚原則

具有相似功能的**應該放在同乙個元件內。

隱藏實現細節原則

隱藏實現細節，允許在改變**元件的實現的同時，最低限度地減少對使用該元件的其他模組的影響。

得墨忒耳定律

**元件應該只和它們的直接關係(如，繼承的類，包含的物件，通過引數傳遞的物件等)溝通。

避免過早優化原則

除非**開始工作，否則甚至就不要有優化的念頭。只有當你必須要優化的時候，才能借助實戰資料的幫助。「我們一定要有大局觀：過早的優化是萬惡之源」——donald knuth。

重用**才是好**

這和任何其他法則一樣之精闢。重用**可以提高**的可靠性，並減少開發時間。

關注點分離原則

不同的功能區域應該由明顯的重疊最小的**模組進行管理。

擁抱變化原則

這是kent beck寫的一本書的副標題，也被認為是極端程式設計和通用敏捷方法的原則。許多其他原則都基於這個理念：你應該期待和歡迎變化。事實上，很多古老的軟體工程法則，例如最小化耦合原則，就是和讓**變得更容易改變是直接相關的。無論你是不是乙個極端程式設計的實踐者，這種寫**的方法真的很有意義。