我們現在的項目是會做CodeReview的，也就是代碼審核；但是說實話，我們公司雖然對CodeReview要求很嚴格，但是形式大于實用；下面我就談談我對CodeReview的一些看法。
為什么要做CodeReview
提高代碼質量：代碼審核確實在一定程度上可以提高代碼的質量；每個程序員或多或少都有一些不好的編程習慣，自認為理所應當的代碼可能是有問題的；在代碼審核的過程中，別的開發人員可以幫其發現和糾正；
“威懾性”的作用：“我的代碼要是被查到太多的問題，那多沒面子”，很多程序員會這樣想；
熟悉項目所有的代碼：在做CodeReview的時候，也是熟悉項目其他模塊的過程；讓每個開發人員都熟悉整個項目代碼，可以減少某個程序員在休假、離職的時候帶來的風險；
打造技術氛圍：追求更完美的代碼，CodeReview的過程，本身也是一種技術交流；
對代碼的可讀性有比較高的要求：CodeReview是檢查代碼可讀性的非常好的手段，而良好的代碼可讀性，讓后期的改動和維護都非常容易，并且讓項目組人員有流動的時候，新人會更快地熟悉代碼，工作更容易交接。
當然不少人會反對CodeReview，因為很多時候項目開發時間很緊，加班才能勉強完成代碼開發，不可能給CodeReview留出時間；
有些公司雖然有嚴格的CodeReview流程和要求，比如我們使用Fisheye工具，項目的每次提交的、每一行代碼提交都必須做代碼審核，并且記錄到KPI考核里，但是大多數時候都是流于形式。
如何做好CodeReview
我說一說我們項目的一些方法，效果不一定是最好的，但是比【形式主義】要強很多。
不一定要每一行代碼都Review到，我們是采用抽查的方式；（我始終覺得“威懾性”很重要）；
項目組的新人，CodeReview盡量全部覆蓋，不一定是他水平不高，主要是看他的代碼是否符合項目制定的規范；
我們更多的時候是采用集體CodeReview，也就是在一個敏捷迭代結束的時候，不僅要做驗收，還要花半小時到一小時，抽查一些代碼做CodeReview，也就是把代碼投影出來，大家一起看這些代碼的邏輯和語法；
CodeReview的水平也是需要培養的，先讓項目的技術負責人或代碼水平高的同事先做CodeReview，然后讓其他開發人員去學習他們CodeReview的方法（從哪些角度Review、哪些是好代碼、哪些是差代碼）。