软件工程进阶之每日构建.docVIP

概述 在昨天“正确地做事(善用工具)”的帖子里提到了代码提交频度的问题。当时我特别强调了“要保证提交的代码能编译通过”，理由是“对于每日构建很重要”。我估计列位看官中，不太熟悉每日构建的，大有人在；而且国内停留在手工作坊阶段的软件公司，为数也不少。因此今天我们就来说一下每日构建这个话题。假如你平时已经很善于运用每日构建这一有效的手段，可以直接略过本系列，去看其它帖子。 照例先来说说什么是“每日构建”，每日构建在洋文里也称为Daily Build或者Nightly Build。具体定义见“这里”。简单地讲，就是每天都把整个软件项目自动编译一遍，最终生成的产出物必须和交付到用户手中的一样（比如你最终提交给用户的是一个安装程序，那就必须在开发过程中每天编译出一个安装包）。 为了表明每日构建是一个很有效的手段，我可以给大伙举几个知名软件公司或者著名开源项目的例子： 1、微软公司内部几乎所有产品的开发过程，都会使用每日构建。 2、我不确定Google是否所有产品都采用，但至少Google的Chrome浏览器是采用每日构建。 3、知名的开源组织Mozilla也大量使用每日构建。 4、知名的Linux发行版Ubuntu也使用每日构建。　...... 上面这个列表还可以罗列很长。举这么多例子，无非想说，每日构建是一种牛X的软件工程手段。尤其对于复杂项目和大型团队，它的好处更加明显。看到这儿，有同学可能要问了，具体有些什么好处捏？请看“软件工程进阶之每日构建[1]：好处和优点”。 [1]：好处和优点 上一个帖子“软件工程进阶之每日构建[0]：概述”提到说每日构建是一种很牛X的软件工程手段。本帖子就来说说它到底有多牛X。为了加深大伙儿的印象，我先来说一些陈年往事。 话说上世纪末，我还在一家小公司干活，并参与开发了一个C++的项目。当时公司的流程是：开发人员写好代码，自己编译好，丢给测试人员测试；测试人员如果发现bug，口头通知开发人员改；开发人员改好bug，再丢给测试人员测试...... 案例1（开发的混乱）　有一天，开发组的小头目找来程序员甲。　小头目：你负责的XX功能完成了没有？　程序员甲：早做完啦！　小头目：那测试人员甲怎么说一直没看到XX功能？　程序员甲：不会吧！我去瞧瞧。　若干分钟后，程序员甲回来。　程序员甲：不好意思，编译好的EXE我只发给了测试人员乙，忘记发给测试人员甲了。　小头目：!@#$%^*（此处省略15字） 案例2（测试的混乱）　另一天刚上班。　测试人员甲：今天的XX.EXE怎么一运行就崩溃？　测试人员乙：有吗？我这儿好好的呀！　测试人员甲：真见鬼！我找开发问一下。　经过若干分钟打听，知道XX.EXE是程序员丙负责，于是找来程序员丙。　测试人员甲：为啥你做的XX.EXE一运行就崩溃？　程序员丙：有这回事？！让我看看你的环境。　程序员丙在测试人员甲的机器上研究了N刻钟后。　程序员丙：你是猪脑啊，你没有更新XXX.DLL，害我浪费这么长时间！　测试人员甲：你才是猪脑！我怎么知道XX.EXE会用到XXX.DLL？　然后两人开始对骂...... 案例3（集成的混乱） 临近项目交付了，开发人员都在忙着改bug，测试人员都在忙着复测bug，没有人手准备安装包，于是安装包的制作一直拖到项目交付的前一天才开始搞。制作安装包本身倒是很快，半天就搞定。但是......　小头目：做好的安装包应该没什么问题吧？　测试人员丙：呃，这个，这个......好像装出来的软件没法运行，直接崩溃了。　小头目：偶的神啊！还愣着干嘛，快去查原因！！！今天不搞定大家不许回家！！！　然后开发和测试通力协作，经过艰苦卓绝的努力，到了午夜时分，终于发现：有个DLL是Debug版本...... 有同学可能会问：为啥平时测试的时候没发现这个问题捏？因为平时团队里面都使用Debug版本，方便ASSERT断言。到了作安装包那天，照道理应该统一编译Release版本，但是有个家伙遗漏了，所以混了一个Debug版本的DLL在里面。等安装完运行程序时，该DLL动态加载失败，所以程序就崩溃鸟。 我上面说的这些情形，到今天为止，还在很多公司内部上演。那为啥每日构建能搞定上面这些问题捏？且听我细细道来： 针对“开发的混乱” 对于每日构建的流程，开发人员只要负责提交代码到代码库中。不需要挨个给测试人员提供编译后的二进制文件。因此案例1的问题（漏给测试文件）迎刃而解。 针对“测试的混乱” 在开发阶段，由于测试拿到的程序都是自动编译出来的，因此保证了所有测试人员拿到的是统一的运行程序，并且这个程序和代码库中最新的代码是相对应的。 在测试阶段，每一个开发人员修复了Bug之后，都必须把改过的代码提交到代码库，测试人员才会拿到改过Bug的二进制程