什麼是代碼審查？

代碼審查，或稱對等代碼審查，是有意識地、有系統地與其他程序員一起檢查彼此的代碼是否有錯誤的行為，並且已經被反覆證明可以像其他實踐一樣加速和簡化軟體開發過程。有對等代碼審查工具和軟體，但是概念本身很重要。軟體是人編寫的。因此，軟體經常充滿錯誤。犯錯的當然是人，所以這有一個明顯的關聯。但不太明顯的是，為什麼軟體開發人員經常依賴人工或自動測試來審查他們的代碼，而忽略了人的另一個偉大天賦：看到並自我改正錯誤的能力。

不管你是軟體開發經理還是一線的程序員，你都可能忽略代碼審查或代碼檢查的巨大好處，這將會讓你自己承擔風險。如果做得正確，對等審查可以節省時間，顯著簡化開發過程，並大幅減少質量保證團隊之後的工作量。審查能夠找出很多有可能會通過測試（漏掉了）、進入生產環境而最終進入用戶的筆記本電腦中的未被發現的錯誤(因為這些錯誤，煩惱的顧客可能會在亞馬遜或應用商店對你的產品發表嚴厲的評論，你的銷售也會因此受到影響)，進而實際上能夠為你省錢。閱讀本文來探索代碼審查對每個開發團隊都至關重要的其他原因。

此外，不止節省時間和金錢這些軟體開發業務中至關重要的問題，代碼審查也帶來了一些額外的、更加以人為中心的投資回報。鼓勵程序員相互談論他們的代碼的工作環境往往會促進更多的交流和友誼，傳播任何代碼的「所有權」感，並為初級開發人員提供寶貴的經驗——高級同事通過實際例子所展示的，編寫乾淨代碼的更好方法，用有用的快捷方式解決常見問題，以及直觀地識別任何潛在的故障點，如內存泄漏、緩衝區溢出或可擴展性問題。

總而言之，這些因素應該會鼓勵任何開發團隊去建立一個智能的戰略性代碼審查流程——如果他們還沒有這樣做的話(特別是考慮到統計數據)。畢竟，一個嚴肅的圖書出版商會敢於在沒有編輯團隊的情況下印刷成千上萬份作者的作品嗎？對於軟體的作者和出版商來說，同樣的邏輯也適用。但是現在，隨著生產周期越來越短，從哪裡開始呢？

理解代碼審查

對任何想到代碼審查的人，回顧他們幾年前的做法，在快節奏的敏捷工作場所引入這樣一個系統的前景似乎是一種殘忍的、不同尋常的懲罰。早在1976年，當IBM的Michael Fagan發表了他的開創性論文《設計和代碼檢查以減少程序開發中的錯誤》時，正式的、系統的代碼審查的想法就迅速流行起來了(早期版本的對等審查往往不太結構化)，通常包括一群人圍坐在悶熱的房間里的一張桌子旁，一起瀏覽電腦代碼的點陣列印稿，手中拿著紅色的筆，直到他們頭暈眼花。但是僅僅因為某件事很痛苦，並不意味著它不值得付出努力。正如Capers Jones和Olivier Bonsignour在2011年一篇名為《你檢查了嗎？》的博文中說到 :

Tom Gilb是處理軟體檢查的著名作者之一，他和他的同事們最近的工作繼續證實了他們早期的發現，即人類檢查代碼是發現和消除源自需求、設計和其他非編碼交付的複雜問題的最有效方法。事實上，為了識別源代碼中更深層次的問題，正式的代碼檢查在缺陷去除效率上超過了測試。

儘管如此，隨著計算機和軟體開發世界中的其他事物的發展，代碼審查已經發生了巨大的變化，現在有許多變種可供選擇。如今，儘管長期的正式代碼審查過程一如既往地有效，但通常並不需要，除非是在軟體工程中，要求錯誤率幾乎為零，例如在航空電子或其他受監管的行業中，人的安全優先於一切。但對於大多數其他情況，隨著時間的推移，一系列「輕量級」對等審查的過程已經有機地發展起來，其中許多過程與同樣輕量級的敏捷工作流和迭代生產周期完全兼容。有幾種常見的敏捷友好的代碼審查方法，每種方法都有其局限性。

常見代碼審查方法

電子郵件審查

一旦給定的代碼準備好進行審查，文件就會通過電子郵件發送給相應的同事，讓他們在工作流程允許的情況下儘快進行審查。雖然這種方法肯定比更傳統的技術更靈活和適應性更強，比如讓五個人聚在一個房間里參加一次代碼檢查會議，但是包含建議和不同意見的電子郵件往往會很快使事情變得複雜，只留下最初的編寫人員獨自理清頭緒。

配對編程

作為極限編程( XP )的標誌之一，這種編寫軟體的方法讓開發人員並肩工作(至少是象徵性的)，一起處理相同的代碼，從而在他們前進的過程中檢查彼此的工作。對於高級開發人員來說，這是一個指導初級同事的好方法，而且似乎將代碼審查直接納入了編程過程。然而，由於作者或配對者傾向於過於接近他們自己的語法，因此其他的代碼審查方法可能比本方法有更多的客觀性。配對編程在時間和人員方面也比其他方法使用更多的資源。

即時審查

對於大多數開發人員來說，這種方法比XP的配對編程更舒適，舊的跨平台技術是參與對等代碼審查的最簡單和最直觀的方式。一旦你的代碼準備好了，就找一個合格的同事去你的工作站(或者去他們的工作站)查看你的代碼，就像你向他們解釋你為什麼這麼寫一樣。這種非正式的方法當然是「輕量級的」，但是如果缺乏跟蹤或文檔記錄的方法，它可能會有點太輕。(提示:帶上記事本。)

