代碼審查（Code Review)是軟件開(kāi)發(fā)中常用的手段，和QA測(cè)試相比，它更容易發(fā)現(xiàn)和架構(gòu)以及時(shí)序相關(guān)等較難發(fā)現(xiàn)的問(wèn)題，還可以幫助團(tuán)隊(duì)成員提高編程技能，統(tǒng)一編程風(fēng)格等。

　　1. 代碼審查要求團(tuán)隊(duì)有良好的文化

　　團(tuán)隊(duì)需要認(rèn)識(shí)到代碼審查是為了提高整個(gè)團(tuán)隊(duì)的能力，而不是針對(duì)個(gè)體設(shè)置的檢查“關(guān)卡”。

　　“A的代碼有個(gè)bug被B發(fā)現(xiàn)，所以A能力不行，B能力更好”，這一類的陷阱很容易被擴(kuò)散從而影響團(tuán)隊(duì)內(nèi)部的協(xié)作，因此需要避免。

　　另外，代碼審查本身可以提高開(kāi)發(fā)者的能力，讓其從自身犯過(guò)的錯(cuò)誤中學(xué)習(xí)，從他人的思路中學(xué)習(xí)。如果開(kāi)發(fā)者對(duì)這個(gè)流程有抵觸或者反感，這個(gè)目的就達(dá)不到。

　　2. 謹(jǐn)慎的使用審查中問(wèn)題的發(fā)現(xiàn)率作為考評(píng)標(biāo)準(zhǔn)

碼審查中如果發(fā)現(xiàn)問(wèn)題，對(duì)于問(wèn)題的發(fā)現(xiàn)者來(lái)說(shuō)這是好事，應(yīng)該予以鼓勵(lì)。但對(duì)于被發(fā)現(xiàn)者，我們不主張使用這個(gè)方式予以懲罰。軟件開(kāi)發(fā)中bug在所難免，過(guò)度苛求本身有悖常理。更糟的是，如果造成參與者怕承擔(dān)責(zé)任，不愿意在審查中指出問(wèn)題，代碼審查就沒(méi)有任何的價(jià)值和意義。

　　3. 控制每次審查的代碼數(shù)量

　　根據(jù)smartbear在思科所作的調(diào)查，每次審查200行-400行的代碼效果最好。每次試圖審查的代碼過(guò)多，發(fā)現(xiàn)問(wèn)題的能力就會(huì)下降，具體的比例關(guān)系如下圖所示

（我想這是根據(jù)實(shí)現(xiàn)情況而定，如結(jié)合文檔來(lái)評(píng)審，那么代碼多一點(diǎn)也沒(méi)關(guān)系）

　我們?cè)趯?shí)踐中發(fā)現(xiàn)，隨著開(kāi)發(fā)平臺(tái)和開(kāi)發(fā)語(yǔ)言的不同，最優(yōu)的代碼審查量有所不同。但是限制每次審查的數(shù)量確實(shí)非常必要，因?yàn)檫@個(gè)過(guò)程是高強(qiáng)度的腦力密集型活動(dòng)。時(shí)間一長(zhǎng)，代碼在審查者眼里只是字母，無(wú)任何邏輯聯(lián)系，自然不會(huì)有太多的產(chǎn)出。

　　4. 帶著問(wèn)題去進(jìn)行審查

　　我們?cè)诿看未a審查中，要求審查者利用自身的經(jīng)驗(yàn)先思考可能會(huì)碰到的問(wèn)題，然后通過(guò)審查工作驗(yàn)證這些問(wèn)題是否已經(jīng)解決。一個(gè)竅門是，從用戶可見(jiàn)的功能出發(fā)，假設(shè)一個(gè)比較復(fù)雜的使用場(chǎng)景，在代碼閱讀中驗(yàn)證這個(gè)使用場(chǎng)景是否能夠正確工作。

