Feature Toggle 應用常見問題
Feature toggle（aka feature flags）是一個成熟軟體很常見的開發方法。我在去年（2019）講過三場與此主題相關的分享，今天剛好社群朋友有討論，這裡做個記錄分享給大家。
先曬一下個人的簡報，剛好橫跨北中南XD：
- 先別開 Branch 了，你聽過 Feature Toggle 嗎？ - Agile Tour Kaohsiung 2019
- 應用 Feature Toggle ，交付更加 Flexible - DevOpsDays Taipei 2019
- 先別開 Branch 了，你聽過 Feature Toggle 嗎？ - Agile Taichung
下面是跟社群朋友的對話記錄，有小調整加補充。
Q1：開關太多會造成維護上的困難，該如何解決？
粒度太大，feature toggle 能控制的細節有限；粒度太小則會讓維護變成負擔。粒度到底要多大，要視團隊的適應程度來決定，可以參考這篇文章的 Choose the Right Level of Flagging，文裡有提到：
If they’re cluttering up your application in a way you can’t control, take a step back and reexamine.
我會建議先用一個開關試玩一陣子，等到這個開關上線並移除後，自然就會知道這樣的粒度大小對團隊的影響為何，再來就會知道該如何控制了。
事實上，更好的方法是：讓開關設定變得更容易調整，並且更常去調整它，這樣大家就會清楚開關的用途了。對業務需求而言，恆開或恆關的開關，其實一點意義都沒有－－if else 沒打算走另一條分支，倒不如砍了吧！
Q2：假設 feature A 已經推上去，feature B 剛好用到 feature A 的共用服務，這該如何避免？
我個人覺得這是需求上的衝突，為什麼 feature B 上線會用到 feature A 的功能？
若是共用方法，那應該會是共用方法先上線，再開始做 feature A，然後再做 feature B。若 feature A 是大需求，而 feature B 是裡面部分功能的話，那程式的結構上應該會是 feature A 使用 feature B。
確實可以 feature A 先上，再換 feature B，並沒有問題。但程式的結構應該會隨著開發過程交換過來，讓 feature B 變成被使用的模組，而 feature A 去使用 feature B。
Q3：承上，順序沒錯，但 feature A 關閉，但 feature B 要開啟，這樣會有問題嗎？
就需求面來看，確實是一件影響很大的事。可以試著想像看看：先規劃並開始執行一個偉大計劃，然後做到一半說要玩 MVP，我已經可以聽到一片髒話聲了。
在架構上確實影響巨大，但先假設這是有價值的事必須要做，那如何做才能降低風險？是的，只有自動化測試能幫助你。
Q4：如何對 feature 的名字命名規範？
講我們的例子，之前導入 OpenID Connect 登入機制，當時是用開關控制的，叫 openid_connect；然後第三方登入功能有個按鈕，這個也是開關控制的，叫 sign_in_with_apple，現在這些開關都功成身退了。
該如何命名，詳細可以參考 Flag Naming 一文。
Q5：如剛剛提到粒度，是建議大一點，然後只有一個開關，開關之間不要有相依性嗎？
開關與業務邏輯有正相關，而業務邏輯之間不大可能會沒有相依性。
所以這個問題是 by 業務需求決定。
同理，粒度大小也是 by 業務需求決定。
Q6：如果用 feature branch name 來做為 feature flag name 適合嗎？
feature branch 跟 feature name 可以做到一樣的目的，所以命名一樣是沒問題的。實務上其實會像 Q2 所說的，feature A 做一半上，然後下一次可能就會換一個 branch name 做 feature A 了。
因此，其實這兩個命名是不是一樣，其實不是那麼重要。
如果把 flag 當 branch 用的話，那確實命名都會想要取一樣。不過 flag 有不同的使用情境，這些狀況下就會有不同的命名方法，可以參考看看 uses case。
Q7：Git Flow 改走 Trunk based Flow，是否就要導入 feature toggle
可以試看看先不導，當遇到 feature A 先做，feature B 後做，但 feature B 要先上的時候再來考慮。可以再觀察看看，至少 Q2 的例子是適用的。
要注意 trunk based flow 要成功的關鍵在於每個 commit 都要是可以隨時部署的，所以不能 feature A 做到一半，然後 feature B 在後面 commit 說要先上。用 feature toggle 才有辦法簡單地把 feature A 隱藏起來，並只留下 feature B。
Q8：走 Trunk based Flow，已上去的 feature 最後決定不使用，會保持關閉還是 revert？
看 revert 會不會搞到其他 commit，如果會的話，就保持關閉慢慢移除。
這也是 feature toggle 相對的問題，可以快速上程式，相對地很難拔掉這些程式。