優秀程序員的18大法則

DRY原則

不要重複（Don’t repeat yourself）——程序設計中一個最根本的原則就是要避免重複。許多編程結構（好比循環、函數、類等）的存在就是爲了不重複。一旦重複（例如，一個長表達式，一系列語句，相同的概念）的話，就會建立一個新的抽象。

 

抽象原則

「每一個在程序中有意義的功能片斷應該只在源代碼的一處地方實現。」

 

KISS（Keep it simple, stupid!）原則

簡單性（避免複雜性）應該永遠看成是一個重要的目標。寫簡單的代碼，不但花費的時間少，錯誤少，並且修改起來也容易。

 

避免建立YAGNI（You aren’t going to need it）原則

只有當你須要的時候纔去添加額外的功能，不須要就不要多此一舉。

 

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

在編程時，咱們須要問問本身：「有沒有最簡單的完成任務的途徑？」這有助於咱們保持一直行走在簡約設計的道路上。

 

不要讓我思考

這其實是由Steve Krug寫的一本書的書名。關鍵要點是，代碼應該儘量地易於閱讀和理解。若是閱讀人須要大量的思考才能理解代碼，那麼或許這代碼還須要被簡化。

 

開/閉原則

軟件實體（類，模塊，函數等）在擴展時應該開放，在修改時應該關閉。換句話說，你寫的類你們能夠擴展，但不能修改。

 

爲維護者寫代碼

值得寫的代碼要保證未來必定值得維護。將來的你因爲經歷的代碼太多，也許再回過頭來看這些代碼的時候，也和其餘人同樣，已經成爲了一個徹底的陌生人。請記住，「寫代碼的時候，就假設未來要維護的人是個知道你住在哪裏的暴力型精神病患者吧。」

 

最小驚訝原則

最小驚訝原則一般引用於用戶界面方面，但這一原則也適用於編寫代碼。代碼應該儘量地不要讓閱讀者驚訝。遵照標準約定，註釋說什麼代碼就作什麼，命名是什麼意思代碼就是什麼意思，儘量地避免驚訝致使的潛在的負面影響。

 

單一職責原則

代碼（如類或函數）的組成部分執行的應該是一個單一的明確的任務。

 

最小化耦合原則

代碼的任何部分（代碼塊，函數，類等）都應該儘可能減小對其餘代碼的依賴。這能夠經過儘可能不要使用共享變量來實現。「低耦合經常是計算機系統構造良好和設計良好的標誌，而且當和高內聚力相結合的話，還能夠大大支持高可讀性和可維護性的總體目標。」

 

最大化內聚原則

具備類似功能的代碼應該放在同一個組件內。

 

隱藏實現細節原則

隱藏實現細節，容許在改變代碼組件的實現的同時，最低限度地減小對使用該組件的其餘模塊的影響。

 

得墨忒耳定律

代碼組件應該只和它們的直接關係（如，繼承的類，包含的對象，經過參數傳遞的對象等）溝通。

 

避免過早優化原則

除非代碼開始工做，不然甚至就不要有優化的念頭。只有當你必需要優化的時候，才能藉助實戰數據的幫助。「咱們必定要有大局觀：過早的優化是萬惡之源」——Donald Knuth。

 

重用代碼纔是好代碼

這和任何其餘法則同樣之精闢。重用代碼能夠提升代碼的可靠性，並減小開發時間。

 

關注點分離原則

不一樣的功能區域應該由明顯的重疊最小的代碼模塊進行管理。

 

擁抱變化原則

這是Kent Beck寫的一本書的副標題，也被認爲是極端編程和通用敏捷方法的原則。許多其餘原則都基於這個理念：你應該期待和歡迎變化。事實上，不少古老的軟件工程法則，例如最小化耦合原則，就是和讓代碼變得更容易改變是直接相關的。不管你是否是一個極端編程的實踐者，這種寫代碼的方法真的頗有意義