　　使用這個(gè)技巧，可以讓審查者有代入感，真正的沉浸入代碼中，提高效率。大家都知道看武俠小說(shuō)不容易瞌睡，而看專業(yè)書容易瞌睡，原因就是武俠小說(shuō)更容易產(chǎn)生代入感。

　　有的研究建議每次樹立目標(biāo)，控制單位時(shí)間內(nèi)審核的代碼數(shù)量。這個(gè)方法在我們的實(shí)踐中顯得很機(jī)械和流程化，不如上面的方法效果好。

　　5. 所有的問(wèn)題和修改，必須由原作者進(jìn)行確認(rèn)

　　如果在審查中發(fā)現(xiàn)問(wèn)題，務(wù)必由原作者進(jìn)行確認(rèn)。

　　這樣做有兩個(gè)目的：

　　(1)確認(rèn)問(wèn)題確實(shí)存在，保證問(wèn)題被解決

　　(2)讓原作者了解問(wèn)題和不足，幫助其成長(zhǎng)

　　有些時(shí)候?yàn)榱俗非笮?#xff0c;有經(jīng)驗(yàn)的審查者更傾向于直接修改代碼乃至重構(gòu)所有代碼，但這樣不利于提高團(tuán)隊(duì)效率，并且會(huì)增加因?yàn)橹貥?gòu)引入新bug的幾率，通常情況下我們不予鼓勵(lì)。

　　6.利用代碼審查激活個(gè)體“能動(dòng)性"

　　即使項(xiàng)目進(jìn)度比較緊張，無(wú)法完全的進(jìn)行代碼審查，至少也要進(jìn)行部分代碼的審查，此時(shí)隨即抽取一些關(guān)鍵部分是個(gè)不錯(cuò)的辦法。

　　背后的邏輯是，軟件開(kāi)發(fā)是非常有創(chuàng)造性的工作，開(kāi)發(fā)者都有強(qiáng)烈的自我驅(qū)動(dòng)性和自我實(shí)現(xiàn)的要求。讓開(kāi)發(fā)者知道他寫的任何代碼都可能被其他人閱讀和審察，可以促使開(kāi)發(fā)者集中注意力，尤其是避免將質(zhì)量糟糕，乃至有低級(jí)錯(cuò)誤的代碼提交給同伴審查。開(kāi)源軟件也很好的利用了這種心態(tài)來(lái)提高代碼質(zhì)量。

　　7.在非正式，輕松的環(huán)境下進(jìn)行代碼審查

　　如前所述，代碼審查是一個(gè)腦力密集型的工作。參與者需要在比較輕松的環(huán)境下進(jìn)行該工作。因此，我們認(rèn)為像某些實(shí)踐中建議的那樣，以會(huì)議的形式進(jìn)行代碼審查效果并不好，不僅因?yàn)殚L(zhǎng)時(shí)間的會(huì)議容易讓效率低下，更因?yàn)闀?huì)議上可能出現(xiàn)的爭(zhēng)議和思考不利于進(jìn)行如此復(fù)雜的工作。

　　8.提交代碼前自我審查，添加對(duì)代碼的說(shuō)明

　　所有團(tuán)隊(duì)成員在提交代碼給其他成員審查前，必須先進(jìn)行一次審查。這次自我修正形式的審查除了檢查代碼的正確性以外，還可以完成如下的工作：

　　(1)對(duì)代碼添加注釋，說(shuō)明本次修改背后的原因，方便其他人進(jìn)行審查。

　　(2)修正編碼風(fēng)格，尤其是一些關(guān)鍵數(shù)據(jù)結(jié)構(gòu)和方法的命名，提高代碼的可讀性。

　　(3)從全局審視設(shè)計(jì)，是否完整的考慮了所有情景。在實(shí)現(xiàn)之前做的設(shè)計(jì)如果存在考慮不周的情況，這個(gè)階段可以很好的進(jìn)行補(bǔ)救。

