有家叫作 SmartBear 公司, 我用過他們的一款代碼審查的工具 Code Collaborator , 對于代碼審查，覺得他們總結(jié)的十條最佳實踐挺不錯， 順手翻譯如下， 未嚴格遵循原文翻譯， 并加了點評注， 原文參見 https://smartbear.com/learn/code-review/best-practices-for-peer-code-review
1.一次只審查小于 500 行的代碼
2.不要著急， 代碼評審的速率最好小于每小時500行
3.一次審查不要超過一個小時
4. 設(shè)立目標并檢查相應(yīng)的測試及度量數(shù)據(jù)
如何你的實現(xiàn)某個功能的， 跑幾個相應(yīng)的集成測試
如果你是優(yōu)化某個性能的， 給出一個性能優(yōu)化數(shù)據(jù)
如果你是應(yīng)對某種異常的， 給出相應(yīng)的異常測試用例
在代碼審查結(jié)束后， 也給出一個總結(jié)：
- 花費了多長時間（Man Hour）,
- 每小時審查了多少行代碼，
- 找出了多少bug （平均每百行bug率是多少）
- 代碼的相關(guān)測試是否充分和有效率
- 發(fā)現(xiàn)了多少設(shè)計上的問題
- 發(fā)現(xiàn)了多少可靠性與異常保護方面的問題
- 發(fā)現(xiàn)了多少有關(guān)可理解性和可維護性的潛在問題
5.作者應(yīng)該在代碼審查之前對代碼給出相應(yīng)的說明和注解
6. 使用靜態(tài)代碼檢查工具和檢查表
先自查， 再互查
7. 建立一個跟蹤修復(fù)所發(fā)現(xiàn)問題的流程
比如
- 創(chuàng)建一個git issue 或報一個bug來跟蹤問題，指定專人對修復(fù) bug 的代碼作再次審查
- 對設(shè)計或需求上的問題作出后續(xù)的安排，如需求或設(shè)計評審會議
- 對疑難問題創(chuàng)建一個任務(wù)進行后續(xù)研究
- 等等
8.培育一個積極的代碼評審文化
代碼評審可能會遭遇抵觸情緒， 造成同事之間關(guān)系緊張， 應(yīng)該樹立這樣一種觀念， 越早發(fā)現(xiàn)問題越好，代碼評審是最有效率的提高代碼質(zhì)量， 提升代碼水平的手段， 互相協(xié)作和學(xué)習(xí)才可以共同進步。
在代碼評審時， 要對事不對人， 保持謙遜和禮貌， 代碼評審的結(jié)果不可作為業(yè)績考核的數(shù)據(jù)標準
9. 重視代碼評審的潛在作用
有人會檢查你的代碼， 自然會驅(qū)動你寫好代碼。為了面子， 你也會有更多動力寫出更優(yōu)雅的代碼
10. 實踐輕量級的代碼評審
無需每次開會來審查代碼， IM, Pull Request, 面對面的一起結(jié)對審查代碼都是不錯的方法
另外，說點代碼評審的個人感受
1. 適可而止
幾乎沒有十全十美無可挑剔的代碼，總是有些許改進的空間，不必過度優(yōu)化，過度設(shè)計，把握住基本原則，適可而止，關(guān)鍵要看是否變得更好，以后是否留下隱患或者更大的麻煩
2. 和諧共贏
人性的弱點在于喜歡表揚，反感批評，代碼評審要對事不對人，講究方式方法，顧及到別人的感受，先肯定，再否定，給別人臺階下，誰敢說自已的代碼沒毛病，少說感覺，多講原則，不提個人喜好，只講利弊分析
3. 有始有終
代碼評審會議一定要有記錄，有跟蹤，有始有終，每一條反饋意見都要落實，代碼一定要有類似于pull request 的比較評注工具，發(fā)現(xiàn)的常見問題最好整理總結(jié)出來，作為參考比如Checklist, FAQ 或者 best practice
