























標題: 「如何提供專業 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 能夠幫助團隊帶來下列好處
為了讓上述概念可以充分的導入到團隊專案中,作者分享了一些自己常用的概念與招式
事先準備一份 Checklist 一個好的 review 流程就是要有一份檢查清單,這份清單上面描述的是每次程式碼合併都“必須”要符合的規則,同時也是團隊很重視的規則 這份清單沒有絕對標準,主要是根據團隊去思考哪些東西是最重要的,舉例來說
這份清單的重點是只要列入那些被視為是非常必須且重要的項目就好,不然整個清單落落長其實意義也不高
盡可能的自動化上述檢查 準備好前述清單後,下一個步驟就是想辦法將上述清單規範給自動化,譬如
當有辦法自動化這些操作後,下一個步驟就是要思考什麼時候執行?
一切都準備完畢後就可以將其整合到整個 git 工具中,譬如只有當 CI pipeline 通過的 PR 才有被人 review 的需求,如果連自動化測試都沒有辦法通過,那就是開發者的 責任要去將其完成,一切準備就緒後才要開始最後一步
作者也推薦採用 IDE 來進行 code review,很多 IDE 強大的功能都能夠幫助開發者更有效率地去檢視程式碼,譬如快速找到宣告點,被呼叫點以及整個資料結構的面貌等 這些都可以省下不少時間
最後最重要的是每次 PR 的大小不能太大,這點其實也是 Linux Kernel 內一直奉行的原則,過大的修改有太多檔案要看,同時也有更多可能潛在的不相容問題要注意 這對開發者與 reviewer 來說都是個沈重的負擔,因此能的話將修改以拆分成數個有意義的 PR 分別檢視會使得整體流程更講有效率,同時也可以避免 檔案太多時可能看不下去就直接無腦 +2 的蓋章行為
此内容由惯性聚合(RSS阅读器)自动聚合整理,仅供阅读参考。 原文来自 — 版权归原作者所有。