　　我們?cè)趯?shí)踐中發(fā)現(xiàn)，即使只有原作者進(jìn)行代碼審查，仍然可以很好的提高代碼質(zhì)量。

　　9.實(shí)現(xiàn)中記錄筆記可以很好的提高問(wèn)題發(fā)現(xiàn)率

　　成員在編碼的時(shí)候應(yīng)做隨手記錄，包括在代碼中用注釋的方式表示，或者記錄簡(jiǎn)單的個(gè)人文檔，這樣做有幾個(gè)好處：

　　(1)避免遺漏。在編碼時(shí)將考慮到的任何問(wèn)題都記錄下來(lái)，在審查階段再次檢查這些問(wèn)題都確認(rèn)解決。

　　(2)根據(jù)研究，每個(gè)人都習(xí)慣犯一些重復(fù)性的錯(cuò)誤。這類問(wèn)題在編碼是記錄下來(lái)，可以在審查的時(shí)候用作檢查的依據(jù)。

　　(3)在反復(fù)記錄筆記并在審查中發(fā)現(xiàn)類似的問(wèn)題后，該類問(wèn)題出現(xiàn)率會(huì)顯著下降

　　10. 使用好的工具進(jìn)行輕量級(jí)的代碼審查

　　“工欲善其事，必先利其器”。我們使用的是bitbucket提供的代碼托管服務(wù)。

　　每個(gè)團(tuán)隊(duì)成員獨(dú)立開(kāi)發(fā)功能，然后利用Pull Request的形式將代碼提交給審查者。復(fù)審者可以很方便在網(wǎng)頁(yè)上閱讀代碼，添加評(píng)論等，然后原作者會(huì)自動(dòng)收到郵件提醒，對(duì)審閱的意見(jiàn)進(jìn)行討論。

　　即使團(tuán)隊(duì)成員分布在天南海北，利用bitbucket提供的工具也能很好的進(jìn)行代碼審查。

　　來(lái)源：堅(jiān)果云投稿（一個(gè)用于移動(dòng)辦公的安全云存儲(chǔ)服務(wù)）。

二、代碼審查：大家都應(yīng)該做的事情

正如我在上一篇博客中提到的（現(xiàn)在可以明確地告訴大家），我已經(jīng)離開(kāi)Google了。雖然我已經(jīng)收到了很多不錯(cuò)的offer，但是還沒(méi)有決定去哪里。在這段時(shí)間里從技術(shù)角度上說(shuō)我不受雇于任何人，雖然也許這會(huì)讓我和（前）同事或者老板關(guān)系有點(diǎn)緊張，但我覺(jué)得應(yīng)該寫一些關(guān)于技術(shù)上的有趣的事情。

正如我在上一篇博客中提到的（現(xiàn)在可以明確地告訴大家），我已經(jīng)離開(kāi)Google了。雖然我已經(jīng)收到了很多不錯(cuò)的offer，但是還沒(méi)有決定去哪里。在這段時(shí)間里從技術(shù)角度上說(shuō)我不受雇于任何人，雖然也許這會(huì)讓我和（前）同事或者老板關(guān)系有點(diǎn)緊張，但我覺(jué)得應(yīng)該寫一些關(guān)于技術(shù)上的有趣的事情。

　　Google確實(shí)是一家很酷的公司。不論是在公司內(nèi)部或是外部，Google都做了很多讓人贊嘆的的事情。這里我想介紹一些不涉及商業(yè)機(jī)密，但鮮為外人所知的事情。

　　Google的代碼之所以優(yōu)秀原因其實(shí)很簡(jiǎn)單：他們非常重視代碼審查。代碼審查并不是Google獨(dú)有的，它被公認(rèn)為是一個(gè)很好的（提高代碼質(zhì)量的）手段，很多人已經(jīng)在日常開(kāi)發(fā)中采用代碼審查。但我還沒(méi)有看到哪一家大公司（像Google這樣）應(yīng)用得如此廣泛。在 Google，任何的產(chǎn)品或者項(xiàng)目代碼在檢入（代碼倉(cāng)庫(kù)）之前都需要進(jìn)行有效的審查。

