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

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

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

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

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

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

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

8. 如果你有更好的方案，盡管提出來。在 Code Review 中經(jīng)常會發(fā)現(xiàn)寫的不好的地方，如果你有更好的方法，歡迎提出來！首先能改進這個 PR 的代碼，其次能體現(xiàn)你的能力，團隊?wèi)?yīng)該定期對這種提出好的解決方案的同事進行獎勵。

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

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。