上一篇已经阐述了重构的思路和方法，这里主要阐述下里面提到的重构计划。
首先，了解一个待重构的老项目
项目名称A，某公司重点项目，已经正式上线运行几年了，公司业务遍布全球，很多国家都有办事处或研发部门，也就需要使用该系统。并且随着公司的不断发展，业务流程也在不断地完善和变化。
技术上，项目是CS架构的，支持在线和离线两种操作方式，对于在线方式，数据访问是直连服务器上的Oracle数据库，离线的数据访问是连接本地的Access数据库；对于本地数据库，系统提供WebService来实现本地数据的同步。
目前项目代码的规模已经达到100多万行，负责项目开发和维护是由同一个团对来承担，其中的开发和设计人员有10人，这些是项目的基本情况。
项目存在的问题：
1、维护工作量很大，这占用了差不多40%左右的时间，这主要是因为易用性差造成的，不过由于在以前的代码中把太多的逻辑放在UI层上，在业务复杂和界面都复杂的情况下根本不敢去修改，这就导致无法改善易用性。
2、开发BUG很难减少，特别是做一些变更任务的时候，往往简单的修改会牵涉出很多BUG，这是由于项目代码混乱，复制的代码随处可见，导致变更分析很难做到全面。
3、代码复用度低，导致每个版本的开发时间都比较长，而且，每次的版本开发都导致代码规模的暴增。
4、从业务上说项目已经成熟，公司希望将项目产品化起来，并且在内部真正实现组件化（根据业务模块来划分模块，并像搭具木一块快速的组合与拆分）的架构方式。
现有架构：
项目在架构上根据业务划分成了几个子模块，下面是提取出来的三个模块，同时也表示出了模块之间的关系。
在每个子模块中根据传统的三层模式来划分，不过层之间业务数据的体现都是以DataTable为核心。
了解完上述这些后，不知道大家都有什么想法？反正对于我来说，这个过程现在想想都郁闷，从进入项目开始算起，花了三个月的时间才提出了最终的重构计划！
1、在存在的问题、现有的架构、重构时间（1个半月的开发时间）和项目风险几方面的综合考虑制定了新的架构
（看到上面这幅图后，有些人可能会坐不住了，觉得很平常化，没有任何高深或有新意的东西，就连基本的设计原则还都不符合，为什么不加入设计模式，例如：层次之间的利用接口隔离，数据操作类上可以使用工厂模式等等，其实这些并不是没有想过，去掉的理由很简单：初步重构老项目不要去理想化，它的首要目的是解决现有存在的问题，对于理想化的东西我们放到以后的持续重构中去实现。）
2、选择重构的代码，100多万的代码不可能在一个半月内都完成重构，所以如何选择是个很重要的事情，上面三个模块中，销售模块的使用度最高，其中用户的问题反馈基本占了80%，代码规模处于平均阶段，综合这些考虑选择这块进行重构。那么其他模块怎么办？！采用当后期模块内有需求变更的时候，对于变更的内容采用新的架构来做，这样一步一步地达到目标。
3、对选择模块的UI层，让BA、UI工程师和用户重新设计界面流程。
4、对模块内部代码的变动制定详细的执行步骤，例如：先从业务层开始在类中新增对象属性和相关方法，接着利用属性消除DataTable，最后抽出UI层的业务规则等，并且要清楚工作之间的依赖程度，要做出串行和并行的任务，例如：上述步骤是需要串行的，而基础组件模块的重构是可以并行的，这样做是保证你对整个重构过程有很好的控制。
5、接下来进入实质的编码阶段了。有个注意的地方，最好安排两个设计人员每天对修改的代码进行代码走查，以确保明天不要重构今天的代码。
就这样团队整整辛苦了一个半月后，终于完成了重构！虽然现在的代码依然存在很多问题，但是至少我们让一直困扰的问题消失了，也许又会出现新的问题，为了避免这种情况，引入了敏捷开发中的过程-对于每个版本的持续重构！
