推薦閱讀： 大數據智慧平臺落地方案 Nginx + 阿裡雲SSL + tomcat 實現https訪問代理 永遠別忘了TD 再確認測試代碼前，先找別人幫你檢查下是否無誤。在別人做之前儘量檢查出bug並且將其處理好。代碼審查最重要規則是對即將提交的代碼中查找問題——你需要做的就是確認代碼是正確的。 2 ...
推薦閱讀：
Nginx + 阿裡雲SSL + tomcat 實現https訪問代理
再確認測試代碼前，先找別人幫你檢查下是否無誤。在別人做之前儘量檢查出bug並且將其處理好。代碼審查最重要規則是對即將提交的代碼中查找問題——你需要做的就是確認代碼是正確的。
2.儘可能的自動化
這裡有幾個非常好的Java工具比如：PMD, Checkstyle, Findbugs等等。問題是當利用這些工具查找後人們還肯花時間去做代碼審查嗎？
使用這些工具前，為這些工具制定一套細則是非常重要的。這能夠確保你使用同一個代碼審核標準從而區別於那些常被用於20世紀老式的代碼審查規範。在理想的狀態下，這些工具可運行在各種版本控制系統上通過hook審查每個代碼。如果該代碼不好將被阻止在外。
3.尊重設計
在我開始從事Java項目早期時，用代碼審查的方式已為時已晚。因為當你檢查代碼問題時實際上給你的設計造成了缺陷。設計模式被誤解，一些繁雜的附屬物質混入進來或者開發者脫離了主題。
審查會混亂你的觀點。或許你會反駁：“這是代碼審查而不是設計審查”。這時一些爛攤子必然會接踵而至。為了避免這些問題發生，我們改變了設計的初衷。代碼審查會牽連到很多面，無論是設計還是設計審查。事實上，我們通過設計審查要比代碼審而得多的衝擊要多的多。設計需要更高的質量和靈感，我們應該避免一些複雜的思維。
4. 統一的風格指南
即使是使用自動化工具（諸如Checkstyle，Findbugs等）也應避免不必要的風格衝突，你的項目應該具備有風格指南。（在儘可能的情況下）堅持Java協議的規範標準。嘗試著為你的項目介紹制定一個“詞典”，這就意味著，當涉及這個代碼時，查看該代碼的用法和環境是否適宜，這些都很容易被檢測出。
5. 挑選適宜的工具
如果開發者都在使用Eclipse開發工具（ Eclipse IDE插件Jupiter），你可以通過你的方式來查看代碼、調試代碼甚至可使用Eclipse IDE上的一切東西當來幫助你在審查代碼時更加的便捷。但是，如果大家沒有使用同一個IDE（或者該IDE沒有給你的工作帶來方便）你可以考慮Review Board. ，它是個不錯的選擇。
6.請記住每個項目都不同
也許你在採用以前的項目方法工作，但是，請記住每個項目之間是不同的。每一個項目都有特定的架構（高併發或是高分散），有特定的文化（或許很多人喜歡使用Eclipse），並使用特定的工具（maven or ant）。難道你想照葫蘆畫瓢？OK，請記住，不同的項目有不同的工作方法。
7.懂得取捨
代碼審查需要積極和細緻而不是賣弄學問。你會因為一些細微的瑣事讓你緊張而導致項目失敗或是花費公司成本嗎？記住，千萬不要這樣。理清頭緒，換個角度想想，改變自己的心態而不是記掛著去改變別人。
8. Be buddies
在我看來，稱之為“buddy reviews”（別人會叫“over the shoulder”）非常好。A buddy review是指與其他團隊成員每隔一到兩天以非正式的形式討論，並且快速的瀏覽（5-10分鐘）對方的代碼。這種方法可以幫助你：
1. 及早的發現問題
2. 總是很快的知道該乾什麼
3. 代碼審查無須過長，因為你只需要查看新的代碼，舊的代碼會很快趕上
4. 這種非正式的場合——沒有緊張感，很有趣！
5. 可以定期的交換想法
buddy reviewing在團隊中是一種很好的工作方式，當某人在團隊中出現問題時可以及早的發現。這不僅可以幫助大家，還可以交換彼此的進度和想法。
總之，如果你的項目正在進行代碼審查，應該做到快速、有效、不浪費別人的時間。正如文章所說的，這幾點非常重要。代碼審查用意是在代碼提交前找到其中的問題。
