# Outline
一、前言
二、概述
三、種類
Ａ、待敘項目

# TL;DR

在雙十連假前，此系列文每天的發文時都會以最簡陳述為主，以求在繁忙的日常中，至少能先維持挑戰鐵人賽的進度，並且逐漸拓展思路與系列結構。預期會在國慶連假將本篇文章論述完整。

一、前言

曾在 Git Workflows 提及 Feature Toggle，今天就回過頭來稍微詳細去講講何謂 Feature Toggle 吧！

二、概述

在 Git Workflows: Recommended Practice 提及讓某功能是否啟用這件事情不應該透過 Git Branch 合併與否去實作，應該讓 Git 專心做好自己是版控工具的角色，而這類事情應該在程式面去解決，也就是所謂的 Feature Toggle。

那什麼又是 Feature Toggle 呢，最簡單的又像是一個條件判斷式加上某個變數去判斷使用者是否能使用這個功能，就像是這樣：

if features.enabled? 'ironman'
  # do something
end

三、分類

Martin Flower 將 Feature Toggle 分為四類：

• Release Toggles
• Experiment Toggles
• Ops Toggles
• Permission Toggles

3-1. Release Toggles

這就是我們前面提及的，在功能尚未完成前，卻須先將程式碼合併回主線時，都必須先加上 Release Toggle。更好的做法是，在實作新功能前，都應該先加上 Release Toggles，直到這個功能已經做好、透過 Toggles 啟用一段時間，確定不會收掉，就可以把 Toggle 相關的程式碼清除。

我常用一個比較貼切的名詞去形容這樣的一個 Toggles，就是所謂的「鷹架」。我們常看到建築物在工程期間都會在外面架上一層鷹架，直到所有工程結束後才撤掉，我認為概念是類似的。尤其是許多工程師會對程式碼多這些條件判斷式感到醜陋而不願意加、或是擔心未來程式碼會充斥著這類程式碼，我就會用這樣的比喻去說服他們，鷹架是一時的，只有在工程期間才會架設，而工程結束後我們也應該主動清除，而不是一直留在程式碼中，通常工程師們就比較可以理解與接受。

附錄Ａ、待敘項目

• 補充說明完所有的 Feature Toggles 類型
• 比較建議的 Feature Toggles 實作方式。
• 如果時間充裕，介紹 GitLab 的 Feature Toggle 功能。
• 延伸說明這個和 Git Workflow 的關係。