　　每個(gè)人都要參與代碼審查，而且這里我指的不是非正式的審查：它是軟件開(kāi)發(fā)環(huán)節(jié)中非常重要而且通用的規(guī)則。不僅是產(chǎn)品代碼，所有的代碼都需要進(jìn)行審查。審查代碼不需要投入很多的精力，但是（與不做審查相比）產(chǎn)生的效果卻是天壤之別。

　　關(guān)于代碼審查（code review），Jonathan Danylko 的看法是“代碼要經(jīng)常檢查（包括自查和其他同事檢查）。不要把別人的檢查，看成是對(duì)代碼風(fēng)格的苛求。應(yīng)該把它們看作是有建設(shè)性的批評(píng)。對(duì)個(gè)人來(lái)說(shuō)，經(jīng)常檢查你的代碼并且自問(wèn)，“我怎樣才能寫得更好呢？” 這會(huì)加速你的成長(zhǎng)，讓你成為一個(gè)更優(yōu)秀的程序員?！?br />
　　你能從代碼審查中收獲什么？

　　事實(shí)顯而易見(jiàn)，有另外一個(gè)人檢查即將提交的代碼，能夠幫助找到bug。這是代碼審查眾所周知且經(jīng)常被提及的好處。但依據(jù)我的經(jīng)驗(yàn)，這是最沒(méi)有價(jià)值的一個(gè)好處。人們確實(shí)可以在代碼審查中找到bug。然而坦率地說(shuō)，在代碼審查中找到的bug絕大多數(shù)都是一些代碼作者花上幾分鐘就能找到的小bug。那些真正需要花時(shí)間才能找到的bug在代碼審查中是檢查不到的。

　　代碼審查最大的好處在于它是一種社交的途徑。如果你編程的時(shí)候就知道會(huì)有同事檢查你的代碼，那么你的程序會(huì)有所不同。你寫的代碼會(huì)更加整潔，有著較好的注釋，結(jié)構(gòu)也組織的不錯(cuò)——因?yàn)槟阒罆?huì)有人來(lái)檢查你的代碼，而且你很在意他們的意見(jiàn)。如果沒(méi)有代碼審查，你知道代碼會(huì)在最后才會(huì)審查。因?yàn)椴皇邱R上就要檢查，所以對(duì)你而言并不緊迫，因而你不會(huì)想著先自檢一遍。

　　代碼審查還有一個(gè)更大的好處，就是可以分享知識(shí)。在很多的開(kāi)發(fā)團(tuán)隊(duì)中，每個(gè)人都會(huì)負(fù)責(zé)并且專注于一個(gè)核心模塊。除非別的同事負(fù)責(zé)的模塊出現(xiàn)問(wèn)題導(dǎo)致自己的代碼不能運(yùn)行，否則他們是不會(huì)去關(guān)注別人的工作。這樣產(chǎn)生的結(jié)果是，每一個(gè)模塊的代碼只有一個(gè)人比較熟悉。假如事不湊巧，那位程序員正好休假或者離開(kāi)了公司，那么沒(méi)有人了解那些代碼了。如果有代碼審查的環(huán)節(jié)，那么至少會(huì)有兩個(gè)人熟悉代碼——代碼的作者和審閱者。審閱者雖然沒(méi)有作者對(duì)代碼那么了解——但是他同樣熟悉代碼的設(shè)計(jì)和結(jié)構(gòu)，這些信息是無(wú)價(jià)之寶。

　　當(dāng)然，沒(méi)有什么事情是那么簡(jiǎn)單的。以我的的經(jīng)驗(yàn)看來(lái)，要做好代碼審查需要一段時(shí)間練習(xí)。我注意到經(jīng)驗(yàn)不足的審閱者通常會(huì)落入一些代碼審查的陷阱，這些陷阱往往會(huì)造成很多的麻煩，給那些希望嘗試代碼審查的人們留下了壞印象，成為了他們采納代碼審查的一個(gè)主要障礙。

