软件工程进阶之每日构建[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 的二进制软件包才会到测试人员手中。如果某个开发人员改了 Bug 但是没有提交代码，那么在测试人员看来，相当于他的 Bug 一直没有改，因此他的 Bug 就一直不会被关闭。
　　所以“弊端2”的情况也不会出现。

◇针对“集成的混乱”

　　对于每日构建来说，每天都会生成安装包（或者“安装光盘的ISO镜像”）。也就是说，从项目开始开发的那天起，每天都在进行集成（这就是传说中的【持续集成】）。因此，集成的问题，在一开始就会暴露出来，而不用等到项目后期。


　　其实每日构建的好处除了上述三点（这三点俺认为比较重要），还有其它很多，大伙儿可以自己再琢磨一下。
　　后面一个帖子，俺把每日构建需要的准备工作介绍一下。

版权声明
本博客所有的原创文章，作者皆保留版权。转载必须包含本声明，保持本文完整，并以超链接形式注明作者编程随想和本文原始地址：
https://program-think.blogspot.com/2009/02/daily-build-1-advantage.html?m=0