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

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

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

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

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

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

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

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

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

總結(jié)

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

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