码迷,mamicode.com
首页 > 其他好文 > 详细

记一次重构经历(未完)

时间:2020-06-26 18:41:46      阅读:66      评论:0      收藏:0      [点我收藏+]

标签:完成   删除   代码   数据库   实现   分支   结构   业务流   key   

背景

项目实际生产环境中,经常因为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、提测,将自己的做的哪些改动、需要重点关注测试的接口尽可能清晰的描述给测试人员。

记一次重构经历(未完)

标签:完成   删除   代码   数据库   实现   分支   结构   业务流   key   

原文地址:https://www.cnblogs.com/poorloser/p/13195602.html

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!