本文轉(zhuǎn)載自：http://blog.csdn.net/marchbirdcode/article/details/4801978

如需看原文，請看上面的鏈接。

?

從種種渠道可以知道，Google的代碼之所以優(yōu)秀，原因很簡單，他們非常重視代碼審查。這個(gè)方法不是Google獨(dú)有的，它被公認(rèn)是一個(gè)提高代碼質(zhì)量的手段。在Google，任何產(chǎn)品或者項(xiàng)目代碼在撿入倉庫之前，都需要進(jìn)行有效的審查。

每個(gè)人，如果有意愿的話，都要參加代碼審查，它是軟件開發(fā)環(huán)節(jié)中非常重要而且通用的規(guī)則。審查代碼，不需要投入很多精力，但是，與不做審查相比，產(chǎn)生的效果卻是天壤之別。我們越早發(fā)現(xiàn)代碼存在的缺陷，解決缺陷的代價(jià)就越低。

不要把別人的檢查，看成是對(duì)代碼風(fēng)格的苛求。

對(duì)個(gè)人來說，經(jīng)常檢查你的代碼并且自問“我怎樣才能寫的更好？”這會(huì)加速你的成長。

?

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

自己的看法：在審查前，自己肯定是檢查過一次，顯而易見的Bug是不出現(xiàn)在審查代碼中。鑒于審查時(shí)間的長短，被審查者收獲什么，別人對(duì)自己思路的認(rèn)同？別人對(duì)自己代碼的看法？我覺的，應(yīng)該由被審查者先講述自己這段代碼要解決什么問題，采用了什么樣的方法，然后再給別人看流程圖，最后結(jié)合流程圖看代碼。
　　代碼審查最大的好處在于它是一種社交的途徑。如果你編程的時(shí)候就知道會(huì)有同事檢查你的代碼，那么你的程序會(huì)有所不同。你寫的代碼會(huì)更加整潔，有著較好的注釋，結(jié)構(gòu)也組織的不錯(cuò)——因?yàn)槟阒罆?huì)有人來檢查你的代碼，而且你很在意他們的意見。如果沒有代碼審查，你知道代碼會(huì)在最后才會(huì)審查。因?yàn)椴皇邱R上就要檢查，所以對(duì)你而言并不緊迫，因而你不會(huì)想著先自檢一遍。

自己的看法：代碼審查的時(shí)機(jī)？是解決完一個(gè)問題就審查還是在入庫時(shí)才審查？我覺的應(yīng)該是在入庫時(shí)來審查，鑒于部門人數(shù)眾多，一一審查是不可能的，可以采取每周抽查兩個(gè)人，在整個(gè)部門中，由他們來講解自己代碼中的一部分，感興趣的人都來聽。其余的入庫，只需要和自己的上司提交審查請求就可以了，每周至少保持一次。
　　代碼審查還有一個(gè)更大的好處，就是可以分享知識(shí)。在很多的開發(fā)團(tuán)隊(duì)中，每個(gè)人都會(huì)負(fù)責(zé)并且專注于一個(gè)核心模塊。除非別的同事負(fù)責(zé)的模塊出現(xiàn)問題導(dǎo)致自己的代碼不能運(yùn)行，否則他們是不會(huì)去關(guān)注別人的工作。這樣產(chǎn)生的結(jié)果是，每一個(gè)模塊的代碼只有一個(gè)人比較熟悉。假如事不湊巧，那位程序員正好休假或者離開了公司，那么沒有人了解那些代碼了。如果有代碼審查的環(huán)節(jié)，那么至少會(huì)有兩個(gè)人熟悉代碼——代碼的作者和審閱者。審閱者雖然沒有作者對(duì)代碼那么了解——但是他同樣熟悉代碼的設(shè)計(jì)和結(jié)構(gòu)，這些信息是無價(jià)之寶。
　　當(dāng)然，沒有什么事情是那么簡單的。以我的的經(jīng)驗(yàn)看來，要做好代碼審查需要一段時(shí)間練習(xí)。我注意到經(jīng)驗(yàn)不足的審閱者通常會(huì)落入一些代碼審查的陷阱，這些陷阱往往會(huì)造成很多的麻煩，給那些希望嘗試代碼審查的人們留下了壞印象，成為了他們采納代碼審查的一個(gè)主要障礙。
　　代碼審查最重要規(guī)則是對(duì)即將提交的代碼中查找問題——你需要做的就是確認(rèn)代碼是正確的。而通常會(huì)犯的一個(gè)錯(cuò)誤，即審閱者會(huì)判斷這段代碼是否按照自己思路來實(shí)現(xiàn)。
　　當(dāng)有一個(gè)問題需要解決時(shí)，通常會(huì)有幾十種的辦法。當(dāng)選定一個(gè)解決方法時(shí)，會(huì)有百萬種代碼實(shí)現(xiàn)。因此，作為一個(gè)審閱者，你的工作不是確保代碼是按照你的方式來編寫的——因?yàn)檫@是不可能的事情。審閱者的工作是確保原作者編寫的代碼是正確的。如果你沒有遵守這個(gè)規(guī)則，你可能會(huì)到處碰壁，審查結(jié)束時(shí)你的心情很糟糕，對(duì)你來說肯定不是一件好事情。
　　問題在于這是不自覺就會(huì)犯的一個(gè)錯(cuò)誤。假定你是一個(gè)程序員，當(dāng)你在看一個(gè)問題的時(shí)候，你會(huì)得到一個(gè)自己的解決方案——并且你認(rèn)為你看到的就是這個(gè)問題（應(yīng)該采用的）解決辦法。如果想要成為一名好的審查者，你需要知道這是不對(duì)的。
　　第二個(gè)誤區(qū)就是人們感覺一定要說點(diǎn)什么（才算是做了代碼審查）。

