记一次重构经历（未完）

背景

项目实际生产环境中，经常因为redis缓存数据和数据库数据不一致导致各种问题，归根揭底是因为从db同步数据到redis中这个过程不稳定，容易漏数据。所以每次出现问题就需要根据问题来确认是哪个缓存key数据不一致导致的问题，然后通过页面单条刷新功能进行redis数据同步。
ps：这次重构比较坑，没有业务、产品介绍，只能通过页面功能、代码来反过来弄懂前人的逻辑实现，前人还不止一个，整个过程还是比较痛苦的，做的好了还好，做的不好了，会让领导觉得，别人都已经写好了的东西，让你来改改还能出现各种问题？这么简单的事情，轻轻松松就搞好了。。。
时间紧、事情多。

why 为什么要重构

1. 原有代码大量重复，重复代码黄线一堆
2. 原有代码一个if分支占了一屏幕，常常有3个这种的分支。阅读起来很困难
3. 原有流程有变动：原有流程是：
   1 服务A查询db，将db的数据组装成json，发送到服务B
   2 服务B接收到请求，根据要同步的目标redis（多个redis集群）和操作类型（新增/删除）来进行redis操作
   需要改造成的流程：
   去掉服务B，将服务B中的操作移植到服务A中，直接由服务A来操作redis。

重构的准备

一、前期思考
1、了解整个流程
2、了解每个流程的细节（错误的示范：只挑其中的一个流程进行整理，然后开始编码，提供了一些自认为可以公用的方法，后来处理其他数据同步的时候，发现还有其他的情况，之前的公用方法要么不能用，要么就是需要改造，之前的工作打了折扣。）如果确认了这些业务代码都需要重构，那就把每个流程都理清楚吧，因为早点理清楚了，可以更多的确保自己的前期的一些工作不打折扣，避免做到那里后发现还有其他的情况没有考虑到。一句话：不要急功近利。
3、重构的地方确认，要重构成什么样子？为每个流程提取公用的地方，做成通用的方法
4、为重构的内容定制套路，了解完每个要重构的业务流程后，就要对这些业务做分类，为同一类的业务做制定的模板，这样子做好一个业务模板后，我们就可以相对轻松点的完成同类的其他业务处理。分类做好、结构模板做好，将重构的思路套路化。
二、中期编码
1、根据前期的调研准备，进行编码，如果发现与思考有出入，需要及时解决。
三、后期测试
1、如果时间允许，为每个接口进行一下单元测试，或者针对分类后的典型接口进行单元测试
2、提测，将自己的做的哪些改动、需要重点关注测试的接口尽可能清晰的描述给测试人员。