　　代碼審查最重要規(guī)則是對(duì)即將提交的代碼中查找問(wèn)題——你需要做的就是確認(rèn)代碼是正確的。而通常會(huì)犯的一個(gè)錯(cuò)誤，也是剛剛接觸代碼審查的新手容易犯的一個(gè)錯(cuò)誤，即審閱者會(huì)判斷這段代碼是否按照自己思路來(lái)實(shí)現(xiàn)。

　　當(dāng)有一個(gè)問(wèn)題需要解決時(shí)，通常會(huì)有幾十種的辦法。當(dāng)選定一個(gè)解決方法時(shí)，會(huì)有百萬(wàn)種代碼實(shí)現(xiàn)。因此，作為一個(gè)審閱者，你的工作不是確保代碼是按照你的方式來(lái)編寫的——因?yàn)檫@是不可能的事情。審閱者的工作是確保原作者編寫的代碼是正確的。如果你沒(méi)有遵守這個(gè)規(guī)則，你可能會(huì)到處碰壁，審查結(jié)束時(shí)你的心情很糟糕，對(duì)你來(lái)說(shuō)肯定不是一件好事情。

　　問(wèn)題在于這是不自覺(jué)就會(huì)犯的一個(gè)錯(cuò)誤。假定你是一個(gè)程序員，當(dāng)你在看一個(gè)問(wèn)題的時(shí)候，你會(huì)得到一個(gè)自己的解決方案——并且你認(rèn)為你看到的就是這個(gè)問(wèn)題（應(yīng)該采用的）解決辦法。如果想要成為一名好的審查者，你需要知道這是不對(duì)的。

　　第二個(gè)誤區(qū)就是人們感覺(jué)一定要說(shuō)點(diǎn)什么（才算是做了代碼審查）。代碼的作者花了很多的時(shí)間和精力來(lái)編寫代碼——你難道不應(yīng)該說(shuō)點(diǎn)什么嗎？

　　答案是：你不應(yīng)該。

　　如果只是說(shuō)“哦，這看起來(lái)這不錯(cuò)！”，這永遠(yuǎn)沒(méi)錯(cuò)。反之，如果你不斷地去查找一些“問(wèn)題”并加以指責(zé)，那么我肯定你的信譽(yù)會(huì)蕩然無(wú)存。如果你不斷地去制造一些事情來(lái)說(shuō)些什么，那么代碼的作者會(huì)認(rèn)為，當(dāng)你的言論只是為了避免冷場(chǎng)。從此，你的意見(jiàn)不會(huì)受到重視。

　　第三個(gè)誤區(qū)就是速度。你不應(yīng)該匆忙完成一次代碼審查——但是也不要拖延。你的同事在那里等著你的審查結(jié)果。如果你和同事不愿意抽出時(shí)間來(lái)做代碼審查或者一直拖延，大家會(huì)對(duì)這次的審查感到厭煩，也會(huì)認(rèn)為以后的代碼審查也只會(huì)帶來(lái)麻煩?？雌饋?lái)好像代碼審查會(huì)打斷你的工作，其實(shí)不必如此。你不必要在別人要求你審查的時(shí)候馬上丟掉手頭上的事情。但是在幾個(gè)小時(shí)之內(nèi)，當(dāng)你工作中間休息的時(shí)候——喝杯茶，去一下洗手間或者聊聊天，散散步。當(dāng)你再回來(lái)工作的時(shí)候，你可以開(kāi)始并完成這個(gè)代碼審查。如果你這么做了，沒(méi)有人會(huì)站在你身邊一直等著你給出審查結(jié)果。

?

五、21世紀(jì)的代碼審查

?

