一条架构设计原则是把功能设计为能够禁用的。这种设计方法与设计为能够回退的相比，至少有两点不同之处。其-.如果实现得当，禁用个功能通常比把它恢复到之前的版本或发布要快。情况好时，应用会侦听专用的信道，根据指令禁用某个功能。其他的方法则可能需要重启应用，以便采用新的配置文件。但无论哪种方法，禁用造成扩展问题的功能，通常都比用之前发布的版本替换当前的版本要快得多。
一条架构设计原则是把功能设计为能够禁用的。这种设计方法与设计为能够回退的相比，至少有两点不同之处。其-.如果实现得当，禁用个功能通常比把它恢复到之前的版本或发布要快。情况好时，应用会侦听专用的信道，根据指令禁用某个功能。其他的方法则可能需要重启应用，以便采用新的配置文件。但无论哪种方法，禁用造成扩展问题的功能，通常都比用之前发布的版本替换当前的版本要快得多。
禁用功能与回退的另一点 不同之处在于，它允许一个发布中的其他功能， 无论是新功能还是修改过的功能，继续正常运行。用我们的约会网站做例子，如果我们一一次发布了两个功能，一个是搜索“他和我们的朋友约会过吗”，另一个是对某次约会进行评级，我们可以只禁用搜索功能，直到它破修复了为止，而不是回退整个发布，导致两个功能都不能用。对于-次发布中包含多个修复、修改过的功能或新功能，这种方法具有明显的优势。
不过，如果把所有功能都设计为能够禁用的，有时增加的成本甚至比设计为能够回退到指定发布版本的还多。理想的情况是，设计为能够禁用的和设计为能够回退的实现成本都很低，公司可以选择为所有新的和修改过的功能都实现这两种设计。但更可能的是，找出高风险的功能，从而确定哪些功能应该被设计为能够禁用的。代码重用或异步调用的共享服务有助于大大减少实现能够根据需求禁用的功能的成本。同时实现回退和功能禁用，可以创造出具有适应性、灵活的生产环境，而不必依赖像量大、高成本又往往低回报的性能测试这样的预测性方法，从而可以实现敏捷性。
如果实现得当，设计为能够禁用的和设计为能够回退的实际上可以缩短上市时间，因为它们允许你在生产过程中冒一些风险，而这在没有应用这俩原则时是不会被考虑的。虽然无法取代负轻松回退实现。载测试和性能测试，但它们允许你以更快的方式执行这些测试，因为你知道发布之后你仍然可以测试。
可能您还想看