代碼最佳實務

標籤：

1:對於不可以為空白的對象,儘早返回,且打出錯誤記錄檔.    a:直觀,易讀,容易尋找錯誤    b:不會往下執行 能節約很多時間效能上的消耗    c:不會引起一些未知性異常 2:對於介面返回 ,還是需要返回原生對象,而不是跟某個協議耦合.   a:按照之前的邏輯使用PB返回,那麼dubbo使用不了,其他的架構也是使用不了的   b:如果把PB傳到service裡面,就會引起了很多跟商務邏輯不相關的一些代碼,比如PB的封裝.就會造成很混亂  c:好處就是PB比較輕,但是因為 我們的service和web幾乎都是區域網路 ,所以不用考慮 加密  和體積大小問題 ,所以不管怎麼樣  還是傳輸java原生對象比較好 3: 對於介面返回CommonResponse,我個人覺得 也還是沒有必要    a:一旦service返回這個CommonResponse,那麼到了controller又要取出來做一些別的顯示轉換功能,這個類似java的封箱和拆箱了   b:對於調用方來說,  根本不能直觀的獲得 CommonResponse裡面的對象到底是什麼,如果嵌套很深的話,更加難找,再如果使用了反射的話,那就更加不知道了 4: 對於介面返回HashMap,我個人認為弊端比較多    a:hashMap返回的值,沒人能清楚地知道 有多少,他們都是什麼意思   b:一旦我們去擷取的時候就會存在 ,寫錯key?    c: 尋找出來為空白的判斷 各自強制類型轉換 ?   d: 5: 對於介面返回List<Object>或者Object,也是有很多弊端的   a:對於介面返回這樣的類型,那麼調用方  看到這個方法應該怎麼辦,怎麼用?   b:這樣的介面類型 ,最好還是應該使用泛型 ,對於自己寫代碼的時候也會儘快發現錯誤. 6:對於介面的返回處理,如果執行成功了,就直接預設成功,不處理, 如果失敗了就會有異常機制往外拋出去   a:之前看到很多介面 ,在每個if else 裡面,如果成功就返回 CommonResponse  Success,其實這個是沒有必要的,比如一百個if else 就寫了一百遍 ，預設成功之後 統一處理   b:而且失敗了 最好不要返回錯誤 ，直接拋出業務異常 ，不然 根本無法定位錯誤  7:對於異常的處理   a:一些不重要的,比如訂單流程 發郵件失敗  可以catch住 ,因為這個不能影響主流程   b:但是對於主流程的異常還是需要一步步往外面拋出去,之前看到很多異常被catch,住了   但是又沒有往外面拋     c:所以現在對於異常得處理，如果是業務異常或者不是必須catch住的就直接拋出去， 如果是那些讀檔案的。就可以先catch住，然後關閉流，再拋出去   d:這樣的異常最後都會到一個統一的出口 。做同一轉換  8：對於多個地方出現的一樣的字串，最好還是同意使用常量來管理    9:對於介面的定義,能一個方法搞定的最好 一個方法搞定  直接傳輸對象進去    a:比如一個修改訂單的狀態,價格,時間等等的方法 就在Service寫了3個. 其實這個應該在controller來控制,不然方法也是會指數層級增長    b: 10：對於商務邏輯複雜的方法，應該盡量抽出小方法，減少if else ， 比如之前訂單的一個方法  300 多行 if  else 裡面夾帶了發簡訊  發郵件  發模板 11： 對於if  else 比較多的業務  不僅僅要獨立小方法  而且要減少if else   比如 訂單的各種狀態  發不同的訊息   我們 可以把他放到統一hashMap 裡面 根據不同狀態擷取不同資訊   且時間複雜度為1 12:有些商務邏輯刪除關聯關係有外部索引鍵關聯,導致刪除不掉.應該拋出業務異常  13：:還是要把核心service寫成一個獨立的方法,不然app和web很難維護 14：pb的轉換寫成功一個單獨的pbConvert. 寫成模板模式比較好理解,而且不容易出錯,能複用  15：工具類最好先統一，多用工具類好維護，bug少 16 最好傳值得時候使用封裝類型，這樣就不會有預設值，如果是空，就是沒有傳。所以在接受前端參數的時候，最好用封裝類型，而在比較大小，或者存redis的key 的時候必須用原始類型 否則 會獲得錯誤的結果   因為封裝類型值相等 但是對象不等 17:最好每個方法還是需要寫一下junit單元測試，這樣會減少bug和以後容易找問題 18;注意一些效能的小最佳化，今天一個改變訂單狀態的介面逾時了，想想應該把發郵件和發簡訊等等的寫成非同步發送 19:代碼裡面盡量減少迴圈，特別是雙重迴圈(現在還有很多3重迴圈)，可以把他放到hashmap裡面。 20:logback看看怎麼最佳化比較好  按照每天的記錄檔  每天又分為info  sql error等等 21:在每個比較關鍵的代碼的執行點，最好都帶一個log，這樣能更好的尋找問題 22:對於check的方法，比如checktoken  最好是只返回true false。如果類型比較多，就返回枚舉類型。或者採用異常機制(各種 返回 1  2  3  4 5 6 簡直看不懂) 23:是否有必要分 bo vo po，dto等等類型轉換vo :這個是web層，請求的參數， 這個對象，專門用來接收參數，以及判斷欄位的正確性dto：這個專門用來做對象傳輸用 ， 因為請求的參數和最終存入資料庫的 是不同的 ，且查詢資料庫出來的時候  還會冗餘很多查詢資訊po：這個專門跟資料庫欄位一一對應， ORM對應存入資料庫的  24:對於分層思想  Service層之間盡量不要去調用別的層的dao   比如 orderService 裡面有userDao，而且controller裡面更加不能調用userDao 25 對於每個介面實現  最後返回 對象  而不是NULL  (effect in java),比如 list   返回一個長度為0的arraylist. 26:能在controller判斷的就儘早返回  減少遠程調用 27:遠程調研可以寫批量介面  28 越簡單的驗證放在前面   這樣後面的驗證可以減少,能儘早返回            

代碼最佳實務