近期考核項目，代碼走查中存在如下問題：

1、入參使用了Map和Json對象。

　　建議使用對象作為入參，方便后期維護和閱讀

2、直接使用意義不明確的0、1數字作為比較條件

　　建議將意義不明確的數字條件聲明成有意義的應用常量（用final修飾）。

3、直接將super_admin，admin，user等此同類型有含義的字符串用于條件比較。

　　在多次使用相同字符串的時候，容易出現打錯的情況，導致程序錯誤。所以建議將同類型含義的字符串常量用枚舉類聲明，用的時候統一使用枚舉。規避錯誤

4、做分頁的時候，使用類似meetings.subList(0, 10)的方法進行分頁。

　　這樣做，把所有符合條件的數據都查到內存中，結果只是用的一部分，造成資源浪費。建議把分頁查詢放在數據庫查詢時盡可能的減少數據庫服務器的IO,合理使用數據庫資源，有利于應用的平穩運行。

5、過多的地方重復使用相同的注解。

　　嚴重的代碼冗余，可以把注解統一標注在類頭或者通過配置文件統一配置。

6、日志打印記錄較少。

　　不要使用System.out.println();的打印輸出方式。然后在關鍵之出，或者覺得容易出錯的地方適當增加日志記錄，方便錯誤排查。

7、異常打印時避免使用e.printStackTrace()

　　a.建議使用log.error("異常",e);

　　b.對不確定的代碼應加上try-catch，捕獲，并處理潛在異常，做好日志打印處理，為錯誤排除提供幫助。

　　c.具體如何處理異常應該根據不同的業務需求和異常類型去處理。

• • • String getMessage（）；獲取異常的詳細信息
    • Sting getLocallizedMessage（）；獲取用本地語言描述的詳細信息
    • Sting toString（）；返回對異常的一個簡短的描述
    • void printStackTrace（）；打印出異常和他調用棧信息到標準的錯誤流中
    • getClass（）；返回一個表示這個對象屬于哪種類型的對象

8、對于文件存儲路徑等常量信息不應該寫死在代碼中。

　　應該寫成配置文件，然后通過配置文件的形式方便維護，更方便實施部署。

總結：

　　通過本次項目暴露出的問題，可以看出代碼結構不夠嚴謹，命名不夠規范，工具類的使用不夠嫻熟（用的少）等問題。代碼可擴展性差，會對后面的維護和擴展造成更高的時間成本，所以在編碼前應該先考慮好是否符合業務場景，是否可行，這種編碼方式是否合理。多想多問多討論。還要多使用和熟悉單元測試，提高接口健壯性，增強對日志打印顆粒讀的把握，減少錯誤排查的時間，少走彎路。

?

轉載于:https://www.cnblogs.com/caijh/p/8457702.html

總結

以上是生活随笔為你收集整理的代码走查整理总结的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。