11.把改进方案讲给老大听

晓川所在的部门，叫配置管理部，晓川到现在也没弄清楚为什么叫配置管理部。晓川曾经问过师父这个问题，师父说，“牛就叫牛，没有为什么。既然当牛，那就吃草耕田，不用想这么多。”配置管理部的责任呢，主要是三件事儿，各个项目每两周一次的软件集成，软件开发完毕后的对外发布，还有版本控制工具的支持和维护工作。

部门经理，也就是晓川的老大，是个三十多岁的女同志，好像比师父还小一点。她桌上摆着她宝贝儿的照片。一起吃饭的时候，她聊起过自己的经历，说在这家公司呆了很多年，当初公司主要搞硬件，她搞固件上的编程，后来老了，觉得越来越干不动了，刚好公司加强软件研发，有这么个机会，就过来了。她总说自己经验也不多，让大家在技术上要多钻研。她确实不太懂技术细节，但是在她手底下工作，大家都觉得挺舒服的。

在跟项目经理老刘开会之前，晓川的老大先来到晓川工位上，找晓川和晓川的师父了解情况。老大开场白说，本来是想安排晓川学着干点儿别的活儿的，不过既然项目上提出了需求，那可以考虑。我们一起讨论一下看行不行。现在先来看看工作量。

“晓川，一周出一个版本，你的工作量会不会加倍？”老大问。

“有些工作会加倍的。比如发邮件通告集成的启动和结束，比如创建基线的时候打标签，等等。但是这不是工作的主要内容。工作的主要内容是对付版本合并时的冲突，以及随后编译构建时的冲突。这些工作不会加倍。”晓川答。

“这么说，工作量会略有增加，但不会增加到以前的两倍？”

“嗯，有可能。但是也有可能降低了。”

“我是说总工作量，不是每轮集成的工作量。”

“嗯，我明白，我就是想说，当从每两周出一个版本变成每周出一个版本后，总的工作量有可能会降低。”

老大满脸疑惑，看看晓川，又看看师父。师父也满脸疑惑。晓川看两个人都满脸疑惑，就提议找个白板画一下。

在白板上，晓川开始画图。如图4所示。

图4 若每两周一条基线

边画边解释：“简便起见，假定每两周的提交一共有六个，而且每个提交的改动量都一样多。如果每周集成一次的话，那么发生的合并就分别是，处理第一个提交，无需合并。处理第二个提交，一份改动跟一份改动合并。处理第三个提交，一份对两份。第四个，一份对三份。第五个，一份对四份。第六个，一份对五份。”

老大还有点儿疑惑，师父解释了两句。看老大点头了，晓川接着说：“而如果每周集成一轮呢，那么第一轮中，发生的合并是，处理第一个提交，无需合并。处理第二个提交，一份改动跟一份改动合并。处理第三个提交，一份对两份。这跟每周集成一轮时的情形一模一样。不过，从处理第四个提交开始，就不一样了。第四个提交，这里变成了下一轮集成要处理的第一个提交。”

晓川边说边画。“这第一个提交呢，又不用合并了。第二个提交，一份对一份。第三个提交，一份对两份。”

晓川说到这儿，图也画完了。两种情况放在一起，是这个效果。如图5所示。

图5 每两周一条基线与每周一条基线对比

“现在集成时主要精力是处理合并时的版本冲突，以及合并带来的编译链接错误。如果合并的量小了，那么这两方面的问题都会减少，所以集成就轻松了。至少理论上是这样。”

老大又问了些问题，晓川一一解释。最后老大说，“好，知道了。谢谢。”