顶部通知应用图标大小（功能标志最佳实践）

癲嘙姥 2023-01-19 02:12:12

想象一下，您发布了一项新功能并且什么都不担心 - 您可以在几秒钟内打开和关闭它，逐步推出新元素，进行 A/B 测试，配置条件访问等等。这个神奇的解决方案就是功能标志。听起来你的生活会变得更轻松吗？是的，但请记住，权力越大，责任越大。今天是你的幸运日，你将学习如何从特性标志最佳实践中受益，以及如何在你的软件开发项目中实现特性标志。

什么是功能标志（Feature flags），为什么需要它们？

功能标志（或功能切换）是一种允许在不部署新版本应用程序的情况下启用或禁用功能（代码片段）的机制。您可以控制应用程序中单个功能甚至整个页面的可见性。

从开发人员的角度来看，功能标志是代码中的附加

有很多服务可以帮助您管理功能标志，但是在查看可用选项之后，我强烈推荐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 语句，因为之后删除它们会更难。

意外的依赖
当你有一个标志时，很容易控制代码。但一段时间后，它将是两个特征标志，并累积到数十或数百个不同的标志。您必须知道它们之间的连接才能正确测试它们。

想象一下，您必须为正确的值启用五个标志才能访问某个功能。增加标志的数量将导致应用程序中的用户路径更多。您必须注意所有这些，否则您将为用户创造一个死胡同。
难以调试
意外的依赖关系使调试变得更加复杂，因为您必须知道所有标志状态才能重现错误。标志的微小变化会导致不同的结果。您不仅必须实施良好的应用程序监控来检测用户在哪里遇到问题，而且还必须跟踪特定用户启用了哪些独特的标志集来重复错误并相应地修复它。

我无法想象我的工作没有功能切换了

我已经使用功能标志一年多了，我无法想象没有它们就可以创建高级项目。我数不清有多少次功能标志以令人难以置信的测试速度将我们从严重的生产错误中拯救出来。

如果您遵循我的提示，向用户添加新功能将更容易且压力更小，因此我强烈建议您在下一个生产版本之前检查功能标志。
最后的想法：
当您想要控制是否向最终用户显示新功能时，功能标志是完美的，
不要为每个功能自动添加功能标志 - 仅在需要时添加，
在良好的命名约定上投入时间并坚持下去，
切勿使用负值来启用标志，
跟踪您的功能标志，
不时检查您是否仍然需要临时标志，或者您可以删除它们，
当产品经理想要一个不必要的功能标志时，学会说“不”，
请记住在使用此功能时记录有关标志的信息。
,