在軟件工程領(lǐng)域里代碼審查可以結(jié)束程序員之間無(wú)謂的爭(zhēng)執(zhí)。開(kāi)發(fā)者常常會(huì)因?yàn)橐恍┯薮赖男∈露纷?#xff0c;冒犯對(duì)方，甚至是在Q&A問(wèn)答之前抓住Bug而喋喋不休，爭(zhēng)執(zhí)總是圍繞在你左右。OK，千萬(wàn)不要誤會(huì)我的意思，因?yàn)槲覀冇欣碛上嘈糯a審查絕對(duì)是個(gè)不錯(cuò)的好方法。原因如下：

1. 越早發(fā)現(xiàn)bug也就意味著可降低項(xiàng)目成本。無(wú)須釋放一個(gè)修復(fù)補(bǔ)丁，因?yàn)樗幵陂_(kāi)發(fā)階段。

2. 代碼變得越來(lái)越重要。

3. 知識(shí)貫穿于你的團(tuán)隊(duì)中，不再像以前那樣一大塊代碼只有某一個(gè)人知道。

4. 開(kāi)發(fā)者需要加倍的努力。如果開(kāi)發(fā)者知道別人要對(duì)他的工作進(jìn)行評(píng)估時(shí)，就會(huì)采取額外的努力做好工作，同時(shí)他還喜歡用文檔注釋標(biāo)出異議。

如今，在21世紀(jì)的今天很多項(xiàng)目都沒(méi)有使用代碼審查。本文將提供8條準(zhǔn)則，供開(kāi)發(fā)者學(xué)習(xí)與參考。

1. 永遠(yuǎn)別忘了TDD

再確認(rèn)測(cè)試代碼前，先找別人幫你檢查下是否無(wú)誤。在別人做之前盡量檢查出bug并且將其處理好。代碼審查最重要規(guī)則是對(duì)即將提交的代碼中查找問(wèn)題——你需要做的就是確認(rèn)代碼是正確的。

2.盡可能的自動(dòng)化

這里有幾個(gè)非常好的Java工具比如：PMD, Checkstyle, Findbugs等等。問(wèn)題是當(dāng)利用這些工具查找后人們還肯花時(shí)間去做代碼審查嗎？

使用這些工具前，為這些工具制定一套細(xì)則是非常重要的。這能夠確保你使用同一個(gè)代碼審核標(biāo)準(zhǔn)從而區(qū)別于那些常被用于20世紀(jì)老式的代碼審查規(guī)范。在理想的狀態(tài)下，這些工具可運(yùn)行在各種版本控制系統(tǒng)上通過(guò)hook審查每個(gè)代碼。如果該代碼不好將被阻止在外。

3.尊重設(shè)計(jì)

在我開(kāi)始從事Java項(xiàng)目早期時(shí)，用代碼審查的方式已為時(shí)已晚。因?yàn)楫?dāng)你檢查代碼問(wèn)題時(shí)實(shí)際上給你的設(shè)計(jì)造成了缺陷。設(shè)計(jì)模式被誤解，一些繁雜的附屬物質(zhì)混入進(jìn)來(lái)或者開(kāi)發(fā)者脫離了主題。

審查會(huì)混亂你的觀點(diǎn)。或許你會(huì)反駁：“這是代碼審查而不是設(shè)計(jì)審查”。這時(shí)一些爛攤子必然會(huì)接踵而至。為了避免這些問(wèn)題發(fā)生，我們改變了設(shè)計(jì)的初衷。代碼審查會(huì)牽連到很多面，無(wú)論是設(shè)計(jì)還是設(shè)計(jì)審查。事實(shí)上，我們通過(guò)設(shè)計(jì)審查要比代碼審而得多的沖擊要多的多。設(shè)計(jì)需要更高的質(zhì)量和靈感，我們應(yīng)該避免一些復(fù)雜的思維。

4. 統(tǒng)一的風(fēng)格指南

