1.對事不對人。大家是同事，在一個團隊工作和氣很重要。不要在 Code Review 中說“你寫的什么垃圾東西這種話”，你可以說“這個變量名不好理解，咱們換成巴拉巴拉是不是更好”。

2. 每個 Review 至少給一條正面評價。Code Review 本意是改善代碼質量，增強團隊成員之間的溝通，但是我一提交代碼就有人說我寫的垃圾，這很打擊自信心啊，也不利于團隊成員和平相處。代碼有問題，指出問題是必須的，要實事求是，但是有的時候也需要給隊友一點鼓勵，

3. 保證發布的代碼和評審意見的可讀性。大家都是程序員，你提交代碼的時候，在符合團隊風格的同時，把代碼弄的好看點，如果你明確自己這個代碼哪個地方不足，Highlight 出來讓大家給意見。如果你是來 Review 代碼的，把意見寫的通順點，評論有條理一些。對反引號 (`) 嵌入代碼或三個反引號 (```) 寫代碼塊，這樣看的舒服得多，效率也高

4. 用工具進行基礎問題的自動化檢查。用 Tab 還是空格，用兩個空格還是四個空格，函數后面怎么換行等基礎問題檢查，可以使用 eslint 和Rubocop 等類似的工具進行，團隊成員應該把更多精力放在代碼規范，代碼性能優化等地方。

5. 全員參加 Code Review，并設定各部分負責人。擴大 Code Review 參與面，參與不是說一定去審核別人的代碼，可以是代碼被審核，也可以是看別人審核意見，這都是學習的過程。并且每部分設定負責人，該負責人對這部分代碼質量負責，負責人需要是資深工程師。全員參與 Code Review 可以讓團隊成員更快的成長，新人在看大佬 Review 代碼的過程就能學到很多。

6. 每個代碼 PR 內容一定要少。Code Review 效果和質量與 PR 代碼量成反比，你一下提交這么多代碼，我今天還下不下班了？ 我女朋友你幫我陪？每次 PR 代碼量小一些，看起來速度快，又不至于失去耐心，這樣才能達到 Code Review 的效果，所以要經常進行 Code Review，但是每個 PR 代碼量要少。我建議要少于 300 行/PR。

7. 在寫新代碼之前，先 Review 掉需要評審的代碼。你讓我去 Review 一周前的代碼？我還得把思維和項目進度切換到一周前？大家肯定不愿意，所以要形成規定，寫新代碼之前先把舊的 Review 掉，提交 PR 的時候也保證代碼量小，這樣 Review 起來不需要大塊時間，改起來也快。不能因為 Code Review 大幅耽誤項目進度，進度是全團隊的事，不是某個人的事。

8. 如果你有更好的方案，盡管提出來。在 Code Review 中經常會發現寫的不好的地方，如果你有更好的方法，歡迎提出來！首先能改進這個 PR 的代碼，其次能體現你的能力，團隊應該定期對這種提出好的解決方案的同事進行獎勵。

9. 不要在 review 中討論需求，review 就是 review。不要在 Code Review 里搞別的，有需要就另安排時間進行，要明確 Code Review 是完善代碼，不是需求和功能討論，始終要以代碼質量為中心。

總結

以上是生活随笔為你收集整理的反思Code Review的注意点与目的的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。