數百萬年前，猿猴從樹上繁衍出來，進化出對向性拇指（譯者注，對向性拇指即拇指與其他四指對合，結果可以拿握東西），最終成爲人類。
我們以類似的方式看到強制的代碼審查：在軟件開發大草原地的翻滾的草原上將人與獸區分開來。
儘管如此，我有時還是聽到我們團隊成員的評論：
- “對該項目進行代碼審查是浪費時間。”
- “我沒有時間進行代碼審查。”
- “我的發佈被推遲了，因爲我懦弱的同事還沒有完成我的審查。”
- “你能相信我的同事希望我更改我的代碼嗎？請向他們解釋，如果以任何方式更改我原始的優雅代碼，宇宙的脆弱平衡將被破壞。”
我們爲什麼要進行代碼審查？
首先，讓我們記住爲什麼我們要進行代碼審查。任何專業軟件開發人員最重要的目標之一是持續提高他們的工作質量。即使你的團隊擠滿了有才華的程序員，你也不會把你自己與有能力的自由職業者區分開來，除非你作爲一個團隊工作。代碼審查是實現此目標的最重要方法之一。特別是，它們：
- 提供另一雙眼睛以發現缺陷和更好的做事方法。
- 確保至少有其他人熟悉你的代碼。
- 通過向新員工展示更有經驗的開發者的代碼來幫助培訓他們。
- 通過向審閱者和受審者展示彼此的好主意和實踐來促進知識共享。
- 鼓勵開發人員做得更徹底，因爲他們知道它將由他們的一位同事進行審查。
做徹底的審查
但是，除非花費適當的時間和精力進行審查，否則無法實現這些目標。僅滾動修改，確保縮進正確並且所有變量均使用小寫的駝峯字母，並不構成對代碼的徹底審查。考慮結對編程是很有益性的，這是一種非常流行的做法，並且將所有開發時間的開銷增加了100％，以此作爲代碼審查工作的基準。你可以在代碼審查上花費大量時間，並且仍然比結對編程花費更少的全部的工程師時間。
我的感覺是，大約25％的原始開發時間應該花在代碼審查上。例如，如果開發人員花兩天的時間來實施故事，則審閱者應花大約四個小時來審閱它。
當然，只要檢查正確完成，你花費多少時間在檢查上並不重要。具體來說，你必須理解你要檢查的代碼。這不僅意味着你知道其編寫語言的語法。這還意味着你必須瞭解代碼如何適合其所包含的應用程序，組件或庫的情形。如果你沒有掌握每一行代碼的所有含義，那麼你的審查將不會很有價值。這就是爲什麼不能快速進行良好檢查的原因：花時間調查可能觸發給定功能的各種代碼路徑，以確保正確使用了第三方API（包括任何邊緣情況）等等。
除了在正在檢查的代碼中查找缺陷或其他問題之外，你還應確保：
- 包括所有必要的測試。
- 已經編寫了適當的設計文檔。
儘管是擅長編寫測試和文檔的開發人員也不總是記得在更改代碼時對其進行更新。在適當的時候，代碼審閱者輕微地勸說對於確保它們不會隨着時間的過去變得陳舊是重要的。
防止代碼審查負擔過重
如果你的團隊執行強制性代碼審查，則存在代碼審查積壓到無法管理的程度的危險。如果你兩週未進行任何評論，你能夠輕鬆用幾天去審查以追趕進度。這意味着當你最終決定處理它們時，你自己的開發工作將遭受巨大而意想不到的打擊。由於適當的代碼審閱需要大量而持續的腦力勞動，這也使得進行良好的審查變得困難。很難連續幾天維持這種狀態到結束。
因此，開發人員應每天努力清空他們的審查任務。一種方法是在早上第一時間處理審查。通過在開始自己的開發工作之前進行所有未完成的審查，可以避免審查情況失控。有些人可能更喜歡在午休之前或之後或一天結束時進行審查。無論你什麼時候進行，通過將代碼審查作爲日常工作的一部分，而不是消遣，你要避免：
- 沒有時間處理你的審查任務。
- 由於你的審查尚未完成而推遲發佈。
- 發起不再相關的審查，因爲代碼在此期間發生了很大變化。
- 進行不完善的審查，因爲你必須在最後一刻匆匆完成。
編寫可審查的代碼
審查者並非總是審查任務失控的唯一責任人。如果我的同事花一個星期在一個大型項目中隨意添加代碼，那麼他們發佈的修改將很難審查。完成這個會議將有太多難處。理解代碼的目的和基礎架構將會是困難的。
這是爲什麼將你的工作分成可管理的單元很重要的許多原因之一。我們使用Scrum方法論，因此適合我們的單元就是故事。通過努力按故事的方式組織我們的工作並提交僅與我們正在研究的特定故事相關的審查，我們編寫了易於審查的代碼。你的團隊可能會使用其他方法，但是原理是相同的。
編寫可審閱的代碼還有其他先決條件。如果要做出靈活的結構決策，那麼事先與審閱者進行討論是有意義的。這將使審閱者更容易理解你的代碼，因爲他們將知道你要實現的目標以及你打算如何實現。這也有助於避免在審閱者提出不同的更好的方法之後，你必須重寫大量代碼的情況。
項目架構應在設計文檔中進行詳細描述。無論如何，這是重要的，因爲它使新項目成員可以加快速度並瞭解現有代碼庫。它還有更好的優點，可以幫助審查人去更好地工作。在向審查者闡述組件是如何工作這方面，單元測試也是有用的。
如果你的代碼中包含第三方代碼，請分別提交。當將9000行jQuery放到中間時，要正確地檢查代碼是非常困難的。
創建可審查代碼的最重要步驟之一是爲你的代碼審查添加註釋。這意味着你在進行自我審查，並在你認爲會幫助審查者理解什麼在發生的任何地方添加註釋。我發現對代碼進行審查註釋需要相對較少的時間（通常只需幾分鐘），並且對更快更好地審查代碼影響巨大。當然，代碼註釋具有許多相同的優點，並應該用在適合的地方，但審查註釋更有意義。另外，研究表明，開發人員在重讀和審查註釋代碼時會發現自己代碼中的許多缺陷。
大型代碼重構
有時，以影響許多組件的方式重構代碼庫是必要的。對於大型應用程序，這可能需要幾天（或更多），並且會產生巨大的修改。在這些情況下，標準的代碼審查可能不切實際。
最好的解決方案是增量重構代碼。在正在工作的代碼並中，找出你想去的那個方向的的合理範圍內的部分修改。一旦完成更改併發起審查，進行第二次增量更改，依此類推，直到完成整個重構。這並不總是可能的，但是這種想法和計劃通常是現實的，當重構時避免大量的修改。開發人員以這種方式重構可能會花費更多時間，但它也可以提高代碼質量，並使審查變得更加容易。
如果確實不可能以增量方式重構代碼（這可能說明出原始代碼的編寫和組織的情況），一種解決方案可能是在進行重構時執行結對編程而不是代碼審查。
解決糾紛
毫無疑問，你的團隊是由聰明的專業人員組成，並且在幾乎所有情況下，當對指定編碼問題的意見不同時，應該是可能達成一致。作爲開發人員，請保持開放的想法，並準備妥協，當你的審查者更傾向於一個不同的方法時。不要對你的代碼採取固有態度，也不要親自查看評論。僅僅因爲有人認爲你應該將某些重複的代碼重構爲可重用的函數，這並不意味着你就不再是一個有吸引力，聰明而有魅力的人。
作爲審查者，要機智。在提出更改建議之前，請考慮你的建議是否真的更好，或者只是個人看法。如果你選擇奮鬥並專注於原始代碼明顯需要改進的區域，那麼你將獲得更大的成功。諸如說“它可能值得考慮…”或“有人推薦…”之類的內容，而不是“我的寵物倉鼠可以編寫比這更有效的排序算法”。
如果你真的找不到中立的立場，那麼找兩個你尊重的第三方開發人員來看看並提出他們的意見。
原文：http://blog.salsitasoft.com/practical-lessons-in-peer-code-review/