超大规模IT软件项目重构经验与实践

大东家 xiaohelong2005@126.com

1.为什么要重构？

一个项目需要重构，一般情况是因为这个项目可维护性差，或者其功能要扩展已无法适应当下的需要。一方比如，支持新的模型扩展；另一方面，面对云化时代，无法从单机升级至并行抑或是分布式云计算支持。

而我们碰到的就是这样一个程序，程序以VC6+MFC构建，代码规模在100多万行至200万行之间，单机程序，根据功能不同分为不同功能方向的子软件构成。站在这个工程所处的时代而言，客观来讲，程序架构设计合理，结构清晰，但这个当时的模式主流更多的是C++模式的应用，而无法站在应用或者模块化的角度进行组织；另一层面，由于程序在数据量大规模模拟时，出于对运行效率和规模的当下需求，原有架构模式必须模块化、并行化方能支持当下业务扩展；第三个层面，代码过于老旧，用的组件已然找不到资料，特别是数据等；第四个层面，代码的注释极少，只有一个固定的作者对其代码类做了解释，再一个就是基本上没有文档（注：在进行了较长一段时间后，拿了一些帮助手册等，对概念理解层面有一定帮助；最后一个层面，代码已经经历了较长时间的更改（包括界面翻译），中间也几经转手易人，这在概念的统一以及可以确定性的标准方面，对我们造成了一定的影响。

2.重构准备工作

面对一堆代码，从Java习惯转到C++习惯光从语言上切换，就需要克服内心恐惧。面前这一堆代码，就如处于浓雾中，思绪万千，不知从何下手，内心感觉到一阵恐惧。但是我有信心，有能力搞定他，正如以前经历过的几个大项目（与本项目不同）一样，凭借着自我的肯定与坚定的信心，这就开干了(注：在这个方面，过往吹过的牛都实现了，只是容易白头发)。

另外，这是一个全新的领域，需要在较短时间内，补充专业名词、系统原理等概念进行全方位的学习理解，下了几本专业领域的书籍与相关论文，不得不说明的是，在这种压力下的学习真的很有效率。

人力构成主要有开发团队，以及专家团队，虽然我们对工程实施很有经验也有自信，但相应的专业领域，这些特定行业内的顶级专家团队对我们最后的成功起到了决定性作用。当然，这个过程，也是需要磨合成本的。

虽然成功是必然的，但不得不承认，成功也是有偶尔，这个偶尔就在于团队！（相对抽象，但仔细来讲，就是这一整个TEAM的整体输出能力，工作协调能力，通俗的讲，就如结婚，两口子搭的话，幸福一生；如果不搭，痛不欲生。）。所以，很庆幸，这样一个班子达到当前的效果，有如当前做订单可视化一般感同身受。

有了信心，有了自我肯定，有了一个金牌TEAM，这就硬着头皮上了。自顶向下，梳理项目代码依纯关系、梳理类的继承关系，找到对象的相互引用（调用）的关系图，绘制出项目依赖包的关系、定位出被引用最多的函数和类，这一切磨难，在忐忑中前行。

3.压力与机会，核心路线探索

最初想将VC6的工程放到VS2019上编译，以方便调试，但出于对C++工程的熟悉程序，几经尝试均没有效果，只能保持现状，用VC6进行编译调试，用VS2019进行代码阅读与定位（这个问题，在后面团队对代码熟悉后，由C++经验多工程师重组了工程文件得以解决）。

3.1. 第一次尝试

这个时段，对相关概念已不再像最初那么陌生，出于项目本身是可以执行的，想通过直接将原有代码进行打包对外提供API的模式。通过一定时间的尝试，这种方式无法应对写API对内部状态的控制，也无法做到并行处理；当然，如果只是读，不需要改变状态，这种办法就是可行的，因此只能另谋他路。

此时，时间已用到三个月，离任务目标时间仅剩7个月。

​​​​​​​3.2. 第二次尝试

此时就得反思，该如何切入？？？

还好，当我事有所思时，我一般在入睡前思考了几天（这也不好，激动处，易致失眠），终于确定了核心思路。即基于原有软件可以运行的模式，通过原有软件生成可以打通流程的文档，用这个文档驱动整个研发、测试以及结果校验流程，抓住核心要点，去掉复杂度，等核心流程打通，确定可行性以及可并行研发时，再通过加人和版本迭代方式快速大面积铺开。对，就这么干(失眠了，唉)。

如何下手呢？嗯，团队相当给力，通过这个文档将代码业务梳理了一遍，对，就是湖南人的精神霸蛮一行一行打日志，打断点，终于相流程相关的业务代码、关键事件与活动梳理出来了。对，这就是业务驱动开发，只能这样，才能从迷雾中寻找到可以冲出来的路线。这一步走对了！！！

这一下，此刻又面临一个决策问题，如何最快的方式移植代码。可以做的选择有：

一、通过自己对业务的理解，重新做架构，只从原有代码中搬移核心融合算法；

二、通过对原有系统类的梳理，通过压缩层级和模块化拆分最小程度改动代码，最大程度利用原有代码，同时兼顾了架构。

考虑到第一种方式，最后即使移植成功，担心结果不被专家团认可，所以就倾向于第二种模式（第二种模式，中间也挫折，傻乎乎的尝试改变原有命名方式，后面回归到尽最大程度不改折腾了一个月）。时间一天一天过去，直到有一天和专家团进行了“和平友好的、激烈的、口干舌燥的意见交流”闭门会议，达成了采取第一种方式（这个我个人也是最初想选的，只是团队内部讨论担心结果不认同，所以没选择，即这么激烈、友好的又甲方爸爸认可这种结果，那不正合我意么）。

此时，时间还剩下三个月（加上下一年的一个月，共四个月，这个时间点，团队成员的理想人选还在寻寻觅觅中，实话实说，大家心里慌得一P）

​​​​​​​3.3. 第三次尝试

通过理想人员的加持，路线的多方认同，前面虽然走了弯路，但也看了更多的风景，有更多的经验，信心倍增，但时间却很紧。

唯有牺牲多壮志，敢叫日月换新天。此刻的弟兄们，心中有梦想，眼中有亮光，对，干就完了，一天当两天用。

虽然还有一堆TODO，但流程已然贯通，靴子落地，这一刻，兄弟们激动了。我猜专家团也跟我们一样，会很激动地拭一湿润的眼眶。

4. 写在最后

对于具备挑战的未知事件，如 果不能退缩的情况下，干就完了，管他。

成功，更多的是一种偶然事件；但成功只要坚定信念，秉持着不服就干的精神又会成为一种必然事件。

一个困难的事情，要搞定它需要有坚定的信心，吃苦耐劳的定图片，相互协调的团队以及资源的支持，这几个要素缺一不可。

回到本次大规模C++代码工程上来说，核心思想是业务驱动的模式，通过极限编程，业务版本迭代，前期以流程贯通为目的进行。自顶向下业务理解，自下而上实施相结合的模式进行。