标签:完成 删除 代码 数据库 实现 分支 结构 业务流 key
项目实际生产环境中,经常因为redis缓存数据和数据库数据不一致导致各种问题,归根揭底是因为从db同步数据到redis中这个过程不稳定,容易漏数据。所以每次出现问题就需要根据问题来确认是哪个缓存key数据不一致导致的问题,然后通过页面单条刷新功能进行redis数据同步。
ps:这次重构比较坑,没有业务、产品介绍,只能通过页面功能、代码来反过来弄懂前人的逻辑实现,前人还不止一个??,整个过程还是比较痛苦的,做的好了还好,做的不好了,会让领导觉得,别人都已经写好了的东西,让你来改改还能出现各种问题?这么简单的事情,轻轻松松就搞好了。。。
时间紧、事情多。
一、前期思考
1、了解整个流程
2、了解每个流程的细节(错误的示范:只挑其中的一个流程进行整理,然后开始编码,提供了一些自认为可以公用的方法,后来处理其他数据同步的时候,发现还有其他的情况,之前的公用方法要么不能用,要么就是需要改造,之前的工作打了折扣。)如果确认了这些业务代码都需要重构,那就把每个流程都理清楚吧,因为早点理清楚了,可以更多的确保自己的前期的一些工作不打折扣,避免做到那里后发现还有其他的情况没有考虑到。一句话:不要急功近利。
3、重构的地方确认,要重构成什么样子?为每个流程提取公用的地方,做成通用的方法
4、为重构的内容定制套路,了解完每个要重构的业务流程后,就要对这些业务做分类,为同一类的业务做制定的模板,这样子做好一个业务模板后,我们就可以相对轻松点的完成同类的其他业务处理。分类做好、结构模板做好,将重构的思路套路化。
二、中期编码
1、根据前期的调研准备,进行编码,如果发现与思考有出入,需要及时解决。
三、后期测试
1、如果时间允许,为每个接口进行一下单元测试,或者针对分类后的典型接口进行单元测试
2、提测,将自己的做的哪些改动、需要重点关注测试的接口尽可能清晰的描述给测试人员。
标签:完成 删除 代码 数据库 实现 分支 结构 业务流 key
原文地址:https://www.cnblogs.com/poorloser/p/13195602.html