第二個使用情境出現前，別急著加抽象層

前言

三個拆掉過早抽象的真實案例，加上一條簡單規則：重複的程式碼要撐到什麼程度，才值得搬進共用模組。

為什麼這個問題反覆出現

每場 Pattern 的討論最後都會卡在同一個張力上：對團隊當下舒服的選擇，和專案一年後真正需要的東西。光靠辯論，哪一邊都贏不了。

一種思考方式

• 預設值比意圖活得久——請刻意設計它。
• 決策本身便宜，溝通很貴——為後者編預算。
• 分歧是資料。把「什麼證據會改變你的想法」寫下來。

我會怎麼做

從「小到覺得不太有用」的規模開始，把理由寫在 commit 或 RFC 裡，然後用行事曆上的日期重訪它，而不是憑感覺。

結語

Pattern 的品味，其實大多是記憶。請刻意收集你自己的。