Code Review 總讓人感到費神
code review 是一件很耗費心神的工作。在關注業務邏輯的合理性和正確性的同時很容易不小心忽略一些小錯誤。以下面的 java snippet code 為例，有幾個常見的錯誤？
答案是 5 個。
4~10 行不是 thread-safe，在 multi thread 有可能產生 bug。
第 7 行的 <String> 可以拿掉，Java7 以上的版本可以自動推斷泛型類型。
18、26 行都可以直接 return。
你花了多少時間找出這些錯誤，一分鐘？兩分鐘？
試著想像一下，如果這些小錯誤散佈在一次新功能的 commit 中，藏在各個業務邏輯之中，你需要花多少心力和時間才能一一揪出來？
以我自己而言，我無法保證每次 code review 時都能抓到這些錯誤，尤其在手上有其他事，同事又因為時程壓力希望我趕快 review 完讓他上測試環境，這時候往往無法花太多時間仔細的 review 細節。
我認為 code review 應該可以更有效率地進行，人腦應該專注在抽象的邏輯和程式架構，至於這些瑣碎且有既定 pattern 的程式小錯誤讓程式碼靜態分析工具幫忙抓出來。所以我設計了一套機制幫助我能更高效的 code review。
設計概念
最原始的概念就 commit code 之後要 code review 前，先產生一份新 commit code 的靜態分析報告作為前置檢查動作。整套機制的需求有：
- 僅針對新 commit code 的靜態分析工具：code review 當下我只關心這次 commit 的 code，除此之外都不在 code review 範圍內。即便其他地方的程式碼有問題，那也應該是另一個 commit。
- 自動觸發：靜態分析應該是自動觸發的，當同事需要我 code review 時，這些分析資訊應該一併出現，我不需要額外時間執行指令。
- 整合資訊在一個地方：靜態分析的結果，review 的代碼應該集中在一個地方，當 code review ，從一個地方可以看到需要 review 的程式碼，靜態分析的結果。
根據上述的需求，我會需要一個程式碼靜態掃描工具，一個版控的平台，和一個 CI 平台。
實作
程式碼靜態掃描工具：我選擇用 sonarqube。sonarqube 身為一個老牌的靜態掃描工具，支援各大程式語言，而且 sonarqube 可以自定義 new code ，讓你只關注新 commit 的 code 的掃描報告。
版控平台：部門一直都用 github 作為版控平台，加上 github api 可以讓你自己客製 commit 的狀態和連結，方便在 PR 的頁面上顯示 sonar 的掃描結果以及附上掃描報告 url。
CI 平台：由於公司的 QA 部門一直用 jenkins 作為自動測試的平台，加上 jenkins 有豐富的套件，和可以用 shell script 自由的客製流程，因此直接選用 jenkins。
流程上會是這樣，當同事 commit ，發 PR 要我 review 時，jenkins 會自動觸發 sonarqube 跑靜態分析，並將掃描結果的 url 丟到 github 的 commit status 上。
成果
實際上運行的結果如下，同事發 PR 頁面請我幫忙 review 時，頁面如下：
右上方的連結可以看到這次 commit 異動的部分；下方的 status check 顯示這次 commit 的 code 靜態掃描沒過，右方的 detail 可以看到詳細的報告內容如下：
上方可以看到靜態分析失敗的原因（commit code 的 reliability 及測試涵蓋率未達標），左下可以看整體專案的靜態分析結果，右下則是這次 commit code 的靜態分析結果。點進上方的失敗原因連結可以看到具體是那段新 commit 的 code 有問題
結論
自此同事發 PR 給我 review 時，透過自動化靜態分析這次 commit 的 code，我可以根據掃描的結果很快的決定要不要投入時間 review code，也可以請同事自己根據掃描結果修改常見的錯誤，大幅的提升 code review 效率。