[我的翻譯]效代碼審查：來自前質疑者的9個建議

譯者說明：本文由 伯樂線上 - drowzju 翻譯，黃利民 校稿。未經許可，禁止轉載！

英文出處：Gareth Wilson。

理論我知道。代碼審查（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這樣的代碼審查工具可以提供幫助。應提供簡短而有用的送出資訊，在代碼中留下大量注釋。這會幫助審查者，你得到的問題回報也會少一些。