稍微大一些的重构，我会比较推荐使用程序开关，使用一些控制参数来控制逻辑入口是用老代码还是新代码，这样在线上出现了问题，可以及时的调整控制参数，迅速的回滚到老的逻辑在线课堂。
如果程序运行的结果本身就是不确定的，不容易看出重构的错误，甚至推荐在重构的入口处设置 A/B 测试，这样在线上让一部分流量先走重构后的逻辑，同时将新 / 老逻辑的流量标记成不同的测试 bucket，可以在数据测量平台上看到新老代码的表现如何在线课堂。如果新代码的表现合理，则可以不断加大新代码的流量覆盖，直到 100%。
在我上面提到的重构中，我选择在竞价程序计算段创建了一个新的 A/B 测试，对照组采用将竞价结果写到数据库的方法，实验组则将竞价结果发送到消息队列在线课堂。同时在生产环境中，旧的和新的上传程序都在同时运行。在刚上线的时候，我选择将 1% 的竞价结果推送到消息队列中，然后观察新的上传程序能否将消息队列中的消息消耗掉。同时，在产品的监视页面，对对照组和实验组的竞价结果进行分析，确认两个组的竞价结果并没有明显的差别。