代码重构实践之复用改造

怎样识别哪些地方需要重构代码？个人觉得应该有两个层次。

第一个层次是直观感觉。例如当你看到很多相似的代码时，肯定是代码的复用没有做好，应该从加强代码复用；当你看到很多全局变量，应该是数据的隐蔽性没有做好，应该需要加强数据隐蔽性；当你看到没有使用类，而是结构体，应该需要加强类的使用频率，因为这样才会对于继承、数据保护、多态、设计模式等高阶的应用开发思想进行更大力度的重构。

第二个层次是主观分析。这个层次需要对面向对象思想和编程实践有比较充分的实践，对于经验不足的人，可能重构的效果会差异很大。但是我觉得即使这方面经验不足的人，也不能看到像一坨乱麻的代码，而无动于衷。要敢于实践，有一种对待写代码就像写制作一部工艺品一样，具有精雕细琢和锲而不舍的精神。

首先我从第一次层次的代码复用性开始。说起代码的复用性，可能大家都很熟悉，那不就是把相同的功能模块或者函数进行封装，在具有类似的处理中进行调用嘛。其实这只能是表面现象。我们一般编程实践中，都会有一个Utility的模块或者函数，这就是将公共的基础函数或者类提供给外部使用，这已经具有一定的分层思想了。

如果像我现在面临的代码，基本面向过程的代码。想要提高代码的复用性，首先要进行面向对象改造，因为面向过程的代码，其实很多都是在操作结构体内部的成员。例如：

结构体初始化--》采用赋值构造的改造

数据拷贝--》采用构造拷贝、重载赋值操作符、定义拷贝接口等进行改造

成员内存管理--》采用构造时申请内存、析构时释放内存的改造

列表成员的添加、删除、更新、查询操作--》采用类的外部接口、封装自定义的模板容器等改造

这些都是对数据管理进行的重构，但是代码的复用中，我们可能还会涉及到业务逻辑代码的复用。往往这些业务逻辑的代码比较大，但是没有关系，我们要分析业务逻辑各个子逻辑，越细越好。可以采用树形分析方法，从软件的系统、子系统、模块、子模块、类、子类、接口、私有方法层层分解，寻找相同功能子节点，合并子节点，这些剩下的“叶子”就是基础的类或者函数。

在重构过程中，会存在不断“反复”的情况。因为重构首先要保证旧功能不能收到任何“影响”，重构的力度要适当把握，否则会造成无法收拾或者废弃重来的局面。因此，重构时先尽量理解之前的代码，从最小的粒度开始，甚至为了保证不影响旧功能，可以先创建新的类，局部地、步骤地替代之前的结构体或者功能函数。并且在重构完成后，需要加强自测。

好了，这些就是我对代码复用的一些想法和实践。文章中只是提到一些思想，至于如何实践，其实是因人而异，因项目而异的。我也不想把具体的重构代码贴上来，因为这会涉及到公司的隐私，也没有必要。

下一篇，我将说说软件分层的重要性，敬请关注。