Dec December 2011

企业C++大型系统遗留代码变迁的布道之旅

企业C++大型系统遗留代码变迁的布道之旅

前沿

特别声明:本文专为图灵社区活动“唤醒你心中的布道师”而写,欢迎大家积极参与!

程序员杂志第十二期中讲到了企业开发的困境,其中有一点就是企业有很多的遗留代码,而且是C/C++的大型系统。怎么处理一直是推动软件开发中的头疼问题,为什么头疼呢?

  1. 旧代码,又大,怎么下手,时间在哪里?
  2. C/C++代码,和java比起来没有统一的单元测试工具,又难改造,怎么办?

现在我们已经基本完成了这个转变,主要代码覆盖率在60%以上,很好得支持了敏捷开发(如持续集成)。

在看了布道之道一书后,把我们用的一些技巧和策略用实际例子和大家一起来探讨一下。

背景介绍

变革开始于2007年左右,那时,这是一个有几十万行代码的C++产品,始于上个世纪末,基于Corba,XML,组件(component)的技术,由于架构的关系,没有单元测试,只有集成测试。

功能持续增加,开发者交付压力大。质量开始有下降、维护成本有提高的苗头。

我们就想通过提高C++的代码测试覆盖率来解决这些问题;这就需要把单元测试从无到有,再到一个高度。

基础这么差,不得不需要布道!

什么样的怀疑者

在推动这个变革前,先看看有什么样的怀疑者会阻碍你。

在大公司里最多的还是孤陋寡闻型,时间紧迫型。

孤陋寡闻型:主要是开发者,我又想叫他们埋头苦干型。因为他们干活踏踏实实,只是由于项目压力的关系,没有额外的时间去看看外面的新技术,习惯了按步就班。

他们早已经习惯了用集成测试来替代单元测试。猛然间听说要上单元测试,一下子就觉得不行。Java么还可以考虑考虑,C++的产品需要搞单元测试吗?而且这种复杂的架构,能搞成功吗?就算能成,代价也太大了,那么多旧的代码,不可能!

时间紧迫型:主要就是项目管理者,他们最大的愿望是项目准时完成,质量达到要求,项目完成后,他们基本就会转战到另一个战场。

所以一听说想在项目里面加点东西,还不知道干嘛呢,就问多少时间?问为什么在这个项目做(潜台词就是别在我这儿捣乱)。等到一听说要做以前都不做的单元测试,头摇得就像拨浪鼓一样,死活都不肯。

对症下药:采用合适的技术

对上面两种人和我们要解决的问题,我们采用了好多种方法,下面介绍主要的两种:展示技术和适当妥协

展示技术:你要告诉他们,你要推动的变革是可以做到的,这样来消除他们的疑惑。

这是对付孤陋寡闻型的最好办法,告诉他们这个能做到,也没有想象中的难。

我记得我花了两周的时间找了一个最典型的组件,采用了CppUnit这个单元测试框架,并应用了虚函数(java中的接口)的方式把对平台架构的依赖全部隔离掉,顺利地跑通了几个测试。并且我还准备了ppt,召集大家一起来探讨确认这是一个可以工作的方式。

就象书上说的,孤陋寡闻型的人看到了, 了解了以后,就很容易得接受你的建议了。

适当妥协:就是要找到折中方案,让大家都能过的去。

这是对付时间紧迫型的一个好办法,要求不能太高,把一下子想做的东西放在一个地方。

我们决定用循序渐进的方式,提出一个中肯的方案:

  1. 新代码必须要用单元测试,这个没话可说,因为从项目质量上这个是可以要求的。当然怎么做单元测试,由于是新的,会有人提供培训和帮助。
  2. 旧代码在改变时必须要用单元测试,因为改了代码,有测试保证这也是应该的。
  3. 在改动的组件中,每次要对旧代码增加一些测试。

这样一来,每个项目中都会对单元测试有所贡献,长而久之,会积累到比较客观的数量,虽然慢了点,但还是往前进步的。

时间紧迫型当然不是吃素的,老觉得亏了点,就盯着第三点说:“项目没时间做这个额外的事情”,这个要靠策略了。

辅以策略:贯彻实施

两个最基本的策略:竭力支持者,说服管理层。

竭力支持者 是最该采纳的,他们会鼓动周边的人和你一起服务,要善于团结他们,这要就扭成了一股绳。

对大多数有经验的开发者,大家都明白单元测试是保证质量的最好办法,技术上说服以后,他们很快就变成了竭力支持者,觉得不加单元测试就是一种罪过,项目中有谁忘了,竭力支持者也会及时提醒他们,不需要你们一直跟踪,减轻了很多压力。

说服管理层 是一个最棒的方式,当然前提是你要能说服他们。

实际上管理层也知道没有单元测试这一弊端,只是苦于没有行之有效的方案而已。所以当你告诉他们技术上没有问题了,代价也不是很大,并且你又提供了切实可行的计划。管理层立马会通知大家把这个落实到各个项目中去(包括上面的第三条)。

拿到了这个尚方宝剑,没有谁会阻碍了,我们就可以把主要精力花在技术支持上,当然千万不能搞砸了。

收获果实

果然,经过了几年,到2010年单元测试已经达到了60%左右(对C++来说不错了),现在开发人员也习以为常了。

结束语

布道之道 真是一本好书(翻译要记一功),它的好多种模式一看就明白。如果你是个有经验的人,你会发现你的很多技巧都在书上提到了,它会帮你进一步的提炼升华,使你下次做的更好。

布道会使你有一种成就感,让我们一起来把这个软件行业变得越来越好吧。

其他

本文也是我用git记录在github上的,你可以看到每次的变化。

如果对此文有兴趣,帮忙顶一下,别忘了 @larrycaiyu ,希望有机会有人能帮我推荐到QConf 2012中去分享,到时我们可以探讨得更多。

这儿再留一个关子,如何建立一个好的C++代码质量检测框架,并且最终和其他java代码质量清晰得显示在一起又是另外一个布道故事了,而且有一些就是因为没有看这本书而得到的一个反面教材。

blog comments powered by Disqus
comments powered by Disqus