Code Review
程式碼評審，簡稱 CR
為什麼要進行 CR
CR 的好處眾所周知，這裡不詳細述說
- 提升程式碼質量
- 減少Bug，降低系統風險
- 相互討論學習，提高團隊能力
為什麼很多公司推動不了 CR
- 專案大且亂，一時半會看不完
- 業務需求 VS 程式碼評審
有些專案很大很亂，說不定一次 CR 會議，兩個鐘下來都 CR 不完，或者都還沒理出頭緒就會議結束了。
大部分公司都是產品業務驅動型，少數才是技術驅動型公司，所以一般公司內部都是以業務為主，很難有時間來 CR。
爭取 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…
文章可隨意轉載，請保留此 原文連結