最近一項工作就是在做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之後界限不明顯, 不想修改的問題. 以後有了迭代還是需要馬上完成, 再進行下一次迭代, 不能一直在耽誤在那裏.