本文轉載自：http://blog.csdn.net/marchbirdcode/article/details/4801978

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

?

從種種渠道可以知道，Google的代碼之所以優秀，原因很簡單，他們非常重視代碼審查。這個方法不是Google獨有的，它被公認是一個提高代碼質量的手段。在Google，任何產品或者項目代碼在撿入倉庫之前，都需要進行有效的審查。

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

不要把別人的檢查，看成是對代碼風格的苛求。

對個人來說，經常檢查你的代碼并且自問“我怎樣才能寫的更好？”這會加速你的成長。

?

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

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

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

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

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

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

你的同事在那里等著你的審查結果。如果你和同事不愿意抽出時間來做代碼審查或者一直拖延，大家會對這次的審查感到厭煩，也會認為以后的代碼審查也只會帶來麻煩。看起來好像代碼審查會打斷你的工作，其實不必如此。你不必要在別人要求你審查的時候馬上丟掉手頭上的事情。但是在幾個小時之內，當你工作中間休息的時候——喝杯茶，去一下洗手間或者聊聊天，散散步。當你再回來工作的時候，你可以開始并完成這個代碼審查。如果你這么做了，沒有人會站在你身邊一直等著你給出審查結果。

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

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

本次更新來自：代碼走讀常規流程

代碼審查的內容：代碼風格、常規缺陷、業務邏輯缺陷、設計邏輯和思路的審查。

審查原則是確保正確性、可復用性、可擴展性、可維護性和可讀性。

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

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

轉載于:https://www.cnblogs.com/cherishui/p/4029465.html

總結

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

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。