代碼的作者花了很多的時(shí)間和精力來編寫代碼——你難道不應(yīng)該說點(diǎn)什么嗎？
　　答案是：你不應(yīng)該。
　　如果只是說“哦，這看起來這不錯(cuò)！”，這永遠(yuǎn)沒錯(cuò)。反之，如果你不斷地去查找一些“問題”并加以指責(zé)，那么我肯定你的信譽(yù)會(huì)蕩然無存。如果你不斷地去制造一些事情來說些什么，那么代碼的作者會(huì)認(rèn)為，當(dāng)你的言論只是為了避免冷場。從此，你的意見不會(huì)受到重視。

自己的看法：在審查過程中，多提問題，不要把自己想的那一套強(qiáng)加在別人身上，以提問的方式，來了解別人的設(shè)計(jì)思路和策略，這就像，一人一個(gè)想法，相互交換了，每個(gè)人就有了兩個(gè)想法，思路也是一樣的，尊重別人的思維成果，即使它還不完善，還有漏洞。
　　第三個(gè)誤區(qū)就是速度。

你不應(yīng)該匆忙完成一次代碼審查——但是也不要拖延。

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

自己的看法：在部門的代碼審查上，建議時(shí)間保持在30分鐘左右，第一，不要浪費(fèi)大家的時(shí)間.第二，３０分鐘，１０分鐘講思路和流程圖，１０分鐘介紹代碼，還有１０分鐘接收提問。這樣的時(shí)間分配，應(yīng)該還是比較合理的。在個(gè)人的代碼審查上，時(shí)間因人而定，能夠疏通邏輯、答疑解惑一兩個(gè)點(diǎn)就可以了。

-------------------------------10-17更新分割線-------------------------------------------

本次更新來自：代碼走讀常規(guī)流程

代碼審查的內(nèi)容：代碼風(fēng)格、常規(guī)缺陷、業(yè)務(wù)邏輯缺陷、設(shè)計(jì)邏輯和思路的審查。

審查原則是確保正確性、可復(fù)用性、可擴(kuò)展性、可維護(hù)性和可讀性。

理解代碼的意圖和發(fā)現(xiàn)問題，這兩件事情，前一件要在開始之前，通過某種方式告知參與人員，先按自己的思路理解程序的邏輯，然后標(biāo)注出找出的問題并且記錄下來。

可能下面的需要一定的專業(yè)工具來審查，我不是特別了解，希望以后的公司，能夠有這種好的確保質(zhì)量的規(guī)范制度。

轉(zhuǎn)載于:https://www.cnblogs.com/cherishui/p/4029465.html

總結(jié)

以上是生活随笔為你收集整理的代码走读的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

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