Feature flag 的生命週期：什麼時候拿掉、既有 code 怎麼包？
Feature gate 最簡單就是一個 boolean flag 把 gating 當成整套方法的樞紐，但只講了怎麼加，沒講怎麼收。我對這套做法的實用性與整潔性的懷疑，就卡在這幾個洞上。
懸而未決的
- flag 最後要拿掉嗎？ 什麼時機？誰負責？不拿掉的話，codebase 會不會變成一堆死掉的分支？
- 如果只是修改現有 code 加新功能呢？ 那不是新寫一塊 leaf，而是在既有邏輯裡插入分支——gate 要包在哪一層？
- gating 的判斷要 commit 嗎？ （這題材料有答：flag 就是寫在 codebase 裡的 gating code，所以會進版控。真正的問題是後續怎麼清。）
材料給到哪裡
- flag 的清理：完全沒談。 整支影片沒有一句談 flag 下架或累積造成的雜亂
- 既有 code：只有側面回答。 他舉 reducer 的例子說，改既有行為時如果那個行為沒有被 gate 起來，他就會花更多時間 review——可見既有行為的改動是可以 gate 的，但他沒說怎麼包
- （推論）清理 flag 聽起來正該放在他說的**最後 20%「refactor 與清理 codebase」**那一段，但他沒有把這兩件事接起來
想得到答案要往哪找
- feature toggle 的既有實務（LaunchDarkly 這類服務怎麼處理 stale flag、有沒有自動偵測）
- Martin Fowler 的 Feature Toggles 一文對 toggle 分類（release／ops／experiment／permission）與各自壽命的說法
- 團隊層面：flag 要不要有到期日、owner、清理的排程