Steve Smith

DRY 原則的核心#

在所有程式設計原則中，**Don’t Repeat Yourself（DRY）**可能是最基本的。這個原則由 Andy Hunt 和 Dave Thomas 在《The Pragmatic Programmer》中提出，也是許多知名軟體開發最佳實踐和設計模式的基礎。

能辨識重複並透過適當的**抽象化（abstraction）**消除它的開發者，能寫出比持續用不必要重複感染程式碼的開發者更乾淨的程式碼。

重複即浪費（Duplication Is Waste）#

每一行程式碼都需要維護，而每一行都是潛在 bug 的來源。重複會帶來以下問題：

• 膨脹程式碼庫，增加 bug 和意外複雜度的機會
• 讓開發者更難全面理解系統
• 無法確定在某處修改後，其他複製邏輯的地方是否也需要同步修改

DRY 要求：每一份知識在系統中都必須有一個單一、明確、權威的表述。

邏輯重複需要抽象化（Repetition in Logic Calls for Abstraction）#

邏輯中的重複有多種形式，其中複製貼上的 if-then 或 switch-case 邏輯是最容易發現和修正的。許多**設計模式（design patterns）**的明確目標就是消除應用程式中的邏輯重複：

• 物件建立前需要多個步驟？使用 Abstract Factory 或 Factory Method
• 物件有多種行為變化？使用 Strategy Pattern 取代大量的 if-then 結構
• DRY 也可以應用到資料庫結構，產生正規化（normalization）

流程重複需要自動化（Repetition in Process Calls for Automation）#

軟體開發中的許多流程是重複且容易自動化的。DRY 原則同樣適用於這些情境：

• 手動測試緩慢、容易出錯且難以重複——應盡可能使用自動化測試套件
• 軟體整合手動執行耗時且容易出錯——建置流程應盡可能頻繁地執行
• 凡是存在痛苦的手動流程，都應該被自動化和標準化

原則的延伸#

其他軟體原則也與 DRY 相關：

• Once and Only Once 原則：僅涉及程式碼的功能行為，可視為 DRY 的子集
• Open/Closed Principle（開放封閉原則）：軟體實體應對擴展開放、對修改封閉，只有在遵循 DRY 時才能實際運作
• Single Responsibility Principle（單一職責原則）：類別只應有一個改變的理由，也依賴 DRY

雖然在某些情況下重複可能是必要的（例如為了效能而進行資料庫反正規化），但重複只應用於解決實際問題，而非想像中的問題。