Feature Flags 正在毀了你的 Codebase

Feature Flags 是上線新功能時很常使用的 1 項技巧,它的作用是可以讓我們迅速地開關特定功能,例如下列 Python 程式碼範例,可以透過設定檔切換新舊的付款服務:

USE_NEW_PAYMENT_SERVICE = config.get('NEW_PAYMENT_SERVICE') is True
if USE_NEW_PAYMENT_SERVICE:
    ...(the new logic)
else:
    ...(the old logic)

Feature Flags 雖然方便,不過卻也帶來不少問題,這些問題你我都應該知道或親身體驗過,只是我們多數不像 “Feature flags are ruining your codebase” 1 文的作者那樣將 Feature Flags 的利與弊整理得如此清楚,推薦可以花點時間將該篇文章閱讀一遍,不僅會有很多既視感浮現,還能知道未來怎麼做的更好。

我自己總結如下:

  • Feature Flags 很好用沒錯,但要視為最後手段。如果一項功能該上線/下架就勇敢上線/下線,不要做 Feature Flags 讓 PMs 有隨時開關的機會,因為 PMs 很可能會一次食髓知味,之後把各種實驗性的想法都推到 production 環境,甚至讓功能的發想、研究、驗證等過程變得草率,這一切就是因為對 PMs 來說功能的上線/下線變成成本很低廉的事,進而忽略其他人需要付出的成本,這些成本包括,開發者需要將 Feature Flags 的邏輯放入程式碼之中,簡單的話,可能就 x 2 的程式邏輯,不簡單的話就可能是 x N 的程式邏輯,更可怕的是 Feature Flags 之間產生交互作用的情況,例如 A, B Flags 各有 2 種情況,那麼它就會產生 4 (2x2) 種程式邏輯,這些額外產生的邏輯對測試人員也是 1 種成本,因為要測試的案例變多了。
  • Feature Flags 會對 Codebase 的後續維護造成困擾。個人的經驗告訴我,這些 Feature Flags 上線之後,也很少人會去關心它打開/關掉的後續問題,所以程式碼就會一直存在這些 Flags, 隨著存在時間變長,它存在的原因也就逐漸被淡忘,一旦遇到需要維護、升級的情況,就會有倒霉鬼需要扮演程式碼考古學家,需要找到當初開發的文件、 PM 、開發者釐清原因,進而決定後續處理步驟,但多數情況不會如此順利,甚至可能沒人想大冒險,因而決定繼續留下 Feature Flags, 直到下一個倒霉鬼又出現。

至於可能的解決辦法則是:

  1. 為系統可同時容納的 Feature Flags 設定上限,如果 Feature Flags 超過一定數量,就讓測試直接失敗,強迫有人重視這個問題(但是需要團隊有此共識)。
  2. 為每個 Feature flags 設定合理的失效時間,如果 Feature Flags 達到失效時間也讓測試直接失敗,強迫團隊移除不必要的 Feature Flags 。
  3. 每個創造 Feature Flag 的開發者或 PM, 應該都要為該 Feature Flag 負責,後續都應該要有 ticket 進行追蹤,才能讓大家意識到 Feature Flag 有其成本,並謹慎使用 Feature Flags 。

總之,每次要用 Feature Flag 時,都應該要捫心自問「必要嗎?」

Feature flags are ruining your codebase

Facebook Threads X

對抗久坐職業傷害

研究指出每天增加 2 小時坐著的時間,會增加大腸癌、心臟疾病、肺癌的風險,也造成肩頸、腰背疼痛等常見問題。

然而對抗這些問題,卻只需要工作時定期休息跟伸展身體即可!

你想輕鬆改變現狀嗎?試試看我們的 PomodoRoll 番茄鐘吧! PomodoRoll 番茄鐘會根據你所設定的專注時間,定期建議你 1 項辦公族適用的伸展運動,幫助你打敗久坐所帶來的傷害!

贊助我們的創作

看完這篇文章了嗎? 休息一下,喝杯咖啡吧!

如果你覺得 MyApollo 有讓你獲得實用的資訊,希望能看到更多的技術分享,邀請你贊助我們一杯咖啡,讓我們有更多的動力與精力繼續提供高品質的文章,感謝你的支持!