软件集成策略故事连载----对项目的不利影响竟然这么大

2．对项目的不利影响竟然这么大

周一早上。老刘先是说了些感谢的话，感谢晓川的辛苦工作。晓川听了很欣慰。接着，老刘用笔记本给晓川展示了一张巨大的图，跟他说，这是项目的任务计划图。好复杂啊，晓川看得一愣一愣的。老刘见状，转向白板，在白板上给晓川画了张简单的图。如图 1所示。

"晓川，我想让你了解，你的工作对于这个项目有多重要。看这张图，这是一个典型的例子。开发任务 B、C、D要想开始，必须在开发任务 A完成之后。类似这样一个一个任务串在一起，就决定了项目至少需要多久才能完成。这个你能理解吧？"

"能。 "

"但是现在 A任务完成后， B、C、D任务不能立即开始。即便是 B、C、D任务的人手已经到位了也不行。你知道细节。 "

"嗯，A任务完成后，要等到下一轮集成时才能去集成。而集成本身也需要时间，要等集成结束， A任务对应的改动进了基线才行。这时候大家才能看到 A任务的成果， B任务才能开始。"晓川很熟悉。

"现在要等多久？"老刘问。

"嗯，那要看我这边集成需要多久。刚结束的一次是整整一周。哦，不止是集成的时间。还要算上等待集成的时间。如果刚好是周一上午完成的，那几乎不用等。如果不巧是周二完成的，或者就晚了一步，是周一下午完成的，那就要先等上两个星期。也就是说，平均要先用一个星期等待进入集成环节，再用一个星期等待完成集成。 "

晓川说完，陷入沉思。以前只是觉得自己的工作很辛苦，没想到，整个项目都在看着我，指望我快些、再快些……

"我知道你很辛苦，晓川，"老刘说，"现在你也知道我多么期待你把工作做得更好。你有什么好主意吗？"

晓川："我觉得关键是开发人员提交代码的质量。如果他们在提交前保证代码是可以编译通过的，那集成的时候就不会有构建问题了。现在昀费时间的就是集成的时候反复构建。 "

老刘："你是说，大部分时间是用在反复构建上，而不是在这之前的版本合并上？"

晓川："对，是这样。比如这次集成，星期一下午一点开始处理大家的提交。您知道，大家的代码改动，都在各自的任务分支上。所谓提交，就是告诉我，等到集成时，要把他的分支合并到集成分支。在我合并的过程中，可能会遇到版本合并冲突，我就要协调，谁提交的，就找谁解决。快下班的时候我给所有的还有提交没有处理的程序员发了邮件，让他们待命，准备解决冲突。这样，到晚上九点的时候，所有的版本合并冲突都解决完了。而后面的时间，就都费在反复构建上了。"

老刘："好。那看来反复构建昀费时间。然后你的思路是，如果程序员提交的版本都是能构建的，你这里就不需要反复构建了？"

"对。这样的话，说不定周二早上，任务 B、C、D就可以开始了。 "晓川很有信心。

"如果程序员的提交都没问题，你确定你构建的时候就肯定没问题么？"老刘降低了语速，一个字一个字地说。

"那当然，但是……"晓川意识到了什么，好像这里的逻辑看似简单明确，其实并不是严格的推理。

"这样吧，我看到你有一些想法，这很好。你再想一想。多调查调查，看看现在究竟是什么原因需要反复构建。也跟大家聊聊。总之，请你帮忙想想办法，缩短从任务 A完成到任务 B可以启动这中间的时间。 "

本文节选自《软件集成策略》一书

董越 著.
电子工业出版社出版。