Kevin-moon

学习在于分享
  博客园  :: 首页  :: 新随笔  :: 联系 :: 订阅 订阅  :: 管理

如何重构代码-重构计划

Posted on 2010-05-10 23:09  Kevin-moon  阅读(21054)  评论(15编辑  收藏

  上一篇已经阐述了重构的思路和方法,这里主要阐述下里面提到的重构计划。

    首先,了解一个待重构的老项目


    项目名称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、接下来进入实质的编码阶段了。有个注意的地方,最好安排两个设计人员每天对修改的代码进行代码走查,以确保明天不要重构今天的代码。

 

     就这样团队整整辛苦了一个半月后,终于完成了重构!虽然现在的代码依然存在很多问题,但是至少我们让一直困扰的问题消失了,也许又会出现新的问题,为了避免这种情况,引入了敏捷开发中的过程-对于每个版本的持续重构!