工具輔助審查

我們把我們個人最喜歡的東西保存到最後，因為可以說沒有比基於軟體的代碼審查工具更簡單、更有效的方式來審查代碼了，其中一些工具是基於瀏覽器的，或者無縫地集成在各種標準IDE和SCM開發框架中。軟體工具解決了上述方法的許多局限性，以清晰一致的順序跟蹤同事的評論和缺陷的建議解決方案(類似於跟蹤MS Word中的變化)，使得評論能夠非同步和非本地進行，當新的評論出現時，向原始編碼人員發出通知，並保持整個過程高效運行，無需召開會議，也無需任何人離開辦公桌。一些工具還允許審查和修訂需求文檔，重要的是，還可以生成關鍵使用統計數據，提供流程改進和合規性報告所需的審計試驗和審查指標。

跟蹤你的進展

不管你喜歡哪種代碼審查方法，不言而喻，度量標準在代碼評審領域很重要，尤其是有這麼多開發團隊還在等著確信它作為常規實踐的最終效果。然而，沒有比跟蹤實際指標更好的方法來證明和智能地利用所需的時間和腦力——這就是為什麼一些現有的研究如此有啟發性的原因，例如2005 - 2006年SmartBear軟體對Cisco的對等代碼審查過程進行的分析，該分析調查了50名開發人員撰寫的320萬行代碼的2500次審查(完整的研究在SmartBear的深度電子書《對等代碼審查的最佳保密秘密》中介紹)。

結果呢？不僅Cisco的代碼審查過程檢測到的錯誤或缺陷遠遠超過了常規測試本身所能發現的，而且這些度量標準(從如此大的樣本集中得出)讓研究人員能夠收集到以下關於代碼審查的重要見解:

• 審查中的代碼行( LOC )應該少於200行，不超過400行，因為任何更多的代碼會超出審查者的能力上限，他們從而不能發現缺陷。

• 低於300LOC /小時的檢查率有利於最佳的缺陷檢測，低於500LOC /小時的檢查率仍然很好，但是如果LOC的檢查速度超過這一速度，預計會錯過很大比例的缺陷。

• 用注釋和解釋來輔助審查的作者比沒有注釋和解釋的作者缺陷要少得多。原因可能是作者被迫自我審查自身的代碼。

• 總審查時間應少於60分鐘，不超過90分鐘。超過90分鐘的審查，缺陷檢測率會直線下降。

• 預計缺陷率約為每小時15個。這個比率只能在審查中低於175 LOC時更高。

在同一電子書中記錄的另一個案例研究中，SmartBear團隊報告說，一名客戶希望降低每年撥打客戶支持電話的高昂成本，他們確定每次電話費用為33美元。從每年50，000次呼叫開始，在實施系統的代碼審查程序以消除軟體缺陷(因為計算機故障會向客戶支持部門發起隨機呼叫)和提高可用性(減少困惑的客戶致電技術支持)後的幾年內，支持呼叫的頻率下降到每年僅20，000次(儘管產品銷售增長了200 % )，相當於節省了260萬美元。

很明顯，正確的對等代碼審查不僅簡化了軟體，還簡化了底線。你可以在我們的代碼審查學習中心看到其他代碼審查最佳實踐。

對等代碼審查的未來

當然，儘管我們在本文中強調了這一點，但是代碼審查只是任何軟體生產團隊質量保證計劃的一個組成部分，許多不同的測試和靜態分析構成了QA核對錶。但是這是一個重要的組成部分，經常在bug產生後和它們有時間成長為更大的問題之前就消滅它們，並且識別「隱藏」的bug，這些bug現在可能沒有問題，但是可能會阻礙產品未來的發展。

單元測試總是有助於確定給定功能是否如預期的那樣「工作」，但是代碼審查可以闡明更適合人類感知的更微妙的問題——例如可伸縮性、錯誤處理和基本易讀性(包括開發人員注釋和需求文檔的書面清晰性)。正如測試自動化變得越來越複雜並且成為測試團隊選擇的主要武器一樣，工具輔助的對等代碼審查也有可能最終取代其他「輕量級」形式，成為最合適和最包容的方法。

在一個軟體生產進度不斷加快的世界裡，持續部署正在成為常態，客戶反饋是一個無止境的循環，越來越依賴正確的數字工具來獲得最大的效率是有道理的。github效應對代碼審查的影響可以從開發團隊實際進行的越來越多的審查中感受到。

但是即使從現在起10到20年後，除非新軟體開始自行編寫，我們可以放心，對等代碼審查的主要組成部分——即人類——仍將佔據中心位置。事實上，只要有人類進行代碼審查，這意味著即使沒有軟體審查工具，代碼仍將繼續改進，這完全要歸功於人類的心理。

如同Jason Cohen,SmartBear軟體的創始人在一個他稱之為「自我效應」的現象中指出，知道別人會批評你的工作，會自動讓你成為一個更好、更認真的開發者。沒有人想在同事面前看起來很糟糕，這一事實本身就可以成為編寫更好代碼、給予更多關注、讓更少的錯誤從我們易出錯的人性的許多裂縫中穿過並進入白晝的強大動力。

英文原文：https://smartbear.com/learn/code-review/what-is-code-review/
譯者：困頓少年 寧子謙

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！