轉自：http://www.iteye.com/news/30235

理論我知道。代碼審查（Code Review）有助于：?

• 抓bug
• 保證代碼的可讀性，可維護性
• 在團隊中散播代碼的知識
• 讓新人適應團隊的工作方式
• 讓大家接觸不同的思路

或者按另一種看法，代碼審查就是極大的浪費時間。至少我對代碼審查的最初感受就是這樣。?

當時我是新人，剛畢業，在倫敦一家軟件公司開發插件。?

隨著時間推移，我得提交大量樣子都差不多或干脆一樣的代碼。另一個可憐的家伙（“他是最好的。”我的經理告訴我。好在哪兒啊……）會來Review我的代碼。而每次審查之后都會返回不一樣的結果。看起來都是全無必要的挑剔又主觀的結果。?

更糟的是，審查過程的時間，哪怕沒有幾周，也得有好幾天。等代碼返回給我的時候，我幾乎都記不得那是我寫的。這不是那個家伙的錯。他肯定也想要個更有經驗的開發者，不過他分到了我。他厭倦了處理每個沒經驗的開發者搞出的那些低級問題，代碼審查過程變成了他祛除沮喪情緒的方式。?

再加上這些浪費的時間：不同分支的代碼同步，上下文切換……我不是代碼審查的粉兒，團隊其他人也一樣。?

幾年之后，我發現我很同意Jeff Atwood所發表的推特：?

引用 “結對代碼審查是你能改進代碼質量的唯一要事。”

經過這幾年的時間我開始贊同代碼審查，是因為我發現了代碼審查并不是壞事，代碼審查執行不好才是壞事。伙計，我們就執行的很不好。?

我付出了慘痛代價才意識到這一點。當然不是一夜之間的轉變。反思之后，代碼審查把我從尷尬的，足以破壞構建的代碼修改中拯救出來不少回。而自從我在其他地方工作后，我積累了一些和以前不同的、更好的工作方式的經驗。這給了我機會，讓我能切身體會到我以前曾錯過的代碼審查的好處。所以現在我認為自己是一個皈依了的質疑者。?

為了你能避免這些痛苦，看看我們的視頻，讀完這些建議，這樣就能帶給你更有效的代碼審查過程。?
一、寫給所有人的： ?

1.只審查正確的東西，讓工具干別的 ?

你不需要在代碼風格和格式問題上與人爭論。有大量的工具可以持續地強調這些內容。確保代碼正確、易于理解和可維護性強才是重要的。當然了，編碼風格和格式也是這些的一部分，只是你更應該讓工具去檢查。?

2.所有人都該做代碼審查 ?

一些人比另一些人更擅長審查。更有經驗的人可以發現更多的bug，這很重要。不過更重要的是在總體上維持一個針對代碼審查的積極態度，也就是說要避免任何“我們和他們”的對抗態度，或者是讓代碼審查成為某個人的負擔。?

3.審查所有的代碼 ?

沒有代碼是因為太短或者太簡單而不值得審查。當你審查一切，就沒有什么會漏掉。另外這樣做會成為流程的一部分，成為一種習慣，而不總是事后諸葛。?

4.態度積極 ?

這一點對審查者和提交者都很重要。代碼審查不是你要拿全A，發動代碼神技的時候，也不是你需要擺出防御姿態的時候。帶著對建設性批評的積極態度投入進去，你就可以在此過程中收獲信任。?
二、寫給對審查者的： ?

5.代碼審查應該短期高頻 ?

你的審查效率在一個小時后開始下降。所以推遲審查共走，然后在一個極限的周期內趕完對誰也沒用。在你的一天中留出時間來定期處理，別打亂自己的工作節奏并養成習慣。你的同事會為此而感謝你。等待會讓人沮喪。而且當代碼還新鮮的保存在他們腦海里時，他們解決問題也會快一些。?

6.It’s OK to say “It’s all good” |“都挺好”挺好 ?

別太挑剔了，你不是一定要每次審查都發現問題。?

7.使用一個清單 ?

代碼審查清單 確保一致性——每個人都了解哪些是重要的，哪些是常見錯誤。?
三、寫給代碼提交者的 ?
8.保證代碼簡短 ?

超過200行，審查效率就會顯著下降。一旦你超過400行，那基本就沒什么意義了。?

9.提供上下文 ?

要提供相關的單子，或者規格說明的鏈接。像Kiln這樣的代碼審查工具可以提供幫助。應提供簡短而有用的提交信息，在代碼中留下大量注釋。這會幫助審查者，你得到的問題反饋也會少一些。

總結

以上是生活随笔為你收集整理的高效代码审查：来自前质疑者的9个建议的全部內容，希望文章能夠幫你解決所遇到的問題。

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