想象一下，您發布了一項新功能并且什麼都不擔心 - 您可以在幾秒鐘内打開和關閉它，逐步推出新元素，進行 A/B 測試，配置條件訪問等等。這個神奇的解決方案就是功能标志。聽起來你的生活會變得更輕松嗎？是的，但請記住，權力越大，責任越大。今天是你的幸運日，你将學習如何從特性标志最佳實踐中受益，以及如何在你的軟件開發項目中實現特性标志。

功能标志（或功能切換）是一種允許在不部署新版本應用程序的情況下啟用或禁用功能（代碼片段）的機制。您可以控制應用程序中單個功能甚至整個頁面的可見性。

從開發人員的角度來看，功能标志是代碼中的附加

有很多服務可以幫助您管理功能标志，但是在查看可用選項之後，我強烈推薦LaunchDarkly。您可以在 Web 和移動開發中使用 LaunchDarkly。此工具允許您為标志、百分比推出等設置不同的值。我使用 LaunchDarkly 已經一年多了，我對此非常滿意。

應用程序的功能标記最佳實踐

您決定在系統中需要一個标志并希望正确實現它。這是您需要關注的内容。

花時間在良好的命名約定上

使用功能标志時，花時間進行良好的命名至關重要。人們說命名變量是編程中最難的事情之一。使用普通變量，您始終可以檢查文件和其他變量的上下文。但是使用功能标志命名是您唯一需要處理的事情。根據名稱，您必須知道此标志的用途。例如：

if(featureFlag.enableDelete){}

//vs if(featureFlag.enableUserAccountDeletion){}

您在名稱中提供的詳細信息越多越好。

不要在标志名稱中使用禁用/隐藏

我不建議在 if 條件下使用否定形式。它很難閱讀，需要更多的努力才能使用。就像這個例子：

