平常在撰寫程式碼，常常看到有類似的需求，這時候我們該怎麼做？不斷的複製和貼上，我開玩笑的，當然不是，這樣的作法會讓程式碼變得難以維護，因此有一個原則叫做DRY 原則（Don't Repeat Yourself）。

根據維基百科描述如下

"Don't repeat yourself" (DRY) is a principle of software development aimed at reducing repetition of information which is likely to change, replacing it with abstractions that are less likely to change, or using data normalization which avoids redundancy in the first place.

我們根據維基百科做提到的內容做出以下重點

避免重複可以透過下列兩種方式

1. 使用抽象化來避免重複
2. 使用資料正規化來避免重複

根據 Andy Hunt 與 Dave Thomas 在《The Pragmatic Programmer》一書中的說法，DRY 原則的核心概念是：每一項知識都必須在系統中具有單一、明確、權威的表示方式。換句話說，當我們需要修改邏輯時，理想情況下只需要在一個地方進行修改，而不是在多個地方反覆修改相同的程式碼。

接下來將會帶大家透過 TypeScript 的範例來看看為什麼遵循 DRY 原則如此重要，以及如何在實際開發中應用這個原則。

不好的範例：重複的驗證邏輯

讓我們看一個簡單的範例，兩個函式都需要檢查 email 格式：

// 不好的範例：重複的驗證邏輯
function loginUser(email: string) {
  // 驗證 email
  if (!email || !email.includes('@')) {
    throw new Error('Invalid email');
  }
  console.log(`User ${email} logged in`);
}

function registerUser(email: string, name: string) {
  // 又是相同的驗證邏輯！
  if (!email || !email.includes('@')) {
    throw new Error('Invalid email');
  }
  console.log(`User ${email} registered with name ${name}`);
}

這時候我們可以發現的問題：

1. 相同的驗證邏輯重複出現在兩個函式中
2. 維護困難：如果要改驗證規則，需要改兩個地方
3. 容易出錯：可能會忘記更新某個函式的驗證邏輯

修正後的範例：抽取共用驗證邏輯

透過 DRY 原則來改善這段程式碼：

// 修正範例：將驗證邏輯抽取為獨立函式
function validateEmail(email: string): void {
  if (!email || !email.includes('@')) {
    throw new Error('Invalid email');
  }
}

// 現在各個函式變得簡潔且專注於自己的核心邏輯
function loginUser(email: string) {
  validateEmail(email); // 重複使用驗證邏輯
  console.log(`User ${email} logged in`);
}

function registerUser(email: string, name: string) {
  validateEmail(email); // 重複使用驗證邏輯
  console.log(`User ${email} registered with name ${name}`);
}

透過這樣的重構，我們獲得了以下好處：

1. 修改單一元素時，不需更動其他邏輯上無關的元素。
2. 邏輯相關的元素會可預測且一致地變更，保持同步。

適用範圍

除了程式碼本身以外，DRY 原則也適用於以下領域：

• 資料庫結構（database schemas）
• 測試計畫（test plans）
• 建置系統（build system）
• 文件（documentation）

總結

DRY 原則不只是避免複製貼上程式碼這麼簡單，它更是一種思維方式。

需要注意的是，過度抽象也可能造成問題。我們應該在適當的時機應用 DRY 原則，明天將講述過度抽象的問題。大家明天見～

參考資料

• DRY - 維基百科
• The Pragmatic Programmer highlighted points: Ch 2, A Pragmatic Approach
• The Pragmatic Programmer - Andy Hunt & Dave Thomas