功能标志（或切换）通常用于控制产品中新特性的可见性。有几种不同的实现方式，但最常被讨论和推广的是使用功能标志管理软件。当然，最简单的方法是硬编码它们，尽管关于这一点的讨论较少。虽然功能标志管理软件可能很强大，但它们也是复杂性和风险的来源。围绕它们的博客营销如此强烈，以至于承认它们并非必要就像是在承认技术无能。我们已经说服自己，不仅需要几个功能标志，还需要扩展到数千个功能标志。不仅如此，我们绝对需要在运行时更改一个特性，我们绝对必须在不进行部署、不重启、不清除缓存、不迁移数据库的情况下做到这一点，不经过审查和测试，因为业务正在燃烧，唯一的解决办法是更改主页按钮的颜色。这种系统所能提供的唯一标志就是#ff0000类型。从架构的角度来看，它们不过是被美化的if语句，管理在一个单独的进程中。通常需要自己独立的基础设施、托管、监控，以及伴随而来的所有责任。从开发生命周期的角度来看，它们引入了非确定性行为，使得对代码的推理变得更加困难。尽管初衷良好的长期存在功能标志会导致技术债务，使代码库僵化；这种风险确实存在于硬编码标志中，但更容易被发现和管理。从安全的角度来看，它们是一个负担，因为攻击或漏洞的表面面积现在已经增加。在任何情况下，向任何软件系统添加更多活动部件都应该受到严格审查，以确定它是否真的必要，以及它所引入的风险是否值得解决的问题。硬编码功能标志消除了许多这些问题；它们简单、可靠、安全。它们是最无聊的实现方式，这就是它们是最佳实现方式的原因。只需从简单的JSON文件开始，在应用程序启动时读取它，并用它来控制特性的可见性。随时关注这些标志，当它们不再需要时将其删除。如果它们存在太长时间，则将其实际行为化并删除标志。通过正常的开发过程更改一个值，进行审查、测试和部署。对于大多数团队和产品，这通常足够好，并且会有很大的使用价值。当一个团队实际上需要在大规模运行时更改一个特性时，就像在单页应用中的状态管理，他们会知道他们需要它。过早优化不是可行之道。这是一种糟糕的设计，糟糕的工程，只能在技术会议上，在销售讲师询问是否有人在使用它们时，带来短暂的自我陶醉的得意时刻。