有一種習慣，叫看代碼找問題；有另一種習慣，叫不看代碼很不習慣。
這，矛盾，處處不在！
review代碼（code diff升級）到底可以做些什么？該做些什么？
1、整體代碼風格是否貼切已有框架的設計風格
一個系統本有一套體系，你就不按這個走？前人踏過無數的坑，你就要去踩？
2、注釋
別人問，這定義的什么？回答：忘了
別人問，這個是干嘛的？回答：忘了
！！！！！！
3、入參的定義，出參定義（特別是枚舉）
考慮某個入參是否以前已有定義？是否其他系統已有定義？是否數據庫已有定義？
本部門內各系統，同一含義的參數最好（應該強制）都統一，不然系統與系統之間交互要轉來轉去，與數據庫交互要轉來轉去。
4、日志打印
a、前端入參、或接受其他系統調用的入參必須打印；
b、調用依賴服務入參、出參必須打印；
c、捕獲的未處理異常堆棧信息必須打印；
d、捕獲的處理異常打印的信息必須明確問題所在；
e、日志級別得明確
5、異常處理
a、異常類型定義必須明確，不能一股腦拋系統異常；
b、調用第三方服務，最好單獨包一層try catch（不單單是整個外部方法的異常捕獲）；
c、。。。。。。
6、埋點統計
我要用戶訪問量！
我要異常訪問量！
我要今天多少用戶干嘛干嘛的量！
7、報警機制
調用第三方出問題了，自己不知道；
別人要服務大概響應時間，自己不知道；
自己服務有問題了，自己不知道；
多么尷尬的事！
8、業務實現
a、了解清楚需求了嗎？
b、這設計方案講得通嗎？
c、依賴服務文檔看沒？
d、聯調過沒？交互流數據確定過沒？
e、在什么環境聯調？本地也叫聯調？
f、表設計合理？索引創建合理？
g、增刪改sql沒問題？
h、簡單的參數check完善？
i、完全信賴別人的傳入？
j、穿插的不是很重要的消息推送做了無傷大雅處理？
k、能異步處理的開了新線程？開的新線程有效？
l、 。。。。。。