你的代碼有重複嗎？

【編者按】本文做者爲來自 SoftwareYoga.com 的軟件架構師、敏捷與 DevOps 開發流程踐行者 Deepak Karanth，文章主要介紹了 DRY 原則的諸多優勢。

本文系國內 ITOM 管理平臺 OneAPM 編譯呈現。如下爲正文：

「避免重複代碼」(DRY) 是軟件發展的一項原則，其主旨是減小代碼重複現象。

「全部內容寫兩遍」(WET) 則是上述原則的反義縮寫，意指不遵照 DRY 原則的代碼。

開發人員應當以其中哪一個原則爲目標本應是顯而易見的。可是，也許這個時候已經有人開始拿出證據來證實我是錯的。

在本文中，咱們會逐一討論編寫代碼時遵循 DRY 原則的好處。首先，咱們先舉一個簡單的例子來講明 DRY 原則的基本優點。

DRY 原則 - 簡單例子

假設你的代碼中有不少地方須要根據當前用戶的角色來執行。好比：只有編輯或管理員才能夠執行 createPage() 函數，只有管理員纔可執行 deletePage() 函數。

在creatPage（建立頁面）和 deletePage（刪除頁面）函數檢查用戶的角色時，咱們可使用下面這個 isPermitted() 單一函數，而不是分別開展用戶角色檢查的邏輯。

//get the current Subject
Subject currentUser = context.getSubject();

if (isPermitted(currentUser)) {    
 //allow execution of deletePage} 
 else {    
 //block execution
}

將 isPermitted() 的邏輯固定在一個地方，就能夠避免重複，同時反覆利用代碼。另一個優點就是邏輯的獨立性，即 createPage() 和 deletePage() 無需知道如何檢查權限。

固然，DIY 原則的優點遠不止這樣。

DRY 原則的優點

可維護性

DRY 原則的最大優點是可維護性。若是檢查權限的邏輯在整段代碼中重複不少次，在重複代碼中出現的問題將很難修復。修復一段代碼中的某個問題後，很容易忘記修復其餘重複代碼中一樣存在的問題。一樣，若是須要修改邏輯，就得四處複製粘貼。若是使用不重複的代碼，只需在一處維護代碼便可。新的邏輯和漏洞修復都只需在一處進行，沒必要再四處徘徊。經過這種方式開發的軟件既穩定又可靠。

可讀性高

大多數狀況下，遵循 DRY 原則的代碼更容易閱讀。這並非由於 DRY 原則自己，而是由於開發人員在代碼中投入了更多精力，讓它符合必定的原則（好比 DRY 原則）。

重複使用

DRY 原則始終提倡二次利用代碼，這是由於咱們會將2個或2個以上重複代碼實例併入一個代碼塊。可重用代碼縮短了開發時間，所以從長遠看，可重用代碼是有回報的。

成本合理

若是想說服管理層用更多的時間來提升代碼質量，就能夠用「成本」這個理由。代碼越長，成本越高。代碼越長，維護代碼、修復漏洞所需的人手和時間也越多。代碼越長，開發時間和漏洞也越多，結果就是客戶很是不滿。無庸贅述。

測試方便

這裏咱們討論的是模塊測試和集成測試，而不是手動測試。測試時須要覆蓋的路徑和功能越多，爲測試而編寫的代碼就會越長。若是代碼不重複，就只須要測試一個主路徑。固然，不一樣的行爲仍然須要接受測試。

注意事項

雖然 DRY 原則好處多多，但仍是有幾個小缺陷。

1. 不是全部代碼都須要整合成一段。有時候2段代碼看上去差很少，但卻存在細微差別。何時應當將代碼段整合成一段，何時又應當讓它們保持分離狀態，都須要仔細斟酌。

2. 若是代碼太過簡略，會讓人難以理解。我曾見過開發人員在只有一個代碼塊實例時，還要貫徹 DRY
   原則。雖然我欣賞他們但願讓代碼更出色、可重用率更高的想法和遠見，可是我只有在須要二次利用代碼時纔會去遵循 DRY 原則。

3. 人們常常會忽略的是，DRY 原則並不只僅適用於代碼，它還能夠同等地應用到數據庫設計、文檔編寫、代碼測試等方面。

OneAPM 能爲您提供端到端的 Java 應用性能解決方案，咱們支持全部常見的 Java 框架及應用服務器，助您快速發現系統瓶頸，定位異常根本緣由。分鐘級部署，即刻體驗，Java 監控歷來沒有如此簡單。想閱讀更多技術文章，請訪問 OneAPM 官方技術博客。

本文轉自 OneAPM 官方博客

原文地址：https://dzone.com/articles/is-your-code-dry-or-wet