#企业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代码质量清晰得显示在一起又是另外一个布道故事了，而且有一些就是因为没有看这本书而得到的一个反面教材。