review代碼，須要作些什麼？？？

 

有一種習慣，叫看代碼找問題；有另外一種習慣，叫不看代碼很不習慣。

這，矛盾，到處不在！

 

review代碼（code diff升級）到底能夠作些什麼？該作些什麼？

一、總體代碼風格是否貼切已有框架的設計風格

　　一個系統本有一套體系，你就不按這個走？前人踏過無數的坑，你就要去踩？

二、註釋

　　別人問，這定義的什麼？回答：忘了

　　別人問，這個是幹嗎的？回答：忘了

　　！！！！！！

三、入參的定義，出參定義（特別是枚舉）

　　考慮某個入參是否之前已有定義？是否其餘系統已有定義？是否數據庫已有定義？

　　本部門內各系統，同一含義的參數最好（應該強制）都統一，否則系統與系統之間交互要轉來轉去，與數據庫交互要轉來轉去。

四、日誌打印

　　a、前端入參、或接受其餘系統調用的入參必須打印；

　　b、調用依賴服務入參、出參必須打印；

　　c、捕獲的未處理異常堆棧信息必須打印；

　　d、捕獲的處理異常打印的信息必須明確問題所在；

　　e、日誌級別得明確

五、異常處理

　　a、異常類型定義必須明確，不能一股腦拋系統異常；

　　b、調用第三方服務，最好單獨包一層try catch（不僅僅是整個外部方法的異常捕獲）；

　　c、。。。。。。

六、埋點統計

　　我要用戶訪問量！

　　我要異常訪問量！

　　我要今天多少用戶幹嗎幹嗎的量！

七、報警機制

　　調用第三方出問題了，本身不知道；

　　別人要服務大概響應時間，本身不知道；

　　本身服務有問題了，本身不知道；

　　多麼尷尬的事！

八、業務實現

　　a、瞭解清楚需求了嗎？

　　b、這設計方案講得通嗎？

　　c、依賴服務文檔看沒？

　　d、聯調過沒？交互流數據肯定過沒？

　　e、在什麼環境聯調？本地也叫聯調？

　　f、表設計合理？索引建立合理？

　　g、增刪改sql沒問題？

　　h、簡單的參數check完善？

　　i、徹底信賴別人的傳入？

　　j、穿插的不是很重要的消息推送作了無傷大雅處理？

　　k、能異步處理的開了新線程？開的新線程有效？

　　l、　。。。。。。