代碼走查具體考察點
一、參數檢驗
- 公共方法都要做參數的校驗，參數校驗不通過，需要明確拋出異常或對應響應碼。
- 在接口中也明確使用驗證注解修飾參數和返回值，作為一種協議要求調用方按注解約束傳參，返回值驗證注解約束提供方按注解要求返回結果。
二、魔法數字（幻數）
在代碼中要杜絕幻數，幻數可定義為枚舉或常量以增強其可讀性。
三、空指針檢驗
- 不確定返回集合是否可為空時，要先做非空判斷，再做for循環。
- 盡量返回空對象，或者空集合，而不是null。
- 判斷字符串為空時，先判斷是否為空，再判斷是否空串，最好將其提出公共方法。
- 使用a.equal(b)時，把常量放在左邊。
四、下標越界
如果方法傳入數組下標作為參數，要在一開始就做下標越界的校驗，避免下標越界異常。
五、重復代碼檢驗
不允許寫重復代碼（四行左右重復計算重復代碼），重復代碼要使用重構工具提取重構。
六、命名規范
- 包、類、方法、字段、變量、常量的命名要遵循規范。
- 命令要名副其實，一方面增加可讀性，另一方面促使我們在起名的過程中思考方法、變量、類的職責是否合適。
- 盡量不要在循環中調用服務，不要在循環中做數據庫等跨網絡操作。
- 循環或者遞歸，要注意其是否一定包含了停止循環/遞歸的條件。
- 盡量避免while(true)，一定要寫的話，循環開始要加一個sleep，這樣避免一上來就異常，跑死CPU。
七、注意循環
八、關心頻率
寫每一個方法時都要關心這個方法的調用頻率，一天多少，一分多少，一秒多少，峰值可能達到多少，調用頻率高的一定要考慮性能指標，考慮是否會打垮數據庫、緩存等。
九、差錯控制
- 避免過大的 try 塊，不要把不會出現異常的代碼放到 try 塊里面，盡量保持一個 try 塊對應一個或多個異常。
- 細化異常的類型，不要不管什么類型的異常都寫成 Excetpion。
- catch 塊盡量保持一個塊捕獲一類異常，不要忽略捕獲的異常，捕獲到后要么處理，要么重新拋出新類型的異常。
- 方法內部，不要把自己能處理的異常拋給別人。
- 不要用 try...catch 參與控制程序流程，異常控制的根本目的是處理程序的非正常情況。
十、關於長度
如果一行代碼過長，要分解開來；如果一個方法過長，要重構方法；如果一個類過長要考慮拆分類
十一、外部依賴的性能
如果調用了外部依賴，要搞清楚這個外部依賴可以提供的性能指標，考量其是否能夠提供符合我們使用場景的服務。
十二、避免重復造輪子
不要重復造輪子，如果已經有成熟類庫實現了類似功能，要優先使用成熟類庫的方法，這是因為成熟類庫中的方法都經過很多人的測試驗證，已經非常可靠了。
十三、注意多線程
多線程環境中，要注意數據的原子性與可見性等線程安全問題，最典型的HashMap，SimpleDateFormat，ArrayList是非線程安全的，另外如果使用Spring自動掃描服務，那么這個服務默認是單例，其內部成員是多個線程共享的，如果直接用成員變量是有線程不安全的。
十四、日志打印
- 打印日志要設定合理的日志級別。
- 生成長字符串的toString()時，通過日志級別和if語句達到控制打印量的目的。原因是，長字符傳拼接會占用很多gc年輕代內存。
- 要通過log4j打印日志而不是直接把日志打印到控制台。
十五、方法實現的簡潔
這個無法說的太細，總之是不要啰里啰嗦的寫代碼，具體問題要具體分析。
十六、正向依賴
不能讓底層模塊依賴於上層模塊；不能讓數據層依賴於服務層；也不能讓服務層依賴於UI層；更不能在模塊之間形成循環依賴關系。
十七、分治
分而治之，復雜的問題要分解成幾個相對簡單的問題來解決，首先要分析出核心問題，然后分析出核心的入參是什么，結果是什么，入參通過幾步變化可以得出結果。（該條與第十條：關於長度，有一定的重合）
十八、代碼健壯性意識
該條是前面幾條的整合，比較綜合。考慮各種邊界條件（例如第四條下標越界、用戶輸入數據超出最大值等）、處理失敗或出異常的方法（參考第九條、差錯控制）、校驗入參和返回值（參考第一條參數校驗）