標題: 「如何提供專業 Code Review 意見」 類別: others 連結: https://medium.com/@yar.dobroskok/how-to-review-the-code-like-a-pro-6b656101eb89

作者開門見山提到，如果團隊中沒有任何 code review 文化的話，請直接忽略這篇文章。 當團隊真的有 code review 的經驗時，才有機會透過本篇文章分享的一些概念來改善整個 code review 的流程，高效率低耗時。

作者認為一個好品質的 code review 能夠幫助團隊帶來下列好處

1. 避免合併一些充滿 bug, 難讀, 無效率的程式碼到專案中
2. 開發者可以互相分享彼此的知識
3. 獲得關於實作上的各種意見
4. 確保團隊內的 coding style 一致

為了讓上述概念可以充分的導入到團隊專案中，作者分享了一些自己常用的概念與招式

事先準備一份 Checklist 一個好的 review 流程就是要有一份檢查清單，這份清單上面描述的是每次程式碼合併都“必須”要符合的規則，同時也是團隊很重視的規則 這份清單沒有絕對標準，主要是根據團隊去思考哪些東西是最重要的，舉例來說

1. Branch, Commit 內容與名稱是否符合規範
2. Code 是否有足夠的可讀性
3. Codesytle 以及命名規範是否符合團隊文化
4. 資料夾/檔案結構是否符合團隊文化
5. 是否有包含相關測試
6. 文件是否有一起準備

這份清單的重點是只要列入那些被視為是非常必須且重要的項目就好，不然整個清單落落長其實意義也不高

盡可能的自動化上述檢查 準備好前述清單後，下一個步驟就是想辦法將上述清單規範給自動化，譬如

1. 透過 linters 來檢查 codesytle
2. 運行一些如 SonarQube, Codacy 等工具來幫忙檢查是否有潛在的低效率或是有漏洞的程式碼
3. 透過相關框架運行自動化測試並且得到相關的覆蓋率報表

當有辦法自動化這些操作後，下一個步驟就是要思考什麼時候執行？

1. 針對一些快速檢查，譬如 linter, beautifer 等工具，可以考慮整合到 pre-commit hook/ pre-push Git hook 等時間點運行 這樣就可以讓開發者快速檢查簡單錯誤
2. 針對一些比較花時間的檢查，譬如分析工具，測試以及相關建置流程這些都可以放到 CI pipeline 去運行

一切都準備完畢後就可以將其整合到整個 git 工具中，譬如只有當 CI pipeline 通過的 PR 才有被人 review 的需求，如果連自動化測試都沒有辦法通過，那就是開發者的 責任要去將其完成，一切準備就緒後才要開始最後一步

• 人工介入 review * 開始人工 review 時，因為前述自動化的過程已經幫忙檢查非常多的事項，所以這時候要專注的就是運作邏輯。 能的話作者建議 review 與其慢慢看 code 猜想不如直接跟開發者一起討論 review，可以避免來回溝通花費的無效時間 此外開發者也可以更清楚地去解釋所有實作的背後理由與考量。

作者也推薦採用 IDE 來進行 code review，很多 IDE 強大的功能都能夠幫助開發者更有效率地去檢視程式碼，譬如快速找到宣告點，被呼叫點以及整個資料結構的面貌等 這些都可以省下不少時間

最後最重要的是每次 PR 的大小不能太大，這點其實也是 Linux Kernel 內一直奉行的原則，過大的修改有太多檔案要看，同時也有更多可能潛在的不相容問題要注意 這對開發者與 reviewer 來說都是個沈重的負擔，因此能的話將修改以拆分成數個有意義的 PR 分別檢視會使得整體流程更講有效率，同時也可以避免 檔案太多時可能看不下去就直接無腦 +2 的蓋章行為