學習要點

不要過度預測未來需求，避免早期過度設計，先找到足夠的使用案例，再來考慮。

故事描述

某天，我們開始了一個新的專案，分為兩個階段，各三個月。十倍工程師選擇了 Next.JS，由他初步建立了基本雛形後，其他成員也陸續加入。

由於後端邏輯還未完全定案，大家便從套用靜態頁面開始。團隊成員都很資深，所以在簡單切割任務後，大家就各自採取行動，沒花太多時間，就完成了大部分的工作。接著進入到整合真實資料的階段，開始需要考慮狀態管理了。

於是，我們開會討論是否應該使用 Redux。你可能會感到驚訝，這還需要討論？React 和 Redux 幾乎成了標準組合，但我們團隊真的花了一場會議來討論這個問題。

（友善提醒：故事背景不是現在，現在可能有其他常見的組合。）

大多數人覺得 Redux 可用可不用，但兩位十倍工程師一致認為，當前現況不需要 Redux，僅使用 React 的 custom hooks 就足以應付場景需求。

因此，我們最終決定只使用 custom hooks 來寫。多數功能進展順利，只有兩個地方顯得麻煩，會讓人有一種「如果用 Redux 會更輕鬆」的衝動，但我們仍然堅持不使用。

當第二階段進入尾聲，幾乎所有功能都已經開發完畢，團隊成員被派去支援其他專案，僅留下其中一位十倍工程師負責收尾。這時，第三個需要狀態管理的地方出現了，他最終決定將 Redux 整合進專案。

我問他：「你最後採用 Redux 的原因是什麼？」

他回答：「因為出現了第三個需要用的地方。」

我接著問：「會不會覺得，如果一開始就用 Redux，後面就不用改了？」

他回道：「不，這是兩回事。當時只有兩個地方勉強需要狀態管理，但並非必須。現在則是有第三個明確的使用案例，這才是適合使用 Redux 的時機。」

最終，他僅花一個早上就把兩個適合使用 Redux 的地方改完了，下午再花兩個小時解決了最後一個需求，專案的開發正式結束。

啟發

這次經驗讓我思考，雖然結果都是使用了 Redux，但方案一和方案二究竟有何差別？

方案一：一開始就用 Redux

每個需要狀態管理的地方都會用 Redux。

方案二：最後才用 Redux

大部分地方使用 custom hooks，只有三個地方使用 Redux。

雖然方案二，看似多了一次工，因為部分程式碼要從 custom hooks 改寫為 Redux，但這額外的修改換來的是：

1. 延遲做出「是否採用 Redux」的決定：前端框架變化快速，難以預測誰會持續主導市場，推遲選擇可以降低風險。

2. 降低未來切換框架的成本：部分使用 Redux 而非全面採用，未來若需切換框架，成本相對更低。

這讓我反思以往的專案：是否每次都遵循「殺雞不用牛刀」的原則？

還是因為擔心後期改不動，而無腦選擇主流框架？

這是否顯示我們的基本功還不夠扎實。無法有十倍工程師那樣的信心，能在後期輕鬆改寫，才做這樣的決定。

這些問題，我就留給各位自己思考了。

理論：YAGNI 原則

YAGNI（You Aren’t Gonna Need It）原則是一種軟體開發中的設計理念，強調不要過早實現不必要的功能。它源於極限編程（Extreme Programming, XP），目的是幫助開發團隊專注於當前真正需要的功能，而非預測未來可能需要的功能。

實踐指南

• 避免過度預測未來需求：不要一開始就選擇複雜的工具，先觀察實際情況是否出現多個獨立的使用案例，再考慮是否採用。

• 考慮技術選擇的靈活性：選擇技術時應避免過度依賴單一框架，保持足夠的靈活性，減少未來切換技術的成本。

• 適時延遲決策：推遲技術選擇，直到實際需求出現，這樣可以降低風險。

• 兩倍法則：如果某個技術或工具能將開發效率提升至少兩倍，那它可能值得提前採用。否則，避免過度設計。