Kirk Pepperdine

DRY 原則與效能的關係#

**DRY 原則（Don’t Repeat Yourself）**要求系統中每一項知識都應有唯一的表述，知識應包含在單一實作中。DRY 的反面是 WET（Write Every Time）——當知識被編碼在多個不同的實作中時，程式碼就是 WET 的。

當你從效能剖析（performance profile）的角度來看，DRY 與 WET 的差異就變得非常明顯。

WET 如何稀釋效能瓶頸#

假設系統中某功能 X 是 CPU 瓶頸，消耗了 30% 的 CPU：

• WET 的情況：功能 X 有 10 個不同的實作，每個平均消耗 3% CPU。這個水平不值得擔心，我們很可能會錯過這個瓶頸
• DRY 的情況：只有一個實作，清楚地顯示 30% 的 CPU 使用率，而且只需修復十分之一的程式碼

WET 程式碼不僅限制了重構能力，還迫使 API 的使用者各自重新實作相同的查詢邏輯，讓效能問題更加分散、更難被發現和修復。

用封裝解決問題#

一個常見的 WET 違規是直接暴露原始集合（raw collection）給客戶端。更好的做法是引入領域特定的集合型別（domain-specific collective type）：

• 將查詢邏輯封裝在這個新型別中
• 消除暴露 ArrayList 等實作細節的需要
• 讓我們可以自由地更改底層實作而不影響客戶端

例如，將 ArrayList<Customer> 替換為自訂的 CustomerList 類別，將查詢方法納入其中。這不僅語義上更貼合領域，還讓我們能輕鬆地引入替代索引方案（如 SortedList），從而找到並修復效能瓶頸。

遵循 DRY 原則不僅關乎程式碼品質，更直接幫助我們發現和修復效能瓶頸——而 WET 程式碼會讓這些瓶頸變得更加隱蔽和難以處理。