一、为什么重构？

代码不规范，维护成本高，如代码结构混乱，魔法值乱入，子父类功能重复

业务重构导致的代码重构，原有代码已不满足现需功能

代码太复杂，无法调试，也无法将性能优化到可接受的水平

二、什么是重构？

在不改变代码外在行为的前提下对代码做出修改，以改进程序的内部结构。本质上说，重构就是代码写好之后改进它的设计。设计不是一开始就完成的，而实在整个开发过程重逐渐浮现出来，在“构筑-设计”中反复互动

三、如何进行重构？

3.1 明确重构目标

不要为了重构而重构！

重构周期冗长，而且十分繁琐，如果人力不够，可能你会从一开始的雄心壮志变得死气沉沉，中间会出现非常多的问题，我就曾遇到过

明确自己重构的目标，是因为业务重构，还是性能方面的重构。如果是业务重构，一般伴随着修改和新增表，还需使用粘合代码把旧数据导入到新表中。性能方面的重构，可以做代码抽象，sql优化，运行调试函数，并施加一定的缓存，从经验来说，数据库表索引的使用会是重点

3.2 明确重构顺序

大刀阔斧的重构是新手美好的期望，老手选择稳扎稳打，循序渐进的方式。

一个上生产的项目，即便业务功能十分简单，其代码量也很可观，非业务功能的代码比如用户权限、菜单管理、系统监控、日志记录等功能也是非常多的，重新开始写你很可能会遗漏某些代码，因为原本你们的代码结构就比较混乱。

我的经验是先调整代码结构，并测试每一个大功能改动后的代码，然后再进行下一步，直至结构变成你想要的结构。再是重构表以及model，做好关系映射，然后在功能上做修改。

以上工作都做完之后你的业务功能以及代码结构都没问题了，代码的复用性、健壮性、性能方面的调优才刚刚开始：1.合并函数以及类 2.规范函数命名和接口名 3.优化sql及程序代码

在你新的功能全都满足之后，生产的旧数据是不可丢弃的，此时编写粘合代码进行表数据合并测试，并根据业务情况做事务管理，防止合并时间较长跟新产生的数据造成影响。

对每步都做好测试，这个很重要！

3.3 重构详解

根据Java代码规范以及常规技术规范，统一命名常量类，接口名，字段名，禁止不同表同一字段同值不同义，比如is_enable, 可以表示商品上下架状态，不能商品表的is_enable = 0是上架，套餐表的is_enable = 0是下架，造成不必要的误解。见名知意，常量比如状态的常量的可以设置成STATUS_ONLINE = 1, STATUS_OFFLINE = 2等，STATUS前置，采用的是通用的倒叙方式，比如groupId的示例com.example, com.alibaba就是如此，时间字段、状态字段数据库全局统一，比如创建时间采用create_time 还是 created_time均可，保持一致即可，其余的updated_time, created_by, updated_by, is_enable, is_deleted, status等等同理

数据库：使用恰当的数据类型，根据业务使用索引以提高sql执行速度，冗余字段也很方便

禁止魔法值：用Constants类、Code类，枚举类定义异常、常用值、业务常量

代码结构优化：合并可以合并的函数以及类，做到小模块的复用。一般项目都采用MVC架构，已经做好了比较好的分类，但DDD防腐层也有值得借鉴之处，Mybatis-plus框架也可减少操作单表的部分代码文件

对象模型的优化：对于多个类可用到的created_time, updated_time, is_enable，is_deleted，status等字段可以根据业务抽象到BaseModel

注释：合理使用@Api、@ApiModel、@ApiMoldeProperty等注解，swagger等线上文档，毕竟手动写很费时，关键的地方给出注释，防止自己记不住业务逻辑，但好的代码是不需要很多注释的，阅读起来很通畅

做到前面这些，你的代码已经相当优秀了，此时就结束了吗，并没有

缓存的存在就是为了提升效率，减少数据库访问次数，为自己的代码加上缓存，可以提高接口响应速度，我们常见的缓存有Redis缓存，本地Lua缓存，分布式缓存等等，根据项目业务以及对技术的熟悉程度加上缓存，让响应更快吧！

等等，结束了？不会有人不知道Nginx除了反向代理，可以做黑白名单校验，业务处理吧，详情请看我另一篇文章《Nginx核心技术》

项目代码重构核心技术