1. 永遠別忘了TDD
再確認測驗代碼前，先找別人幫你檢查下是否無誤，在別人做之前盡量檢查出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在團隊中是一種很好的作業方式，當某人在團隊中出現問題時可以及早的發現，這不僅可以幫助大家，還可以交換彼此的進度和想法，
總之，如果你的專案正在進行代碼審查，應該做到快速、有效、不浪費別人的時間，正如文章所說的，這幾點非常重要，代碼審查用意是在代碼提交前找到其中的問題，
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/225618.html
標籤：其他