即使是使用自動(dòng)化工具（諸如Checkstyle，Findbugs等）也應(yīng)避免不必要的風(fēng)格沖突，你的項(xiàng)目應(yīng)該具備有風(fēng)格指南。（在盡可能的情況下）堅(jiān)持Java協(xié)議的規(guī)范標(biāo)準(zhǔn)。嘗試著為你的項(xiàng)目介紹制定一個(gè)“詞典”，這就意味著，當(dāng)涉及這個(gè)代碼時(shí)，查看該代碼的用法和環(huán)境是否適宜，這些都很容易被檢測(cè)出。

5. 挑選適宜的工具

如果開(kāi)發(fā)者都在使用Eclipse開(kāi)發(fā)工具（ Eclipse IDE插件Jupiter），你可以通過(guò)你的方式來(lái)查看代碼、調(diào)試代碼甚至可使用Eclipse IDE上的一切東西當(dāng)來(lái)幫助你在審查代碼時(shí)更加的便捷。但是，如果大家沒(méi)有使用同一個(gè)IDE（或者該IDE沒(méi)有給你的工作帶來(lái)方便）你可以考慮Review Board. ，它是個(gè)不錯(cuò)的選擇。

6.請(qǐng)記住每個(gè)項(xiàng)目都不同

也許你在采用以前的項(xiàng)目方法工作，但是，請(qǐng)記住每個(gè)項(xiàng)目之間是不同的。每一個(gè)項(xiàng)目都有特定的架構(gòu)（高并發(fā)或是高分散），有特定的文化（或許很多人喜歡使用Eclipse），并使用特定的工具（maven or ant）。難道你想照葫蘆畫瓢？OK，請(qǐng)記住，不同的項(xiàng)目有不同的工作方法。

7.懂得取舍

代碼審查需要積極和細(xì)致而不是賣弄學(xué)問(wèn)。你會(huì)因?yàn)橐恍┘?xì)微的瑣事讓你緊張而導(dǎo)致項(xiàng)目失敗或是花費(fèi)公司成本嗎？記住，千萬(wàn)不要這樣。理清頭緒，換個(gè)角度想想，改變自己的心態(tài)而不是記掛著去改變別人。

8. Be buddies

在我看來(lái)，稱之為“buddy reviews”（別人會(huì)叫“over the shoulder”）非常好。A buddy review是指與其他團(tuán)隊(duì)成員每隔一到兩天以非正式的形式討論，并且快速的瀏覽（5-10分鐘）對(duì)方的代碼。這種方法可以幫助你：

1. 及早的發(fā)現(xiàn)問(wèn)題

2. 總是很快的知道該干什么

3. 代碼審查無(wú)須過(guò)長(zhǎng)，因?yàn)槟阒恍枰榭葱碌拇a，舊的代碼會(huì)很快趕上

4. 這種非正式的場(chǎng)合——沒(méi)有緊張感，很有趣！

5. 可以定期的交換想法

buddy reviewing在團(tuán)隊(duì)中是一種很好的工作方式，當(dāng)某人在團(tuán)隊(duì)中出現(xiàn)問(wèn)題時(shí)可以及早的發(fā)現(xiàn)。這不僅可以幫助大家，還可以交換彼此的進(jìn)度和想法。

總之，如果你的項(xiàng)目正在進(jìn)行代碼審查，應(yīng)該做到快速、有效、不浪費(fèi)別人的時(shí)間。正如文章所說(shuō)的，這幾點(diǎn)非常重要。代碼審查用意是在代碼提交前找到其中的問(wèn)題。

六、代碼審查
代碼審查可以幫助提高代碼質(zhì)量，避免由于代碼習(xí)慣而造成的 bug。下面列出的這些要點(diǎn)因該可以作為大部分代碼審查的指導(dǎo)，如果是 Java 應(yīng)用的話，這些建議應(yīng)該被視作最佳實(shí)踐。

