• 王宁
    2018-06-09
    这样会不会导致一堆类似IF ELSE的判断。看着也令人很头疼吧。
    调试和问题修复的时候复杂度应该也会增加不少。

    作者回复: 是有技术债问题,所以要定期清理,但用好了很有用,是很多一线公司的devops最佳实践

    
     7
  • yien
    2019-02-02
    这个就好像以前用svn管理代码的时候,对于个性化开发的需求都是通过if else 去做了,后面发现一堆代码债。后面使用git多分支管理,特定需求拉新分支去处理,不影响主干的功能,和代码侵入。怎么说呢,感觉如果功能多的,配置中心会有一堆配置开关的,也不敢维护,如果配置中心有一个测试通过,正式发布新功能的时候,自动屏蔽老功能代码就好咯。

    作者回复: 两种方式都是有利有弊,分支有冲突问题,TBD有代码债问题,没有绝对好,需要研发流程规范和治理配合。之前在eBay,开关驱动开发有大规模生产实践,效果不错。

    
     1
  • 幻想
    2018-11-04
    非常不错。看完之后,我觉得开关驱动开发非常合适与重构。

    作者回复: 对,可以先把apollo搭建起来,FDD对研发效能和系统稳定性、DevOps等都有立杆见影效果

    
     1
  • winter0703
    2018-09-27
    实践中已经有挺多类似做法,但是没上升到方法论层面,现在听杨老师一讲,觉得可以大规模推广。定期清理很关键,这要通过机制来解决,时间长了谁都说不清楚。

    作者回复: 恩,开关驱动开发是业界最佳实践,国内还未普及,需要架构师布道宣传,我也是做些布道宣传。

    
     1
  • Nick
    2018-12-22
    那F2.1的代码最后怎么办?不回master的话,下次release怎么处理呢?

    作者回复: 先在主干上修复bug,再从F2 release切F2.1分支,再将主干反向merge到F2.1,可参考原文(ppt里头有原文链接)。

    
    
  • Eric
    2018-11-23
    老师,今天学习了TBD ,想问个问题,如果使用开关控制新老功能的交替,假如存储层结构在新老功能交替中有变化,这种情况 通常怎么处理?

    作者回复: 开关驱动重构一般是向下兼容的,这样在出问题后才能安全退回去,存储结构变化也没关系,你把它们先封装在抽象接口(API或服务)后面,只要接口不变向下兼容,你后台的具体存储就可以腾挪变化。

    
    
  • self-discipline
    2018-11-20
    咨询下老师,如果是微服务,自己处理自己的项目,那么按理来说不会有这种合并问题吧,同时做小版本的迭代,迭代周期不会超过半个月

    作者回复: 微服务团队可大可小,还是会一个团队门人有几个组员并行开发需合并的场景,开关驱动开发建议基于主干开发减少合并,适合微服务,迭代周期二周左右节奏

    
    
  • self-discipline
    2018-11-20
    收获很大

    作者回复: 谢谢支持!加油💪

    
    
  • 莫行
    2018-11-13
    这种情况不好做code review吧。每天提交到主干的代码不一定是完整的功能

    作者回复: 这种模式下要求每次提交都是较完整功能,保证主干始终可build可布署,暂不起用功能躲在开关后面

    
    
我们在线,来聊聊吧