评论数:3条

软件工程进阶之每日构建[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