程式碼評審（Code review）是保證程式碼質量的一種有效手段，做得好的話，對公司來講是一筆收益頗高的時間投資。但實踐起來往往變成了炫耀程式設計技能、固執己見、惡言相向、同事關係惡化的事，這該如何是好？
往往程式碼評審過程中，評審者（Reviewer）往往會過於關心旁枝末節，而忽視主要問題，也就是所謂的自行車棚效應。在批准價值百億的核電站的建設提案中，專家們往往會浪費大量時間糾結於廠內自行車棚（bikeshed）的顏色；因為核電站太大、太複雜，“專家們”未必真懂，但總不能不說話啊，那就從無關痛癢的自行車棚挑毛病吧。
有效的程式碼評審
程式碼評審是開發人員編寫的程式碼由另一個人檢查以查詢缺陷和改進的過程。換句話說，開發人員大部分都是獨立編寫程式碼的，當程式碼完成之後，他們會召集一次評審。
程式碼評審是提高軟體質量的有效途徑。在Google，所有程式碼都要經過同行評審。引用《程式碼大全（第2版）》中的幾個例子：
- IBM 的 Orbit 專案有 50 萬行程式碼，使用了 11 級的檢查。它提前交付，並且只有通常預期錯誤的百分之一。
- 一份對 AT＆T 的一個 200 多人組織的研究報告顯示，在引入評審後，生產率提高了14％，缺陷減少了90％。
- 噴氣推進實驗室估計，通過早期發現和修復缺陷，每次評審節省約 25,000 美元。
然而，不少團隊在有效的程式碼評審爭論中，失去了原本的效益。在功能失調的團隊和組織中，對所有參與者來說它可以迅速變成一個令人不快的經歷：
- 它成為評審人員來展示技能的平臺。他們在別人的程式碼中指出“錯誤”，並強加自己沒有價值的“意見”。
- 在程式碼完全就緒前，開發人員會非常抗拒別人審查他們的程式碼 ——可以說這可能是一件好事，但他沒有真正理解評審的意義。
- 開發人員放棄程式碼所有權，並開始依賴他人查詢問題。
在這篇文章中，我將討論團隊和組織可以做的一些事情，讓程式碼評審為所有參與者帶來愉快的體驗。
對管理層的建議：營造健康文化
有效的程式碼評審，需要一個重視質量和卓越的健康文化。如果團隊不以提供高質量的產品為信仰，程式碼評審將不會給您所期望的結果。你需要一個人人蔘與的積極文化—立足於建設性批評，智者勝。
除了創造一個健康文化，並允許花時間和資源進行評審，管理者在程式碼評審中應保持低姿態。大多數人不想在上司面前暴露自己的祕密，這已是一種文化。程式碼評審最好由同行進行，管理層不應該詢問可以用來評價人的細節。的確有一些管理人員索要檢查表和成績，以便他們可以“衡量”並評價人。
可能你已經有一個健康的文化（算你幸運）。這還不夠，營造健康的文化取決於許多因素（團隊和組織內部）。這是非常具有挑戰性的，沒有靈丹妙藥。沒有正確的文化，程式碼評審不會帶來期望的收穫，甚至在極端情況下可能會適得其反。
對個人的建議：換位思考
Karl Wiegers 在他的《Peer Reviews in Software: A Practical Guide》中寫道：
產品的作者與評審者之間的互動至關重要。作者必須足夠信任和尊重評審者才能接受他們的意見。 同樣，評審者必須尊重作者的才華和辛勤工作。評審者應謹慎選擇他們用來提出問題的詞彙，重點關注他們對產品的觀察。說『我沒有看到這些變數被初始化 』可能會引發建設性的反饋， 而『你沒有初始化這些變數』可能會讓作者非常不爽。
關注程式碼很容易，但不要忘記，桌子（或計算機）的另一端有一個人。他有主見有“自我”。請記住，解決問題的方式有很多。
- 要謙虛。我既見過非常高效的評審，也見過因為吹毛求疵而非常低效的評審。不要吹毛求疵！！！
- 確保您有編碼標準。編碼標準是在組織中共享的人人都認同的一套準則。如果你沒有編碼標準，那麼不要讓討論變成一個比較編碼風格的比賽（大括號 { 在同一行還是下一行！）如果你遇到這樣的情況，請在編碼標準論壇上離線討論。
- 學會良好地溝通。你必須能夠清楚地表達想法和理由。
- 程式設計策略是一個仁者見仁智者見智的問題。評審者和開發人員應該尋求理解彼此的觀點，而不應該成為哲學辯論
對評審者的建議：謙虛
- 開發者不是冤大頭。評審的目的不是證明誰是更優秀的程式設計師而是查詢缺陷，並確保程式碼是簡單和可維護的。
- 問問題。不要提出可能聽起來帶指責的要求或言論。例如，不要說：『你沒有遵循標準XYZ』。更好的方式是真正尋求理解開發者的觀點：『你對標準 XYZ 有什麼看法，它是否適用於這裡？』，這可以引到我的下一個觀點。
- 避免『你為什麼』，『你為什麼不』風格的問題。它會使人對立。 『為什麼把它宣告為全域性變數？』可以更好地表達為『我不明白為什麼這裡用一個全域性變數』。尋找方法來簡化程式碼。程式碼評審的目標之一是建立“可維護”軟體。
- 記住要欣賞並感謝對方。人們經常忘記一句簡單的『幹得好』或『它看起來很棒』的影響有多大。
有些事情，如果看起來像排練過的或以諷刺的語氣說出來，就不會奏效。像正常對話一樣對待程式碼評審。你正在聆聽他人，應該真正尋求理解他們的觀點。需要時提供建議和提示。如果程式碼很棒，不要強迫找一些消極的來說。
對開發者的建議：它不是個人的事情
- 不要感情用事。記住，別人說的不是，是程式碼中的缺陷或不足，而不是你。
- 意識到你和你的程式碼是捆綁在一起是正常的事情。如果你為自己的工作感到自豪，那是一個很好的跡象，說明你是一個關心作品的人。
- 有適當的自我。足夠信任和捍衛自己的觀點，但又不至於盲目拒絕對方的好建議和意見。
- 人非聖賢孰能無過。評審者作為第二雙眼，可以指出你可能忽略的事情。問題與具體建議一樣有價值。
- 提問題要有針對性。『將所有這些類納入它們自己的軟體包中是否更有意義』
- 感謝審稿人的時間和他們可能提供的任何反饋。
總結
同行評審是人們互相交流，而無效（ineffectiveness）則源於社會學問題。然而，管理者花費大量時間在操心使用哪些驚豔的工具。工具會有所幫助，但只有工具並不會神奇地帶來結果。立足於正確的文化同時…換位思考，以人為本！ :-)