敏捷反思之: 主干开发的好处看起来很美, 对你却效果寥寥

image.png

很多人一提到主干开发,就会blablabla的讲到这些好处

  • 频繁提交,及早暴露冲突
  • 频繁集成
  • 频繁部署
  • 频繁验证
  • 避免依赖阻塞
    B 需要依赖 A正在工作的某一部分(如某个接口、某个服务类....),两个都不断提交和同步自己的半成品代码,B便能及时用到A的那一部分

看到这些好处,是不是垂涎三尺。

且慢,请问,你的项目,有相应的单元测试吗? 有相应的UI自动化测试吗?有CI/CD吗?

如果有,你可以得到它了。

如果还没有,那么,请问
你向主线的提交 commit & push,有多频繁?每几分钟?每十几分钟?每小时? 每半天?

超过 每半天 级别,就已经谈不上频繁了,好吗!

如果没有单元测试,你的再频发提交,也只是为了少些代码合并冲突罢了。
对于类似java这些编译型语言,至少还有另一个好处 - 检查是否能编译。
(但代码冲突真的是坏事吗?未必~ 后面我再单独写着这个事情。)

业务逻辑冲突才是问题,但是,你真的能每提交一小步,就到主线开发集成环境上主动手工做一轮测试吗? 你一天能做几次?

你和你工作伙伴,敢直接想主线push半成品代码吗?
什么叫半成品代码? 就是一个功能还没完成,只写的部分代码(even 只有十几行代码)。

正常的CI/CD,你的每一次push, 都应当触发自动化部署。你们一天触发多少次部署?

没有单元测试兜底,我真不相信你们的主线提交频率,能高到哪里去。
这种情况下,频繁提交,更像是频繁提交垃圾,尤其是动态语言项目。

另外,你在第1步到第4步之间的代码变化,对于其他人来说,就是个黑箱子,你没完成第5步,你的队友看的见你的代码吗?

我在第2步中,业务逻辑实现有些不对路。其他人能够及时看到? 又是如何看到的?

我们的主干,什么时候是稳定的?可以发布的?

迭代进行到一半,我们突然被要求上线,当时的主干,能直接上吗?

你的队友的代码写法有问题,都push进去了,你还有多少可能性让他修改?


image.png

哦,还有一点,大家还会说 半成品加 特性开关 就可以啦~

哪如果是对一个已有的功能做修改呢?你还能 特性开关 吗?

让我们来演练一下一个不少见的case:

我在做一个已有功能的修改,其中改动到一些其他人也用到的方法, 迭代结束时,我只做了一半,这一半已经提交进主线。 但是,迭代结束要求发布,我们改如何做?

为了快速提交,我的这一半,分了5个commits,分布在周四, 周五,周四周五的中间,都有其他伙伴的提交混杂着。

  • A 要么,不发布,等我完全做完。

  • B 要么,发布,把我前面的那一小半修改,撤回。

当 A 不被接受。
那么 B 如何有效快速的做到?
再来个雪上加霜,因为我的那一小部分提交,导致在我后面提交的其他伙伴修改了一些代码冲突。
我的撤回,他的还能工作吗?

当然,你可以告诉我说 C选项 半成品不要提交,那么这还是 最开始的“基于主干开发的频繁提交” 吗?

我在2017年带的小团队,用的就是基于主干开发,频繁提交,频繁集成,频繁部署,频繁验证。每个人都敢提交半成品代码,根据需要修改任意代码。

我们的基础是,带有充足的单元测试,功能测试,接口测试,集成测试的CI,手动的UI自动化测试,代码一旦被合并到开发主干,便自动部署到相应的环境,并执行自动化测试。

如果你的团队没有这个基础,而能很好的做到 能频繁的写一个小方法就提交代码到开发主干,并且团队协作良好的。
欢迎来跟我分享一下你真实案例,我请你吃饭。

还未吐完,待续.....