2018-06-09这样会不会导致一堆类似IF ELSE的判断。看着也令人很头疼吧。
调试和问题修复的时候复杂度应该也会增加不少。作者回复: 是有技术债问题，所以要定期清理，但用好了很有用，是很多一线公司的devops最佳实践
7
2019-02-02这个就好像以前用svn管理代码的时候，对于个性化开发的需求都是通过if else 去做了，后面发现一堆代码债。后面使用git多分支管理，特定需求拉新分支去处理，不影响主干的功能，和代码侵入。怎么说呢，感觉如果功能多的，配置中心会有一堆配置开关的，也不敢维护，如果配置中心有一个测试通过，正式发布新功能的时候，自动屏蔽老功能代码就好咯。作者回复: 两种方式都是有利有弊，分支有冲突问题，TBD有代码债问题，没有绝对好，需要研发流程规范和治理配合。之前在eBay，开关驱动开发有大规模生产实践，效果不错。
1
2018-11-04非常不错。看完之后，我觉得开关驱动开发非常合适与重构。作者回复: 对，可以先把apollo搭建起来，FDD对研发效能和系统稳定性、DevOps等都有立杆见影效果
1
2018-09-27实践中已经有挺多类似做法，但是没上升到方法论层面，现在听杨老师一讲，觉得可以大规模推广。定期清理很关键，这要通过机制来解决，时间长了谁都说不清楚。作者回复: 恩，开关驱动开发是业界最佳实践，国内还未普及，需要架构师布道宣传，我也是做些布道宣传。
1
2018-12-22那F2.1的代码最后怎么办？不回master的话，下次release怎么处理呢？作者回复: 先在主干上修复bug，再从F2 release切F2.1分支，再将主干反向merge到F2.1，可参考原文（ppt里头有原文链接）。
2018-11-23老师，今天学习了TBD ，想问个问题，如果使用开关控制新老功能的交替，假如存储层结构在新老功能交替中有变化，这种情况 通常怎么处理？作者回复: 开关驱动重构一般是向下兼容的，这样在出问题后才能安全退回去，存储结构变化也没关系，你把它们先封装在抽象接口（API或服务）后面，只要接口不变向下兼容，你后台的具体存储就可以腾挪变化。
2018-11-20咨询下老师,如果是微服务,自己处理自己的项目，那么按理来说不会有这种合并问题吧,同时做小版本的迭代,迭代周期不会超过半个月作者回复: 微服务团队可大可小，还是会一个团队门人有几个组员并行开发需合并的场景，开关驱动开发建议基于主干开发减少合并，适合微服务，迭代周期二周左右节奏
- 2018-11-20收获很大
作者回复: 谢谢支持！加油💪
- 2018-11-13这种情况不好做code review吧。每天提交到主干的代码不一定是完整的功能
作者回复: 这种模式下要求每次提交都是较完整功能，保证主干始终可build可布署，暂不起用功能躲在开关后面