為什麼我們先上線功能開關，再寫功能

前言

主張在寫第一行程式前先建立開關、指標與回滾路徑，並附上一份適合小團隊執行的檢查清單，讓每次發布都能安全回頭。

為什麼這個問題反覆出現

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

一種思考方式

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

我會怎麼做

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

結語

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