“通過一次真正徹底地程式碼審查（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 作為日常活動中的一部分而不需要在專案結束的時候才開始，因為那時候專案的交付期限讓你的生活一團糟了。
【如需轉載，請標註並保留原文連結、譯文連結和譯者等資訊，謝謝合作！】