論代碼走查的重要性

　　在一個團隊中, 若是沒有code review, 直接容許開發提交代碼到版本庫並部署環境, 那麼在正式開始測試以前的代碼走查就很是有必要了。

　　這裏說的走查不是使用工具在持續化集成以前進行代碼規範的檢查, 而是根據PRD文檔, 驗證代碼的實現是否符合需求描述。

　　在開始測試以前我都會先同步開發的代碼, 而後詢問開發人員具體有哪些接口涉及到本次功能提測, 以後從每一個接口入手, 查看業務邏輯層與數據庫訪問層代碼, 看其實現是否與需求相符, 並找出一些明顯的錯誤。這樣作的目的只有一個, 那就是節省時間。其實這些問題應該在開發提交代碼前由code review發現的， 可是因爲團隊剛剛組建，沒有造成一套合理的流程，並且時間很是有限。其實這些惡性bug都是能夠在測試階段發現的，並且是在冒煙測試階段就能輕易發現，可是問題仍是時間緊，不如先走查一遍代碼，將錯誤處與開發溝通，以後提bug，將具體哪行哪一個位置的問題標出，這樣能夠大大加快測試進展，起碼能夠快速使得測試經過冒煙階段，節約一些時間。

　　下面就舉幾個栗子說明我在走查階段發現的幾個明顯的問題：

　　

 

首先看這段代碼：

　　

在數據庫讀取的時候查詢的是UNSETTLED類型的帳單，但查詢結果直接賦值給了名爲settledBills的引用，好吧，以後的代碼就都是錯的了。

 

再舉個栗子：

　　

這裏調用了dubbo服務接口，對接另外一個系統，傳入的枚舉UNSETTLE_BILL_REPAY，表明償還未出帳單的意思，可是這個代碼是用來償還已出帳單的service層代碼。。。

 

其實這種問題在咱們項目的代碼裏發現的不少不少，在兩個系統對接的時候，兩方開發人員幾乎不溝通，看哪一個接口像就直接調用了，以後就都推給測試去測了，發現了問題再改，發現不了就呵呵了，不說了，都是淚。。。

總結一下，面對不靠譜、不溝通的開發，幾乎沒有管理的項目，一切靠測試手動發現問題實在是鴨梨山大啊。