你的程式碼有重複嗎？

OneAPM官方技術部落格發表於2016-05-04

【編者按】本文作者為來自 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

相關文章