【转】遗留系统重构案例

背景和问题

 

在客户咨询过程的时候，客户的小安正好在做一个升级工具的重构，后来他找到我（钱安川），希望顾问能够指导一下。我简单了解了一下10万行以下C++代码，听起来业务流程也比较清晰，所以我就答应了，准备带着大家一显身手。

我用了2天了解业务，3天了解了代码框架，发现升级工具面临的问题比我想象的复杂得多：

• 代码混乱，到处都是全局数据和静态类
• 升级业务流程比较简单，但是硬编码了很多批量操作和异步时间控制
• 代码中有很多的hack，导致到处是坑和地雷（我们后面的升级工具开发证明了这一点）
• VC6的环境，没有测试框架支持

除了升级工具的问题之外，升级工具主开发人员小安，有根深蒂固的面向过程开发经验，没有任何面向对象开发经验，排斥面向对象。他所谓的重构就是只要把大函数变成小函数，把大类拆成小类就完成重构了。

面对这种现状，我发现这不仅仅只是一个简单重构的问题。如果要完全重构好升级工具，必须要重写基础架构，也就等于说重新把升级工具重做一遍。这必须要立项，是一个大项目，因为大家的技术水平都比较差，所以风险也很大。所以，我毅然的决定放弃重构升级工具这个目标。我的思路转变为更多地是把人能力培养出来，顾问可以提意见，给出解决方案，但重构本身不是顾问的工作。

于是我们就把重构范围缩小在:

一个升级工具的
一个加载功能的
一个CodeSever模块的
一个类CServerLoadMng的
一个叫MakeMmlCmdLine的函数

目标是提升大家用TDD方法重构遗留系统的能力。

重构方法

1. 梳理业务流程
2. 识别痛点
1)报文处理 2) 执行时间 3) 任务控制和中断 。。。
3. 识别业务领域对象
4. 引入测试框架
5. 指导种子重构。有两个开发人员一起结对，进行重构开发。我会做在旁边指导，先保证代码可以工作，然后提出建议，让他们重构

大概2周左右，重构任务结束了。之后我还总结了一篇文章：如何收拾我们的客厅——遗留系统的重构。

经验和教训

• 学会放弃。我及时的放弃了重构整个工具的想法，后来证明是很明智的。因为如果遗留系统的架构有问题，如果要重构，就等于把系统再写一遍。这样是有很多的工作量和风险的。这不是顾问的工作范畴。顾问更多是把自己的方法和经验教导给大家。具体的事情，必须由大家来做。
• 重构有风险，工作需谨慎。我们把重构缩小在一个很小的范围，就是一个MakeMmlCmdLine的函数。新的代码放在一个独立的类文件，这样和遗留系统很好的隔离开，并且测试更方便。