关于重构-献给所有为老系统擦屁股的同学

最近重构了很多老系统，在程序员眼里有‘坏味道’的老项目，发现好系统优点都是一致的，坏系统各有各的问题，今天我们就着重聊一下系统的重构，也是对自己近阶段工作的总结。

 

1 为什么要重构系统

重构系统的原因对程序员来说，无怪于一下几点

(1) 谁写的系统啊，这么垃圾，看着都烦哎，

(2) 自己写的系统，被PM催着上线，只好先以直线式的思维设计，先写好上线，但久而久之，发现系统好烂啊，怕后面接手的人骂我（看第一条）

(3) BOSS瞅了你一眼,说：”这是你写的系统啊！”。

开个玩笑！

相信是程序员都会遇到上面的问题。上面也只是说了表象，真正一个项目需要重构的原因，无怪于两点。

(1) 功能模块划分乱，各种功能纠结在一起，看个逻辑看半天都看不懂；或者多次copy代码修修改改，修改功能要一个类一个类排查，一个功能分散在多个地方，一改改一坨。

(2) 代码效率低下

运行效率低下：运行太慢

实现效率低下：10行代码搞定的事情写了100行

 

2重构项目的形式有哪一些

下面我们来说一下重构代码的形式

(1) 整个系统模块划分不清楚，生搬硬套了一套模块系统上去（典型的就是将三层架构硬配套到所有应用程序中，我三层架构是无敌的），一般在错误的架构方向下，类的职责划分会非常纠结，以至于类的功能划分也是纷乱嘈杂的。

这时候需要重新设计架构，理清模块职责，花费时间较长

(2) 类及方法的职责划分不清楚，类或方法即具有职责A，也具有职责B（笔者就发现过一个1000行的方法！，6000行的类）或者一个功能在类或方法1和类或方法2中都是存在的等等等等

这个时候需要从中抽象出各个不同的功能点，单独进行设计。

(3) 方法效率低下

这个我总觉得它是属于代码优化的范畴，是最小的一种重构。

(4) 现有架构无法满足程序效率的需要，需要重新设计。

这种重构比较特殊，大部分是由于老系统的技术架构不能满足现在的效率需求，需要重新选择技术架构，让系统提升处理能力。这种我们暂且不表。

 

每一个项目都有它自己所独特的缺点，做重构前需要先看明白它的缺点属于哪种类型，然后再进行重构的设计。

 

3重构的步骤：

(1) 发现缺点，制定方案

想要重构需要先确定你重构的级别，是整个项目模块不清，还是某几个类和方法惹人讨厌，或者，更小的，我想把这个方法的300行代码用30行代码搞定。

这里就必须要说一下模块的划分了。

模块是为了实现某一个功能的类的集合。

模块有大有小，有底层模块，有上层模块，不管他们的区别是什么，模块中的类，都是为某一个特定的功能而写。与本模块功能无关的类，不应该放到此模块中。

很抽象是吧，相同功能，谁不知道呢，那我们说些具体的，怎样划分模块

抽象，还是抽象。

抽象的过程，便是一个找到事物共同点的过程，这是一个仁者见仁，智者见智的事情，就比如有一堆球，有红的，有黄的，有足球，有网球，有的人按照红的黄的分，有的人按照足球网球分，都是说的通的。

那究竟谁对呢？

按照以后对修改最有利的情况分

比如我写一个数据请求分发，然后将得到的数据吐出的系统，下面有多个数据源，每个数据源请求方式是不一致的，请求结果返回的方式也是不一致的，有同步，有异步，有直接登录FTP取等等等等，后续还要接多个数据源，那么这时候的模块划分就应该以数据源的角度来划分。

但是如果是相同的系统，数据的请求，返回，处理都是一致的流程，后面也许需要加进一步的数据处理，筛选流程，那么就应该以数据处理流程中的阶段来划分模块，

 

最后说一说层

我认为层是模块划分的副产品，模块划分清楚了，层本身就出来了，底层模块组成底层，高层模块组成高层，所以不需要刻意的划分层次，划分模块就可以了。

 

重构方案的选择

如果是比较小的重构，修改方法代码什么的，改完，做好单元测试，功能测试就可以了。

如果是比较大的，就需要慎重了，保证线上代码良好运行，又要大范围重构，确实是一个技术活。

这里说一种方法，整体模块划分好了之后，先写底层模块，然后按照功能，一个功能点一个功能点将现有逻辑切换到新的底层模块，然后逐步向上重构，最终将所有功能点的代码全部替换掉，重构完成。

这里说的功能点是对外的功能，这样能保证在完成之后，能够非常快速的进行功能点的回归测试，防止功能点漏测的情况。

在这里要说的是，千万不要好大喜功，一次吃个胖子，全盘重构后上线，笔者就因为这样的一次重构，吃了一次亏。

 

(2) 打代码

这就不说了

 

(3) 测试，测试，测试

理想是丰满的，现实是骨感的。大规模重构不出几个故障，怎么好意思呢！
玩笑话哈。

但一定要记住，重构是一项有风险的运动，搞不好，会出故障的！！！

所以，后面测试非常重要，必须要经过充分测试后才能上线，切记切记。这也是上面让大家一个功能点一个功能点进行重构的原因，因为后面好测试啊。

 

PS：关于重构，重新架构，重写等等。

有一位原同事有一天问了我这样一个问题，重构，重写等等好多重的名词，每个词都代表一种优化代码的方式。

其实我个人并不太在意这些名词上的区别，我所讲的,并且追求的是如何将老系统进行优化，以达到心目中的赏心悦目，我给它起了个名词，叫重构罢了。

个人看法^_^