代碼審查是一個好東西，從理論上說，它可以即時（就在代碼編寫的當天下午）的review代碼，以最小的成本發現潛在的隱患，把問題消滅在萌芽狀態；同時由于還有至少另外一個人看懂過這部分代碼，項目就不會嚴重依賴于某個個人。但是，在管理中非常忌諱的是一聽到先進的東西，就趕緊照搬到企業中，也不管各種配套措施和前提條件是否具備。如同中國的教育產業化。當然也忌諱固步自封，不思進取。
那么，代碼審查的前提條件是什么呢？
第一個條件就是要有統一的編碼規范，如果一個軟件公司這一點都沒有做到，那就是徹底的土匪軍，代碼審查這種正規軍的做法就不要考慮了，先把編碼規范建立并培訓普及起來。
第二個條件就是開發人員要比較多，多到至少一個模塊有兩個人在做；或者至少每一個模塊除了開發者之外，還有一個熟悉理解該模塊的人。為什么需要這樣，其實很簡單，代碼審查的目的是要能看懂并真正理解代碼和潛在的設計思路，試想如果都看不懂又如何發現問題和以后可能的頂替呢？在一個項目，每個人負責N多個模塊，各個模塊之間功能、設計、算法差別又很大，如果強制規定必須進行代碼審查，那豈不是要求大家都在學習別的模塊，并努力發現不符合編碼規范（例如沒有必要的空行等）的小錯誤，以應付要求。另外，在這種項目中，每個人的任務都是滿滿的，誰也不會有興致和時間去學習另一個陌生的模塊。
那么，在不具備第二個條件的軟件企業/項目中，是否就無法進行代碼審查了呢？也不盡然。在我同事所帶領的一個項目中，就采用了另一種方式來進行代碼審查，也取得了預想的效果（雖然不是正規意義上代碼審查的效果）。在這個項目中，除了項目經理外，其他幾個開發工程師都是剛畢業的新員工，所開發的產品已經發展很多個版本，產品規模巨大，模塊眾多，項目開發人員又不多。如果按照正規意義上的代碼審查，結果是預想而知的。那么，該項目經理就采取了另一種形式，就是定期把幾個開發工程師召集在一起，來閱讀和分析某個開發工程師最近完成的一個小功能，通過對該功能的分析和代碼的閱讀，項目經理給出點評，變相起到了一種設計培訓和代碼規范培訓的作用。
所以代碼審查可以分為兩種方式、對應兩種目的。
第一種方式是任何軟件項目都可以、且應該做的，就是在開發之前或者前期，由有經驗者和開發工程師一起來閱讀一段代碼，有經驗者評點這段代碼，指出設計上和代碼實現上好的或者可以改進的地方，開發工程師可以提出一些疑問，共同討論；這樣主要起到培訓和代碼規范的目的。這種審查方式不用經常進行，開發初期、尤其是部分開發工程師水平還有待提高時，做3-5次就可以了。投入不大，效果明顯。
第二種方式是主要發現代碼中存在的隱患和問題為主，一般在開發階段，每天下午四五點之后，由開發工程師之間，交換檢查當天編寫完成的代碼，檢查完畢后，再提交到代碼庫中。這種方式投入成本高、且必須每個模塊都至少有兩個人比較熟悉，否則就發現不了存在的隱患和邏輯錯誤，只能做代碼規范層面的檢查。但如果一個項目團隊擁有了足夠的資源保證，就完全可以做到每天進行這樣的審查；這種審查可以在第一時間review編寫（增刪改）的代碼，對于提高代碼質量，發現并解決潛在的問題有極大的好處，可以大大降低在后期測試或者用戶使用中發現缺陷的概率，減少維護的開銷，提高產品的品質；從整體上看反而會減少工作量，縮短開發周期。