你的代碼有重複嗎？

“避免重複代碼”(dry) 是軟體發展的一項原則，其主旨是減少代碼重複現象。

“所有内容寫兩遍”(wet) 則是上述原則的反義縮寫，意指不遵守 dry 原則的代碼。

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

在本文中，我們會逐一讨論編寫代碼時遵循 dry 原則的好處。首先，我們先舉一個簡單的例子來說明 dry 原則的基本優勢。

假設你的代碼中有很多地方需要根據目前使用者的角色來執行。比如：隻有編輯或管理者才可以執行 <code>createpage()</code> 函數，隻有管理者才可執行 <code>deletepage()</code> 函數。

在creatpage（建立頁面）和 deletepage（删除頁面）函數檢查使用者的角色時，我們可以使用下面這個 ispermitted() 單一函數，而不是分别開展使用者角色檢查的邏輯。

将 ispermitted() 的邏輯固定在一個地方，就可以避免重複，同時反複利用代碼。另外一個優勢就是邏輯的獨立性，即 createpage() 和 deletepage() 無需知道如何檢查權限。

當然，diy 原則的優勢遠不止這樣。

dry 原則的最大優勢是可維護性。如果檢查權限的邏輯在整段代碼中重複很多次，在重複代碼中出現的問題将很難修複。修複一段代碼中的某個問題後，很容易忘記修複其他重複代碼中同樣存在的問題。同樣，如果需要修改邏輯，就得四處複制粘貼。如果使用不重複的代碼，隻需在一處維護代碼即可。新的邏輯和漏洞修複都隻需在一處進行，不必再四處徘徊。通過這種方式開發的軟體既穩定又可靠。

大多數情況下，遵循 dry 原則的代碼更容易閱讀。這并不是因為 dry 原則本身，而是因為開發人員在代碼中投入了更多精力，讓它符合一定的原則（比如 dry 原則）。

dry 原則始終提倡二次利用代碼，這是因為我們會将2個或2個以上重複代碼執行個體并入一個代碼塊。可重用代碼縮短了開發時間，是以從長遠看，可重用代碼是有回報的。

如果想說服管理層用更多的時間來提高代碼品質，就可以用“成本”這個理由。代碼越長，成本越高。代碼越長，維護代碼、修複漏洞所需的人手和時間也越多。代碼越長，開發時間和漏洞也越多，結果就是客戶非常不滿。無庸贅述。

這裡我們讨論的是子產品測試和內建測試，而不是手動測試。測試時需要覆寫的路徑和功能越多，為測試而編寫的代碼就會越長。如果代碼不重複，就隻需要測試一個主路徑。當然，不同的行為仍然需要接受測試。

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

不是所有代碼都需要整合成一段。有時候2段代碼看上去差不多，但卻存在細微差異。什麼時候應當将代碼段整合成一段，什麼時候又應當讓它們保持分離狀态，都需要仔細斟酌。

如果代碼太過簡略，會讓人難以了解。我曾見過開發人員在隻有一個代碼塊執行個體時，還要貫徹 dry

原則。雖然我欣賞他們希望讓代碼更出色、可重用率更高的想法和遠見，但是我隻有在需要二次利用代碼時才會去遵循 dry 原則。

人們經常會忽略的是，dry 原則并不僅僅适用于代碼，它還可以同等地應用到資料庫設計、文檔編寫、代碼測試等方面。