敏捷代碼審查指南
通過一次真正徹底地代碼審查（code reviews），仔細閱讀你的代碼，找出問題，這是我知道的最好的方式去檢測早期的 bug，但是他們很少去這樣干過。某種意義上是因為他們花了大量的時間去寫好代碼，但是我認為主要是因為絕大部分 程序員害怕其他人審查自己的代碼。作為專業的程序員我們要克服阻力，如果你不愿意別人閱讀你的代碼，然后只是按照自己的意愿寫，如果其他人沒法讀懂它，又怎能讓別人使用呢？”J im 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 作為日常活動中的一部分而不需要在項目結束的時候才開始，因為那時候項目的交付期限讓你的生活一團糟了。