customer-service项目重构总结

青旅半醒 2022-12-18 15:57 131阅读 0赞

最近一项工作就是在做customer-service的项目重构, 最开始的时候customer-service是crm-service中的一个模块,现在把他拆分出来, crm-service中还包含的木块有resource-serivce, trade-service, sales-service, workflow-service, 都拆分出来, 尽量做到数据库的独立, 因为现在yd\_cloud这个库里面有几百张表了,

首先理清customer-serive项目中涉及到的表, 全部记录下来, 分库的时候一定要注意,是否有其他的项目引用了你当前要分出去的表? 就是left join这样的? 怎么处理? 例如 trade-service中left join 了很多customer\_info这个表, 我如果拆分出去形成一个单独的库, 之前的代码, 只有表名, 没有新的库名, 这个怎么处理? 要考量好, 是使用feign进行查询, 还是跨库查, 怎么选择?

在trade-service中很多,有customer相关的实体类,其实就是复制过去的,然后到处引用,服务的边界不清晰,而且引用的地方太多,也不好改了.目前做了一个把CustomerSearchCondition从trade-service移动到了customer-service中去, 改了很多,  
可以把一些只在当前项目用到的VO移动到当前项目去,不要胡乱的依赖.  
讲道理,骨架项目(-skeleton)是不应该依赖其他的骨架的,但是具体的实现可以依赖于骨架之中.

pom.xml中的依赖,对于一些没有用的依赖,先注释掉,再启动项目,放在测试环境跑一段时间,没有问题再删除掉.

尽量不要去格式化代码,一旦格式化了代码,之前的提交记录就没了.

具体的重构的步骤是(只涉及到customer-service):

0.拆分项目  
1.去掉代码中注释的代码...  
2.清理feign中没有被引用到的方法  
3.清理provider中没有被用到的方法  
4.清理service和dao中没用被用到的方法  
5.清理VO,DTO  
6.清理pom.xml文件  
7.清理各种V2的接口,查询哪些有用,哪些没用.没用的删除  
8.对数据库的表进行清理,标记  
9.使用阿里巴巴的代码扫描对代码进行扫描,按照严重的程度,对一些不规范的代码进行规范化  
10.使用idea的ctrl+shift+o 对java文件中的无效import进行删除处理.

中途一定要记录各种删除,以及修改的记录

总结的教训如下:

1.写代码请写注释, 无效的代码, 请标记@Deprecated,或者直接删除.  
2.代码的统一规范, 如果一个类是VO后面一定要加上VO, 如果是DTO, 大家统一使用DTO 或者 Dto, 格式统一, 枚举中的具体类名字大小写,请统一(默认是大写的)  
3.抛出异常,或者提示,请统一风格,不要有的地方是在

throw new ServiceException("-1","未查询到法人信息记录，请确认！");

有的地方确实:

result.setCode(CommonCode.CODE_201.getCode());
    result.setMessage("文件导入出错！");
    return result;

这样的统一数据格式返回....  
4.严禁在controller中写业务逻辑,都写到service中去, 不然到处的controller中都是复制的相同的代码, 啰嗦的不得了.  
5.按照各个的功能划分,不要把所有的方法都写到了CustomerService接口里面去了,按照功能细分到其他的Service中去.  
6.如果返回空的List,直接Collections.emptyList(),不要用new ArrayList();  
7.判断List是否为空,请用CollectionUtils, 判断String是否为空,请用StringUtils.不要用下面的重复代码;

if (null != vo.getPositionName() && StringUtils.isNotEmpty(vo.getPositionName())) {
    }

8.app的controller和web端的controller混乱.  
9.不要在项目中使用swagger,项目大了,完全是灾难.  
10.请求的url里面, 不要 list\_customermarketproduct  下划线, 大小写, 还有的使用- 横线, 三种风格, 请统一.  
11.请在controller中接收参数的地方把注解加上,方便以后可能出现的版本升级.  
12.如果全部是前后端分离,可以直接把@ResponseBody加上类上,不需要每个方法上加一行.

后记: 2021年1月15日17:34:33

从10月份开始做, 到在1.6号的时候重构的代码终于上了预生产环境, 中间经历了很多很多事情, 这个都没有发上去, 今天突然说有问题, 一些接口少了, 然后就开始找, 是因为在数据库里面配置了一些类名和方法名, 直接去通过system-service直接调用配置的方法返回. 然后就没有找到再代码里面的引用,就发生了方法的误删, 幸运的是, 这样的方法不多, 就临时又把那几个接口方法还原回去了, 就好了. 通过这个事情的教训就是, 以后方法不要随便的删除, 可以标记为@Deprecated , 这样知道当前方法是废弃的就可以了.不要随意删除, 或者先标记为@Deprecated , 再过几个迭代的版本再删除.

再吐槽几句, 在当前迭代之后马上进行了下一个迭代, 造成了代码更新不及时, 代码的冲突很多, 功能的冲突很大, 出现了bug之后界限不明显, 不想修改的问题. 以后有了迭代还是需要马上完成, 再进行下一次迭代, 不能一直在耽误在那里.