代碼審查，本身應該是一個相互合作，相互學習，整合團體動力，最終卻以消極和敵意為代價向前發展。這種現象是如何造成的，我們又該如何克服呢？原文作者Erik Dietrich給出了一些見解。譯文如下：

　　前不久，我收到一封有關討論代碼審查的郵件，對方對其抱著無所謂的態度，我想這可能是大部分人持有的態度，這也一直是大多數的代碼審查的面臨的尷尬狀況，但不是全部。與其冒著把孩子與洗澡水一起倒掉的風險，那不如干脆不要把洗澡水弄臟。我的意思是，完全杜絕糟糕的代碼審查。

　　雞蛋里挑骨頭和無意義的討論

　　我想我們大多數人都同意，沒有什么比花一兩個小時的爭論是否要使用隱式類型，或是拋出ArgumentNullException還是NullReferenceException異常更無聊了。為什么不讓你的代碼審查變成那樣呢？你可以不用擔憂大局，僅僅進行哲學討論，如代碼的可讀性和易維護性。那些曾將代碼審查作為學習和合作的機會的人，很快就會意識到，他們只會關注細節上主觀意見分歧激烈的地方。

　　居高臨下和嘲諷

　　在正常的代碼審查中，一般會指出一個可能的邏輯錯誤，但千萬不用止步于此。如果錯誤可以驅動開發，那么添加一句“是個人都不會忘記這點”的評論會讓他們更加印象深刻。代碼審查是項單向活動，不用擔心他們回過頭來找你算賬。所以還不如讓“撕裂般的侮辱摧殘他們的自信心”。他們也會期待著有一天，像你一樣羞辱未來的初級開發者。

　　讓審查沒完沒了

　　一點點代碼審查算是“還不錯”，那10小時的馬拉松會是“非常棒”。請確保您審查了每一行代碼，每一個配置文件的改變，每一個標記標簽，每個自動重構。如果你曾把事情搞砸或者其他開發人員已經審查的代碼，或者審查一個甚至沒有寫的代碼的經驗，一定會有加分。如果開發者不能確保把每個字符都加入到代碼庫中就懲罰他們，像博士畢業論文答辯一樣嚴格要求。

　　保證所有審查必須“通過”

　　當你將情景設置為“教授和學生”，你不妨繼續制定“審查必須通過”的政策。這樣一來，它就不是一個專業團隊檢討彼此的工作，并提出批評，建議和見解，而是一個被嚇壞了的初級開發人員試圖找出這次發布的版本中做的不夠好的地方。為什么不能把每個開發/循環/發布搞得像參加SAT考試一樣隆重呢？

　　以事實定位你的意見

　　只是你個人覺得靜態方法比實例方法更好嗎？當然不是。這是一個事實。想想你帶有個人偏好的設計模式，編碼方法，風格等的，然后去掉類似“我認為”，“我喜歡”，或者“在我看來”等修飾語，將“我喜歡用下劃線命名字段名”變成“你應該用下劃線命名你的字段名”和“我覺得你的參數很混亂”變成“我們的參數很混亂”。不管你做什么，不需要有任何證據或引用說明。當你告訴別人，他們的代碼太長了，他們會問：“哪里太長了？”不用列舉任何有關方法的長度和增加缺陷數成正比關系的研究，只消說“我是高級程序員，而你的代碼比我長。”

　　逃避所有可以很容易地自動檢查出的錯誤

　　為什么要花費一天時間坐在一個狹小的會議室，尋找是否有人犯了采用Camelcase命名而不是Pascalcase命名方法的大罪呢？你可以一行一行地數方法的代碼行數，甚至通過手工計算循環的復雜度。當然，有很多工具可以在幾秒鐘內可以做任何你想做的事情，但這樣就失去了公開指責初級開發人員錯誤的機會了。

　　保持消極

　　一點點積極的鼓勵都會激勵整個項目的進度，代碼審查其實有很多這樣的機會，因為你可以看到很多新的做事方法。正因為如此所以，你必須要小心，至始至終保持消極。使用白板或電子表格列出別人的錯誤，并且多多益善。隧道的盡頭的燈只為懦夫照亮。

　　結語

　　我相信，良好的代碼審查需要一致協作。如果發現了錯誤，你不需要直接告訴別人他們錯了，換成“你覺得，如果我傳遞null給這個方法會怎么樣呢？”就足夠了，別人可能會說“哦，這個我沒考慮到，我馬上解決它。”讓他們自己意識到錯誤并提出改進的方法會更好。

　　代碼審查不是考試，也不是為了證明代碼的價值，而是提出更好的解決方案的機會。通過結對編程來減少代碼審查中的摩擦。這樣一來，更多的人一起來捍衛自己的工作而不是一個團隊來挑某個人的刺。

　　研究表明，減少缺陷數的最有效的方法不是過于苛刻，不是使用靜態分析工具，甚至不是單元測試，而是結對檢驗。找一種工具來折騰是個不錯的選擇，只要像待人一樣對待它就行了。

　　英文出自：Daedtech