Code Review

程式碼評審，簡稱 CR

為什麼要進行 CR

• 提升程式碼質量
• 減少Bug，降低系統風險
• 相互討論學習，提高團隊能力

為什麼很多公司推動不了 CR

• 業務需求 VS 程式碼評審
• 專案大且亂，遷一而動全身

爭取 CR 時間

當業務需求和程式碼評審衝突時，跟產品爭取時間來進行 CR

• 專案急不急，能延期上線？
• 部分功能有沒有用，能砍掉？
• ...

爭取失敗才是正常

大部分時候，業務需求很難讓步，但有些也是有機會，看你自己怎麼爭取。 既然失敗了，該怎麼辦呢？

粒化 CR

個人覺得 CR 可以拆分不通階段來完成不同的職能，以達到粒化的效果。

• 第一階段：程式碼是否規範（ESLint、命名、註釋）
• 第二階段：目錄結構是否合理
• 第三階段：檔案、函式是否過長
• 第四階段：待定。。

因為還沒試過粒化 CR，不知道粒化得是否合理，後面在公司內部推行後再來看下效果，再回來調整粒化的階段內容，以達到較優。

每個階段都在什麼時候進行 CR

如果有足夠多的時間來CR，肯定在上線前進行所有階段 CR 並優化完。 時間不夠的話，粒化CR就派上用場了，按照時間安排進行不同的階段CR。

上線前

前兩個階段不影響邏輯，我覺得可以在開發期末來 CR，亦或者在測試期修 Bug 來 CR 也行。 如果這都完成不了，那隻能是你們自己的問題。 ps： 上線之前至少需要完成第一階段的 CR，儘量連第二階段也完成

上線後

每隔一週進行一個階段的CR，如果專案太多複雜，可以在階段內分模組進行CR。 這時候也別又說沒時間，不然又回到最開始的問題了。解決辦法總是想出來的，不是坐等送上門的。 後面這些階段目前還沒實踐過，不打包票，等嘗試過後再回來填充。

話外題

第一、第二階段是否有需要保留

誠然，有些人認為前兩個階段應該算作個人基本功，不應該拿來當作CR，但我想說的是，這可能是大廠或大牛們的個人基本功。

其實大部分中小型企業、創業型公司，很多人前兩個階段都很難做到，所以才把這兩個階段列進來，如果你的團隊已經優秀到每個人的前兩個階段都紮實，那可以直接忽略掉，直接進入第三階段。

如果覺得我 CR 粒化的不夠完善，不夠合理，歡迎指出，大家一起學習，畢竟這也是我的一點思考，還沒能確定這樣粒化是否是正確的。

富有同理心

CR 推行者需要提前強調 review 和 被review 的人心態要放好，要有同理心，該尊重的要尊重，該虛心接收的虛心接受。

凜冬將至

最近各種裁員資訊層出不窮，建議大夥們放好心態，不要裸辭，不要裸辭，不要裸辭，重要的事說三遍，安心學習準備，以待春天來臨。

參考地址

coolshell.cn/articles/13…
www.jianshu.com/p/6b1e7a6e8…

文章可隨意轉載，請保留此 原文連結