如何说服开发人员开始使用功能标志切换？

假定功能标志切换是一个好主意，并且应将其实现为开发人员编写的代码。例如Etsy发誓他们是他们文化的重要组成部分。

如何说服（并强制）开发人员开始使用功能标志切换的好方法？

有关功能标志切换的更多信息，请参见Q：如何使用功能标志切换，Q：什么是功能标志切换，在Pete Hodgson 在Martin Fowler博客上有关该主题的文章中进行了广泛介绍。

功能切换是高速开发中的常见做法，因为它们使开发与发布脱钩。 开发团队可以在禁用状态下将新功能“软发布”到生产中。这样可以随时释放该功能。如果功能依赖于其他工作或准备工作，则无需等待主要版本投入生产。

至于“说服”开发人员使用它们，这是为其提供的自由辩护的一种做法。我的经验是，对于开发人员而言，这并不是一个艰难的选择。管理层往往不愿尝试新事物。尝试这个：

• 查找功能切换框架。管理/业务可能更适合尝试由通用系统支持的事情
• 从小开始。在试用的基础上引入切换系统，以展示其实用性。
• 演示切换器进行A / B测试的能力。为您的Web场的一部分启用切换，然后收集行为指标。事实证明，页面布局的微小差异会对零售应用程序（例如Ebay，Amazon）的收入产生巨大影响

在理想的世界中，我认为您会推出一个新版本并感到惊讶！没有什么改变。这是因为您的所有新功能都在开关后面，而这些开关在关闭时会熄灭。

部署后，您将验证推出的服务是否仍然有效，电话再也不会响铃（除非是要响铃），等等。一旦返回已知的稳定操作，您就可以开始启用和验证您新部署的功能。

现在为您解答：您希望如何在一个随手可做的团队中工作，因为我们的站点和服务坚如磐石，而我们的用户却热爱我们，因此我们的用户非常喜欢我们？

那就是我要工作的团队。

如果需要，可以在这里停止阅读。

将所有功能置于功能开关的后面似乎会导致到处都是意大利面条代码。如果您使用IoC，并且能够在vNow / vNext / vPrevious之间进行选择，那么就可以维护您的配置。是的，还有更多签入程序，是的是更多类（componentV1，componentV2，componentV3等），但实际上您有一个更稳定的系统吗？怎么样？vNext没意思吗？使用控制塔切换回vNow。一周了，vNow有一个小错误？同样的事情-同样轻松地回到vPrevious。

没有麻烦，没有烦恼，没有睡眠，没有压力。

这不是白日梦。我以前在那里工作。希望我可以将其出售给我目前的团队。

成功的高速开发环境通常依赖于相当严格的自动化系统，该系统涉及质量验证以及对导致回归的错误更改的检测和拒绝。

功能切换提供了提交甚至进行中的未经测试的更改的功能，而不会因在集成分支中引起回归而被拒绝。这就构成了一个非常好的动机来引入功能，从而在功能生命的早期就进行了切换。

偏离真实CI并在特征分支上移动特征开发的缺点之一是缺乏这种动机。稍后，将功能分支合并到集成分支中时，添加功能切换通常会比较困难，就像任何后期集成一样。

开发人员（通常是开发经理）通常会寻求与框架相关的两个结果：易于管理和部署速度。您希望更快，更轻松地发布代码。

提供该方法有效的证据；尝试使用功能标记而非旧方法来构建小型POC。案例研究对战术人员（开发人员/工程师）的重要性不如战略人员（中层管理人员/产品设计师）重要。

开发人员无法决定具有功能切换的理由。这是产品所有者要关心的事情。开发人员以最可持续和安全的方式实现此更改。我批评这个问题。