文檔
1. Javadoc 應(yīng)該在每一個(gè)類和方法中添加。
2. 如果是修復(fù)某個(gè) bug，應(yīng)該添加 bug ID。
3. 走捷徑的方法或者復(fù)雜的邏輯要有解釋。
4. 如果代碼會(huì)被公開(kāi)，每個(gè)文件頭都要標(biāo)注版權(quán)信息。
5. 復(fù)雜的 HTML，JavaScript，CSS 應(yīng)該包含文檔。

功能
1. 如果類似的邏輯被使用了多次，應(yīng)該把它寫成一個(gè)幫助類，然后在多出調(diào)用。
2. 鼓勵(lì)使用 API 而不是重復(fù)編寫代碼解決相同的問(wèn)題。
3. 要強(qiáng)調(diào)代碼的單元測(cè)試。
4. 任何新加的代碼不應(yīng)該破壞已有的代碼。
5. 假如是 Web 應(yīng)用，JSP 不應(yīng)該包含 Java 代碼。

安全
1. 任何代碼都不能執(zhí)行用戶的輸入，除非轉(zhuǎn)義過(guò)了。這個(gè)常常包含 JavaScript 的 eval 函數(shù)和 SQL 語(yǔ)句。
2. 禁止那些在短時(shí)間內(nèi)提交非常多請(qǐng)求的 IP。
3. 任何類，變量，還有方法都應(yīng)該有正確的訪問(wèn)域。
4. 盡量避免使用 iframe。

性能
1. 所有數(shù)據(jù)庫(kù)和文件操句柄在不需要的時(shí)候都應(yīng)該被關(guān)閉。
2. SQL 語(yǔ)句的寫法會(huì)導(dǎo)致性能千差萬(wàn)別。
3. 鼓勵(lì)創(chuàng)建不可變（immutable）的類。
4. 類似的邏輯代碼，盡量通過(guò) if else 語(yǔ)句來(lái)實(shí)現(xiàn)更多的重用。
5. 盡量避免使用重對(duì)象（heavy objects）。
6. 如果是 Web 項(xiàng)目，請(qǐng)檢查是否使用了合適的圖片尺寸，CSS sprites 和瀏覽器緩存等技術(shù)。
7. 全局都需要的信息保存在 application context 中。

編碼習(xí)慣
1. 沒(méi)有被使用的變量要?jiǎng)h除。
2. 針對(duì)不同的 Exception 要用不同的 catch 語(yǔ)句，而不是一個(gè) Exception 解決所有問(wèn)題。
3. 針對(duì)變量，方法和類要用相同的命名方法。
4. 常量應(yīng)該被寫在獨(dú)立的常量類中。
5. 每行代碼的尾部不要有多余的空格。
6. 對(duì)于括號(hào)，循環(huán)，if語(yǔ)句等等要用統(tǒng)一的格式。
7. 每一個(gè)單獨(dú)的方法不應(yīng)該超過(guò)100行。
8. 一個(gè)單獨(dú)的語(yǔ)句不應(yīng)該超過(guò)編輯器的可視區(qū)域，它可以被拆分成幾行。
9. 檢查 String 對(duì)象既不是null也不是空的最好方法是 if(“”.equals(str))
10. 假如類有很多成員變量，并且實(shí)例化的時(shí)候只需要少數(shù)變量傳入的話，最好使用靜態(tài)工廠方法，而不是重載構(gòu)造函數(shù)。
11. 給方法添加適當(dāng)?shù)脑L問(wèn)控制，而不是所有都是 public。
12. 遵守項(xiàng)目中使用的框架的最佳實(shí)踐建議，例如 Spring，Struts，Hibernate，jQuery。

以上的某些注意點(diǎn)可以通過(guò)靜態(tài)代碼檢查工具完成，例如 CheckStyle，FindBugs 和 JTest。

?

原文地址：http://www.eoeandroid.com/thread-257098-1-1.html

總結(jié)

以上是生活随笔為你收集整理的高效代码审查的八条准则和十个经验的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。