java代碼整潔之道(一)_不斷code review後的感想

序:入職大公司已經有一段時間了,但是小組每次進行code review 都能找出來好多問題,這篇博客主要針對如何寫好一個類一個方法所寫,工程師應該有工匠精神,不斷的對自己的代碼進行優化,往往有意想不到的驚喜,我想這就是工作本身的魅力,願自己心存感恩,不忘初心,做一件事都能細細雕琢。

對一個類和類中方法的優化總結

(1)短路寫法

說道java短路你會想到什麼,短路 && ,短路或 || ,沒錯開發中注意更好的應用他們能提高不少代碼的效率
eg:
(1)當(方法(boolean)1 || 方法(boolean)2)時,返回方法(boolean)1 返回true 的時候,方法(boolean)2 的邏輯是不會執行的

(2)當(方法(boolean)1 &&方法(boolean)2)時,返回方法(boolean)1 返回false的時候,方法(boolean)2 的邏輯是不會執行的

我們這裏說的短路寫法和這個類似

  //業務校驗方法
       User user =  getUser();
       if (user != null){
           //你的業務邏輯
           //你的業務邏輯
           //你的業務邏輯
           //你的業務邏輯
           //你的業務邏輯
           //你的業務邏輯
           String realName = user.getRealName()
           if (realName != null){
               //你的業務邏輯
               //你的業務邏輯
               //你的業務邏輯
               // 成功處理
           }else {
               //失敗處理
           }
       }
       //失敗處理     

能看出來這樣代碼的問題嘛?
(1)多重嵌套,工作中的邏輯常常比這更復雜,,往往過段時間別說其他同事了,自己都不願意看自己的代碼
(2)返回結果不可追溯(到處都有),不能一下子看出理解方法哪裏是正確的結果,哪裏是失敗的結果
這樣代碼如何重寫
首先我們應該梳理我們的業務流程,下圖是我模擬工作的一個流程圖

在這裏插入圖片描述按照上圖的代碼上面的僞代碼優化如下:

//業務校驗方法
       User user =  getUser();
       if (user == null){
           //失敗處理;
       }
       //你的業務邏輯
       //你的業務邏輯
       //你的業務邏輯
       //你的業務邏輯
       //你的業務邏輯
       //你的業務邏輯
       String realName = user.getRealName()
       if (realName = null){
           //失敗處理
       }
        //你的業務邏輯
        //你的業務邏輯
         //你的業務邏輯
        //想要的結果返回

如上代碼,你的業務都是可以寫成私有方法的,而且邏輯都是平行的,這和微服務的設計理念是相符合的(個人見解可以忽略),邏輯平行,邏輯解耦,代碼清晰。


(2)對寫一個業務接口的個人見解

好的業務接口實現邏輯,應該是可配置的,換句話說只要是寫代碼就應該把可配置化這個思維放在首要的思考位置,例子 :你要進行一個用戶操作(比如用戶登錄),其中用到用戶認證(第三方服務),最後更新用戶數據庫操作,這個例子可以參考上面的流程圖

重點: 當你把用戶認證相關的參數拼裝,接口接口調用,返回結果處理等等一系列操作寫在用戶登錄的相關邏輯放在一個方法裏,顯然是不合適的,當然將用戶認證相關的參數拼裝,接口接口調用,返回結果處理等一系列操作 放在一系列操作一起(用戶認證方法)看似是服務 **將各自邏輯放在各自的維度下(用戶認證只做用戶認證)**這樣的做法是合理的,但是最終還是被同事批評了,因爲我們的服務用寫單測,這樣寫第三方調用邏輯,返回結果處理部分的邏輯就落到了第三方獲取透傳層,像我上面的想法最終寫單測的時候,第三方調用層是必須被單測覆蓋到的,所以我最終的處理方法是將最終的第三方處理單獨的寫成一層在對應的用戶service下(一個方法),這樣單測覆蓋用戶service 就好了,下面是我代碼現在的實現思路,歡迎多多指點

在這裏插入圖片描述


(3) 學會模仿,模仿的成本最小,出錯概率也最小

代碼優化,自然隨之的風險,我基本同意一提到優化,上手就幹,也不提倡保持原有能用就是,優化要就行,就必須規避風險,如何有限規避風險那,
我認爲
此處劃重點
(1)首先要讀懂原有代碼,形成自己的思維設計
(2) 自己不懂得,無法確認的東西不要碰,模仿就好
eg: if(result.isSuccess() && result.getCode == CodeEnum.sucess){

}
這樣的代碼不能確認不要動 ,因爲貌似 result.isSuccess(),就能cover的住結果,然而那,你不曉得結果的設計者會不會給你留坑,所以這樣的代碼不要動
(3) 修改或變成,最終的邏輯可靠性,不要用眼看,要用數據說話,正向邏輯,反向邏輯,爲空邏輯 都要測一測

最後一句話:記得對自己的代碼負責,所以一定要細細打磨


要克服生活的焦慮和沮喪,得先學會做自己的主人,學會感恩,學會打磨生活,有問題留言,沒問題留下你的贊
博客聲明:
1.博客內容全是對工作學習的總結。
2.知識點都經過測試和推敲,如有疑問請留言,一定及時解決。

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章