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