首先必須承認Code Review的價值。經驗豐富的專家們在做代碼審查的時候，能夠根據以往經驗，規避重大缺陷的發生，對開發人員給予有價值的指導。然而，這個過程，太冗長，太低效。
Code Review必須基於事實。這裏的事實，就是，源代碼庫。SVN Repository, 或者HG/Git Repository. 在多人協作環境中，對於一份不在源代碼庫代碼是基本不可信的 —— 你無法預知，他是否將會成爲最終可工作軟件的一部分。
積攢下來衆多的代碼修改，使得產生重型、低效的溝通方式成爲必然。這類衆型的溝通方式往往成本驚人 – 需要佔用最好的人很長時間。
過分誇大專家的作用。根據以往經驗，許多最終發現問題，回溯上來，其實是一些簡單的邏輯問題。這些問題如果分散在平時結對或者更頻繁的過程中，則更容易發現。很多情況下，是開發人員對常見的bad smell瞭解和修煉不足，而這些bad smell常常是導致問題的地方。例如在一個已經有3重循環的方法中加入了新的判斷而沒有測試；修改了函數的返回值而沒有任何說明；if 判斷中包含了多達4-5個變量的比較判斷而沒有抽象爲一個更具業務含義的方法，等等。Review手段的原始落後。
Review必須基於變化。會看報表的人都知道，看報表只需要看兩個東西：趨勢和拐點。Code Review也一樣，只需要看變化。SVN/Hg/Git這類現代化的工具給我們提供了豐富的，基於changeset的compare工具。查看一天，整個團隊的check in情況，頂多只需要10分鐘-15分鐘。
在敏捷過程中，Code Review幾乎是一個被忽視的環節——不是不做，而是時時在做。結對時，我們會對結對夥伴的編碼習慣、新寫的類、變量表示質疑；提交之後，有代碼靜態檢查工具、單元測試工具、覆蓋率工具幫助我們檢查有沒有犯簡單愚蠢的錯誤、有沒有破壞既有功能；持續集成服務器則中立、不知疲倦的在每次我們提交之後運行所有的過程。
Code Review不是一個審查環節。不是一個考覈環節。它是交流和反饋環節。