if(!featureFlag.featureFooIsDisabled){ //do something when enabled}

//vs if(featureFlag.featureBarIsEnabled){ //do something when enabled}

view rawflag.js hosted with ❤ by GitHub

使用一個标志仍然很容易解碼含義。但是，如果條件中有多個标志怎麼辦？

if(!featureFlag.featureFooIsDisabled || featureflags.featureBarIsEnabled) {}view rawflag.js hosted with ❤ by GitHub

當你想設置一個合适的标志值時，這也是非常令人沮喪的。想象一下：“當我給出真實值時，它會被禁用，所以要在生産中啟用它，我必須給出錯誤值”。啟用标志的錯誤值是不直觀的。

為标志創建團隊命名約定

這是上一段的延伸。讓整個團隊參與進來，并為您的旗幟寫下約定和标準。以下是您應該考慮的事項：

• 将團隊名稱添加到标志（更容易找到負責标志的人員），
• 為标志名稱添加前綴（例如 temp、rollout、experiment、配置文件等）将簡化标志管理并删除舊标志，
• camelCase 或snake_case，
• 您已經在項目中使用的其他命名約定。

描述标志角色

一個好的名稱是标志可用的最低要求。但我強烈建議為标志添加一些描述。這是為您和其他隊友提供的有關創建此标志的原因的信息。創建此标志時看起來沒有必要，但相信我 - 數周/數月/數年之後，您将不記得為什麼創建此标志。描述可以直接在您用于标志的軟件中添加，但您也可以創建一個附加文檔。

創建用于跟蹤目的的文檔

添加新标志很容易，但很難跟蹤所有标志。根據我的經驗，開發人員在完成任務後就會忘記标志。有時，當出現錯誤時，他們會被提醒相同的功能标志。相信我，當我說當沒有人記得它為什麼首先被創建時移除它是可以想象的最糟糕的任務。特别是當标志創建者不再在公司工作或響應産品團隊轉變為另一個時。

您應該跟蹤哪些信息：

• 标志名稱，
• 負責的團隊，
• 引入功能切換的票證（或引入标志的上下文），
• 預期壽命終止日期，
• 任何其他注釋。

進行審計

不幸的是，創建一個文檔是不夠的。定期進行文件審核是一種很好的做法。我建議每年或每六個月至少檢查一次。在此審核期間，您應該檢查是否：

• 每個标志都描述得很好，
• 每個标志都在本文檔中，
• 你仍然需要你的臨時标志（臨時，推出，實驗），
• 不必要的标志被删除。

在您的應用中實施功能标志的好處

功能标志有幾個非常令人鼓舞的優勢。

在我看來，最大的好處是功能标志将代碼與用戶的可見性分開。

将新功能/改進合并到代碼中并不意味着每個用戶都會在應用程序中看到這個。通過這種方式，您可以完全控制功能生命周期（包括功能可見性）并減少生産中的關鍵錯誤數量。

讓我們更詳細地了解更多标記利潤的功能。

立即發布，稍後激活

您不需要額外的分支來獲得新功能，并且可以将代碼中的更改（新功能/改進）直接合并到主分支。這消除了開發人員方面的許多問題：

• 您不必将功能分支與主分支同步，
• 新功能始終與其他更改同步，
• 沒有代碼沖突，
• 更容易對整個應用程序進行更改（例如庫更新），
• 所有更改都很小，代碼審查很快。

從商業角度來看，這也有一個不錯的好處。開發人員可以在他們認為準備就緒時合并最近添加的功能。然後經理決定功能發布過程是現在進行還是需要等待更長的時間才能獲得更好的機會。為了說明這個例子：開發人員為一家在線商店完成了一項新功能，但距黑色星期五還有一周——這是一個用戶流量巨大的日子。在黑色星期五之前或之後引入此功能更好嗎？它會混淆用戶還是讓他們更容易購物？

安全按鈕

功能标志用作安全開關——如果新功能有任何問題，您可以一鍵禁用它。

您可能體驗過測試新功能。這是一個複雜的過程，需要測試人員的大量經驗。盡管如此，無論您做什麼，有時您都會忽略導緻生産環境出現問題的錯誤。在正常的工作流程中，在生産中發現錯誤意味着調試。然後，您将花一些時間修複和部署新版本。如果這是面向用戶的功能的嚴重錯誤，人們将在幾個小時内無法使用您的應用程序，從而給業務造成損失。

如果您改用功能标志，您可以首先禁用給定功能，讓團隊有時間解決這個問題，并在必要時修改系統行為。功能标志管理非常簡單，功能切換需要幾分鐘而不是幾小時。

您應用程序中的每個新元素都應經過徹底的功能測試。查看我們的 QA 團隊如何處理它：

• 向您的應用程序添加新功能？通過功能測試将風險降至最低

有條件的訪問

非常适合擁有全球用戶群的國際應用程序。由于各種情況（例如法律問題），一個國家/地區的用戶看到的選項/功能與其他國家/地區不同。借助功能标志系統，您将控制應用程序特定部分的可見性，以适應特定條件，如國家、語言、貨币、偏好等。

遠程 配置

這與條件訪問稍有相似，但目的不同。功能标志可以超過一個布爾值。它也可以是其他類型，例如用于為功能創建遠程配置的字符串和數字。現在，您可以即時更改配置并将用戶重定向到不同的功能。

金絲雀部署

Canary 部署是向用戶部署新版本應用程序的安全方式之一。您向少數用戶推出新版本并監控一切是否正常。逐漸增加用戶數量，直到整個用戶群遷移到新版本。使用功能标志，您可以使用單個功能執行此操作。您可以配置有多少用戶會看到某個功能。将此用作擴展的質量保證測試，以在向所有用戶發布之前檢查最近的功能。

A/B 測試

相同的機制可用于 A/B 測試——相同功能/頁面/消息的兩個版本，以查看哪個更适合用戶。您可以使用功能标志百分比推出将一些用戶移至版本 A，将其餘用戶移至版本 B。請記住記錄用戶看到的版本以及他們在那裡所做的事情。有必要在實驗後創建一個摘要。在結束日期之後，您應該删除所有實驗切換。在為 A/B 測試創建功能标志之後，我建議添加一個額外的票以删除這些标志并将它們移動到未來的 sprint 之一。

2022 年前端狀态報告現已發布！
在線閱讀或下載免費副本‍

該報告的結果基于代表125 個國家/地區的各個熟練程度的前端專家填寫的3703 份調查！19 位前端專家對每個主題部分進行了評論。對于任何有前端背景的人來說，這都是一種真正的享受。看看哪些技術仍然很熱門，哪些技術失去了影響，以及我們在可預見的未來期待哪些後起之秀。

索取我的副本特征标志的缺點

所有閃光的不都是金子！功能标志不是解決所有問題的ducktape 或WD40。功能切換有其自己的一組問題，您必須考慮這些問題以避免功能标志地獄。

上瘾

從業務角度來看，功能标志非常容易上瘾。現在管理人員不必等待開發人員打開和關閉功能，他們可以自己做。我已經偶然發現了喜歡使用功能标志來控制對基本上所有内容的訪問的經理。如果他們缺乏技術知識，更多的控制并不一定意味着一件好事。因此，開發人員的角色是僅在需要時使用功能标志。否則，您将引入大量技術債務。

引入技術債務

您還記得必須使用 if 語句在代碼中實現功能标志嗎？If 語句總是引入債務，因為您需要控制它并提供默認行為。

另一個問題是過去實施但不再需要的舊的、未使用的标志。如果您不需要這些功能标志，隻需删除它們。小心不要創建使用相同标志的更複雜的 ifs 語句，因為之後删除它們會更難。

意外的依賴

當你有一個标志時，很容易控制代碼。但一段時間後，它将是兩個特征标志，并累積到數十或數百個不同的标志。您必須知道它們之間的連接才能正确測試它們。

想象一下，您必須為正确的值啟用五個标志才能訪問某個功能。增加标志的數量将導緻應用程序中的用戶路徑更多。您必須注意所有這些，否則您将為用戶創造一個死胡同。

難以調試

意外的依賴關系使調試變得更加複雜，因為您必須知道所有标志狀态才能重現錯誤。标志的微小變化會導緻不同的結果。您不僅必須實施良好的應用程序監控來檢測用戶在哪裡遇到問題，而且還必須跟蹤特定用戶啟用了哪些獨特的标志集來重複錯誤并相應地修複它。

我無法想象我的工作沒有功能切換了

我已經使用功能标志一年多了，我無法想象沒有它們就可以創建高級項目。我數不清有多少次功能标志以令人難以置信的測試速度将我們從嚴重的生産錯誤中拯救出來。

如果您遵循我的提示，向用戶添加新功能将更容易且壓力更小，因此我強烈建議您在下一個生産版本之前檢查功能标志。

最後的想法：

• 當您想要控制是否向最終用戶顯示新功能時，功能标志是完美的，
• 不要為每個功能自動添加功能标志 - 僅在需要時添加，
• 在良好的命名約定上投入時間并堅持下去，
• 切勿使用負值來啟用标志，
• 跟蹤您的功能标志，
• 不時檢查您是否仍然需要臨時标志，或者您可以删除它們，
• 當産品經理想要一個不必要的功能标志時，學會說“不”，
• 請記住在使用此功能時記錄有關标志的信息。

,

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!

查看全部