本篇內容參考自 Overreacted 網站的 "The WET Codebase"

在做開發時，你是不是也有這樣的習慣：
看到兩段長得「有點像」的程式，就立刻抽成共用？

Dan Abramov 在他的文章《The WET Codebase》中提醒我們：

為了 DRY（Don't Repeat Yourself）而抽象，常常會讓程式更難維護。

核心概念：從 DRY 到 WET

• DRY 原則：Don't Repeat Yourself
  → 理念很好，強調可重用、避免重複邏輯。

• WET 概念：Write Everything Twice
  → 並不是鼓勵你亂重複，而是提醒：
  「別為了抽象而抽象」，有時候重複反而讓程式更清晰。

Dan 認為，共用邏輯應該是「觀察出來」的結果，而不是「預測出來」的需求。

錯誤示範：過度抽象的 component

function Text({ type, children }) {
  const style =
    type === "title"
      ? { fontSize: 24, fontWeight: "bold" }
      : type === "subtitle"
      ? { fontSize: 18, color: "gray" }
      : {};
  return <p style={style}>{children}</p>;
}

看起來很 DRY，但實際上：

• type 參數越來越多，邏輯越來越亂。
• 新增一個樣式要修改整個共用邏輯。
• 最後沒人敢動這段 code。

改進版：看起來重複，但更清楚

function Title({ children }) {
  return <p style={{ fontSize: 24, fontWeight: "bold" }}>{children}</p>;
}

function Subtitle({ children }) {
  return <p style={{ fontSize: 18, color: "gray" }}>{children}</p>;
}

雖然重複了樣式，但：

• 一看就懂。
• 不同角色的元件可以自由演化。
• 可維護性反而更高。

常見誤區

• 為了 DRY，過早抽象出複雜的共用 component。
• 以為「重複就是壞事」，但有時候兩段相似邏輯會在未來走不同方向。
• 沒等模式穩定就抽象，結果綁死了程式設計。

實務應用

這篇文章提醒我們：

• 抽象是演化出來的，不是預測出來的。
• 「共用」應該發生在觀察到穩定模式之後，而不是第一次看到重複時。
• React component 的最大價值在於「可讀性」與「維護性」，而不是行數少。

面試回答

Sometimes, duplication is better than the wrong abstraction.
I prefer to repeat code a few times and see if the pattern is truly stable before creating a shared component.
This keeps the code simple and easier to maintain.

中文

有時候重複比錯誤的抽象更好。
我會先讓重複自然發生，等到模式穩定後再抽共用，讓程式保持簡單、易懂、可維護。

🧾 總結重點