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

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自动化测试，代码一旦被合并到开发主干，便自动部署到相应的环境，并执行自动化测试。

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

还未吐完，待续.....