“通過一次真正徹底地代碼審查（code reviews），仔細閱讀你的代碼，找出問題，這是我知道的最好的方式去檢測早期的bug，但是他們很少去這樣干過。某種意義上是因為他們花了大量的時間去寫好代碼，但是我認為主要是因為絕大部分程序員害怕其他人審查自己的代碼。作為專業的程序員我們要克服阻力，如果你不愿意別人閱讀你的代碼，然后只是按照自己的意愿寫，如果其他人沒法讀懂它，又怎能讓別人使用呢？”Jim Waldo – 《Java語言精粹》的作者
我強烈贊同code review 是軟件生命周期管理中重要的一部分，因為它能幫助我們交付高質量代碼、合格作品。
傳統上code review僅是一個形式，通常在代碼提交之前由團隊負責人或高級程序員負責。在敏捷開發環境中，通過團隊合作code review 更系統化，代碼的目標和期望應該能用編碼指南清晰的定義出來，code review的目標是協同合作，而不是查錯。總之code review對整個團隊尤其每個程序員都有好處，所以每個人都應該參與進來。
code review的好處：
俗話說三個臭皮匠賽過諸葛亮，code review 更易于發現代碼bug等問題
3、保證代碼質量以及提高代碼可讀性
2、團隊之間建立信任
1、指導初級程序員
編碼標準是獨立于語言的，對于Java 程序員來說，我想從以下幾個范圍來做code review
Java code review的標準：
合適的變量聲明；如：實例變量還是靜態變量、常量等
9、性能問題；如：當沒有線程安全問題時使用ArrayList，HashMap替代Vector，Hashtable
8、內存問題；如：本應使用對象重用或者對象池時卻被不恰當的初始化，沒有在finally塊中關閉昂貴的資源。
7、數據訪問問題：從數據庫一次獲取數據太多，請求太多的數據庫調用。
6、線程安全問題；如：Java API類像SimpleDateFormat，Calendar，DecimalFormat等不是線程完全的，在JSP中聲明變量也不是安全的，存儲狀態信息在Struts action類中或者多線程servlet也不是線程安全的。
5、對錯誤的處理：異常拋出而沒有保持原始模型（希望Java7修復它），沒有記錄到日志系統中
4、System.out常被log4j替換
3、設計問題：沒有重用代碼，沒有清晰的責任分離。如：業務邏輯嵌套在servlet中，而沒有使用業務邏輯層，可視化元素（如HTML，CSS）嵌入在后臺。
2、代碼文檔：沒有注釋，沒有頭文件等
1、從給定的框架中遵循最佳實踐：如Spring3中注解替代xml文件對于IOC， 對于每一個簡單的部署使用外部屬性替代硬編碼值等
你應該為團隊做個code review的文檔和模板，隨著項目的開始同步更新，學習更多你項目中選擇的軟件。
工欲善其事必先利其器
code review 工具：
3、Crucible 是 Atlassian公司的工具用來不間斷處理的審查工作，Crucible能做代碼審查而且高度集成在JIRA和FishEye中，支持Subversion、Git等其他類型的VCS。一個通用的例子就是Crucible提供一個轉換憑證的工作流，從打開》審查》解決，另一種情景是在代碼改變后check- in了之后自動審查。
2、Gerrit ，Gerrit一個基于web的code review系統。通過Git版本控制系統能方便在線做code reviews。
1、Checkstyle： 并不只是一個code review 工具，更是一個開發工具確保開發者的代碼遵循標準，在每一次code review中節省時間。
最重要的是，使用Checkstyle能使代碼檢查成為一個相對簡單的任務，你可以把code review 作為日常活動中的一部分而不需要在項目結束的時候才開始，因為那時候項目的交付期限讓你的生活一團糟了。