企业C++大型系统遗留代码变迁的布道之旅
#企业C++大型系统遗留代码变迁的布道之旅# #前沿#
特别声明:本文专为图灵社区活动“唤醒你心中的布道师”而写,欢迎大家积极参与!
程序员杂志第十二期中讲到了企业开发的困境,其中有一点就是企业有很多的遗留代码,而且是C/C++的大型系统。怎么处理一直是推动软件开发中的头疼问题,为什么头疼呢?
- 旧代码,又大,怎么下手,时间在哪里?
- C/C++代码,和java比起来没有统一的单元测试工具,又难改造,怎么办?
现在我们已经基本完成了这个转变,主要代码覆盖率在60%以上,很好得支持了敏捷开发(如持续集成)。
在看了布道之道一书后,把我们用的一些技巧和策略用实际例子和大家一起来探讨一下。
#背景介绍# 变革开始于2007年左右,那时,这是一个有几十万行代码的C++产品,始于上个世纪末,基于Corba,XML,组件(component)的技术,由于架构的关系,没有单元测试,只有集成测试。
功能持续增加,开发者交付压力大。质量开始有下降、维护成本有提高的苗头。
我们就想通过提高C++的代码测试覆盖率来解决这些问题;这就需要把单元测试从无到有,再到一个高度。
基础这么差,不得不需要布道!
#什么样的怀疑者# 在推动这个变革前,先看看有什么样的怀疑者会阻碍你。
在大公司里最多的还是孤陋寡闻型,时间紧迫型。
孤陋寡闻型:主要是开发者,我又想叫他们埋头苦干型。因为他们干活踏踏实实,只是由于项目压力的关系,没有额外的时间去看看外面的新技术,习惯了按步就班。
他们早已经习惯了用集成测试来替代单元测试。猛然间听说要上单元测试,一下子就觉得不行。Java么还可以考虑考虑,C++的产品需要搞单元测试吗?而且这种复杂的架构,能搞成功吗?就算能成,代价也太大了,那么多旧的代码,不可能!
时间紧迫型:主要就是项目管理者,他们最大的愿望是项目准时完成,质量达到要求,项目完成后,他们基本就会转战到另一个战场。
所以一听说想在项目里面加点东西,还不知道干嘛呢,就问多少时间?问为什么在这个项目做(潜台词就是别在我这儿捣乱)。等到一听说要做以前都不做的单元测试,头摇得就像拨浪鼓一样,死活都不肯。
#对症下药:采用合适的技术# 对上面两种人和我们要解决的问题,我们采用了好多种方法,下面介绍主要的两种:展示技术和适当妥协
展示技术:你要告诉他们,你要推动的变革是可以做到的,这样来消除他们的疑惑。
这是对付孤陋寡闻型的最好办法,告诉他们这个能做到,也没有想象中的难。
我记得我花了两周的时间找了一个最典型的组件,采用了CppUnit这个单元测试框架,并应用了虚函数(java中的接口)的方式把对平台架构的依赖全部隔离掉,顺利地跑通了几个测试。并且我还准备了ppt,召集大家一起来探讨确认这是一个可以工作的方式。
就象书上说的,孤陋寡闻型的人看到了, 了解了以后,就很容易得接受你的建议了。
适当妥协:就是要找到折中方案,让大家都能过的去。
这是对付时间紧迫型的一个好办法,要求不能太高,把一下子想做的东西放在一个地方。
我们决定用循序渐进的方式,提出一个中肯的方案:
- 新代码必须要用单元测试,这个没话可说,因为从项目质量上这个是可以要求的。当然怎么做单元测试,由于是新的,会有人提供培训和帮助。
- 旧代码在改变时必须要用单元测试,因为改了代码,有测试保证这也是应该的。
- 在改动的组件中,每次要对旧代码增加一些测试。
这样一来,每个项目中都会对单元测试有所贡献,长而久之,会积累到比较客观的数量,虽然慢了点,但还是往前进步的。
时间紧迫型当然不是吃素的,老觉得亏了点,就盯着第三点说:“项目没时间做这个额外的事情”,这个要靠策略了。
#辅以策略:贯彻实施# 两个最基本的策略:竭力支持者,说服管理层。
竭力支持者 是最该采纳的,他们会鼓动周边的人和你一起服务,要善于团结他们,这要就扭成了一股绳。
对大多数有经验的开发者,大家都明白单元测试是保证质量的最好办法,技术上说服以后,他们很快就变成了竭力支持者,觉得不加单元测试就是一种罪过,项目中有谁忘了,竭力支持者也会及时提醒他们,不需要你们一直跟踪,减轻了很多压力。
说服管理层 是一个最棒的方式,当然前提是你要能说服他们。
实际上管理层也知道没有单元测试这一弊端,只是苦于没有行之有效的方案而已。所以当你告诉他们技术上没有问题了,代价也不是很大,并且你又提供了切实可行的计划。管理层立马会通知大家把这个落实到各个项目中去(包括上面的第三条)。
拿到了这个尚方宝剑,没有谁会阻碍了,我们就可以把主要精力花在技术支持上,当然千万不能搞砸了。
#收获果实# 果然,经过了几年,到2010年单元测试已经达到了60%左右(对C++来说不错了),现在开发人员也习以为常了。
#结束语# 布道之道 真是一本好书(翻译要记一功),它的好多种模式一看就明白。如果你是个有经验的人,你会发现你的很多技巧都在书上提到了,它会帮你进一步的提炼升华,使你下次做的更好。
布道会使你有一种成就感,让我们一起来把这个软件行业变得越来越好吧。
#其他# 本文也是我用git记录在github上的,你可以看到每次的变化。
如果对此文有兴趣,帮忙顶一下,别忘了 @larrycaiyu ,希望有机会有人能帮我推荐到QConf 2012中去分享,到时我们可以探讨得更多。
这儿再留一个关子,如何建立一个好的C++代码质量检测框架,并且最终和其他java代码质量清晰得显示在一起又是另外一个布道故事了,而且有一些就是因为没有看这本书而得到的一个反面教材。