【譯】如何提出好的Code Review反饋

沒錯，Code Review系列還在繼續，今天咱們一塊兒來聊一聊如何提出好的Code Review反饋。

Code Review是保證代碼的質量和可維護性，以及向團隊成員分享知識的重要手段。可是，隨着團隊產出代碼質量的提高，Code Review所帶來的價值反而會降低。本文我將向你說明如何提出好的Code Review反饋。這一調研結果是來自於對微軟數百人的高效工程師的訪問。

代碼審查檢查的是關於代碼的問題和質量

在一次代碼審查過程當中，由一名工程師作出的修改將由其餘工程師來進行檢查和討論。代碼審查的主要目標是查出代碼的問題，保證代碼的質量。即便Code Review還帶來了一些其餘的像傳播和學習知識這樣的好處，但咱們仍要謹記這兩個最重要的目標。

有些團隊擔憂的，有些團隊已經遇到了代碼審查的主要缺點：下降編碼速度。這意味着團隊的生產效率被代碼審查拖慢了。

爲何會這樣呢？

前文咱們已經有過介紹，下降團隊效率的緣由可能有不少，但一般是反饋的等待時間長和響應慢有關。若是再加上毫無心義的反饋交流，那麼代碼審查對於全部開發者都將是噩夢般的存在。但團隊能夠輕鬆規避這些問題。

本文我主要向你介紹的是如何提出有價值的反饋。

微軟的代碼審查研究

在微軟，我進行了一項研究來了解代碼審查。在這其中一項，咱們分析了超過200萬條代碼審閱批註，以瞭解哪些反饋是有價值的，哪些是在浪費時間。但咱們要先從代碼審查應該看什麼來介紹。

代碼審查時應該看些什麼

咱們假設你被要求來審查一些代碼。代碼的做者發給你了幾個代碼文件，並對代碼修改的目的作了簡單的描述。那麼如今你要開始審查代碼了，你應該關注什麼？

• 功能缺陷
• 邏輯問題
• 缺乏驗證（例如邊界問題）
• API的用法
• 設計模式
• 架構問題
• 可測性
• 可讀性
• 安全問題
• 命名約定
• 團隊編碼規範
• 文檔
• 使用最佳作法
• 特定語言的問題
• 使用過時方法的問題
• 性能（好比複雜度）
• 替代解決方案

真多啊！爲了系統的查找這些問題，最好使用代碼審查清單，它能夠幫助你快速檢查這些問題，並確保不會遺漏。我會寫一份完整的，更加詳細的代碼審查清單，記得訂閱我，方便第一時間獲取。

如今，你看了全部的問題，你必定會問本身：哪些是最有價值的問題？

哪一個反饋是最有價值的

讓咱們來再次想象一下實際工做中你是如何開始一次代碼審查的。

也許你打開審查以後，會先瀏覽全部文件，而後調整本身。哪裏發生了變化？代碼的哪部分受到影響？修改的中心在哪？

當你已經熟悉了這些修改之後，你就會注意一些問題了：註釋和變量中的錯別字，缺乏註釋，縮進等代碼風格相關的問題，即便這些是要尋找的問題，也不要陷入這些問題中。實際上，這些問題是有價值的，但並非咱們最主要的目標。

那麼，還要看哪些問題呢？

有關缺陷、驗證缺失和最佳實踐的反饋是最有價值的

最有價值的代碼審查反饋都是關於代碼中實際問題的。全部開發人員都將這種反饋視爲最有用的類型。但咱們發現，在研究中這種問題只佔所有反饋的很小一部分。下圖中，你能夠看到代碼審查過程當中開發人員都在討論哪些問題，以及對於做者而言他們認爲哪些是有價值的。

最有價值的代碼審查批註解決了如下問題：

• 功能缺陷。這看起來是垂手可得的，評分最高的代碼審查反饋是發現系統中的功能缺陷。但代碼審查並非發現功能缺陷的主要手段，事實上只有一小部分批註是關於功能缺陷的。可是，若是找到一個，那麼代碼審查帶來的收益就是巨大的。
• 驗證缺失和極端案例。開發人員認爲顯示了被遺忘的方案、未涵蓋的邏輯問題或極端狀況的代碼審查反饋是很是有價值的。這種反饋圍繞尋找當前方案可能失敗的狀況和備用方案來展開。
• 最佳實踐和代碼約定。代碼審查對於維護一致的、可維護和可理解的代碼庫很是有用。因此，那些指出代碼中包含不符合代碼規範和最佳實踐的反饋是頗有價值的。
• API使用和設計模式。其餘的有價值的反饋主要是關注API或第三方庫使用是否正確，或者是缺乏或錯誤的使用了設計模式。

代碼審查反饋是一把雙刃劍

咱們討論的一些問題並不像功能缺陷那樣更容易顯示價值。這些問題可能頗有價值，但也有多是在浪費全部人的時間。可能你已經猜到了，咱們在討論的是代碼風格、代碼規範和註釋。這類問題一般被稱爲「挑剔問題」。

文檔、編碼風格和編碼規範。處理丟失或過期的文檔，突出註釋中的錯別字，或指出很差的命名是你常常收到的代碼審查反饋。但它們真的有價值嗎？

有時代碼審查者並不能立刻看到反饋的價值。可是找出錯別字也不是大的問題不是嗎？這些批准真正的價值是隨着時間流逝而帶來的複合效應。快速解決此類問題能夠保證代碼庫一直保持可維護性和可理解性。

儘管如此，它們仍是會被看做是「挑剔」的行爲，而且這個詞已經具備負面含義了。因此團隊必須保證全部人都能理解這類反饋的價值所在。

另外一方面，避免對代碼縮進和代碼風格進行冗長而重複的討論是很是重要的。這無疑會拖慢團隊的生產效率。爲了讓團隊保持生產力，讓咱們先制定一種代碼風格，而後繼續前進！

超出代碼審查範圍的反饋是無用的

多數被認爲是有價值的反饋都是關注當前範圍代碼審查。可是，代碼審查的範圍並非代碼更改文件中可見的代碼，也不會超出代碼修改的目的。所以，提出實施範圍以外的問題對於大多數開發人員來講是無用的。

• 替代解決方案。即便替代解決方案被認爲是有價值的，可是對當前代碼沒有明顯價值的實現並不能幫助你的團隊提高生產效率。
• 現有技術債務和重構。相似的，開始突顯的舊的技術債務和潛在的重構機會超出了常規的代碼審查範圍。這些問題應該單獨討論。
• 計劃和將來的工做。另外一個沒有用的反饋類型就是批註過於關注將來的工做或者不在當前開發週期的工做。若是你看到這些問題，用backlogs或issue tracker這樣的工具記錄下來，這樣作對你的團隊是有價值的。以後，在合適的時間能夠拿出來討論。
• 提出問題只是爲了瞭解實現。即便代碼審查是一種學習和分享知識的工具，但提出瞭解實現的問題並非代碼審查的目的。別忘了，代碼審查是做者爲了得到贊成以便繼續工做。

若是你不理解代碼時應該作什麼？

當你不理解代碼時應該作什麼呢？你怎麼才能提出有價值的反饋？

這是一個好問題，實際上，研究和經驗告訴咱們，若是你不理解代碼，你沒法提供有價值的反饋，至少能提供的很少。

若是是這種狀況，你最好先了解一些潛在問題。你爲何不能理解代碼？由於你是團隊的新成員？由於你缺少經驗？你之前沒有使用過代碼庫？新編寫的代碼一團糟？

若是是最後一個緣由，那麼你全部的問題都是有效的，應該做爲代碼審查的一部分。可是可能你添加的不只僅是問題，也許會加一些關於如何改進代碼，爲何難以理解代碼的反饋等等。

若是你對代碼不熟悉怎麼辦？

若是你以前在工做中沒有接觸過代碼庫，你可能很難理解代碼審查中的內容。一個好的方法是求助同事，請他/她爲你解釋一遍代碼。這裏重要的是不要在代碼審查過程當中隨機詢問有關代碼庫的問題。

沒錯，學習和傳播知識是代碼審查的兩個重要的好處。不過，這些都是代碼審查的附加價值，真正的關注點應該在於檢查代碼是否正確以及是否高質量。

除非明確告訴你經過這種方式來教你。不然你應該正常作代碼審查，這比你只觀察別人怎麼作要好。慢慢的，你就能更好的理解代碼，瞭解團隊慣例和最佳實踐，以及向代碼審查添加有用的反饋。

缺少經驗的開發人員提出有價值的反饋較少

不僅是你，也不是初級開發者的錯。這只是一個事實。咱們的研究代表經驗豐富的開發人員更能提出有價值的反饋。剛開始在組織內部工做的經驗較少的開發人員，在前三個月不多能提出有價值的反饋。以後咱們能夠看到他們提出反饋的價值在一年內如何增長和穩定。

爲了提出有價值的反饋，你必須熟悉代碼

多項代碼審查研究代表，有價值的反饋多數來自於曾經參與開發或審查對應代碼的開發人員。好消息是，只要以前改過一次就足夠了。也就是說在咱們的研究中，一次修改代碼的開發人員和修改了上百次代碼的開發人員在審覈時沒有顯著的區別。以下圖所示。

領域專家能夠提升你的代碼審查價值

來自其餘團隊或者是跨團隊的領域專家做爲審閱者會對你的代碼審查更有價值。你能夠選擇增長安全專家、大數據專家或可用性專家，即便他們並不像你的團隊那樣熟悉大家的代碼。

這樣作的好處是給代碼審查帶來了特別的經驗和外部的視角。他們進行代碼審查的目的也不一樣。他們可能不會去尋找最佳實踐和團隊規範，而是檢查代碼中你須要他們檢查的真正存在的問題。

像對待本身同樣對待別人

代碼審查是很社會化的活動，在致力於積極打造反饋文化的團隊中，它被高度讚揚和高價值的工程實踐。不幸的是，並非任何地方都是這樣。在一些團隊中，代碼審查被濫用爲權利展現甚至權利爭鬥的工具。這樣的代碼審查沒有任何幫助。

若是你想要從代碼審查中受益，瞭解如何提出建設性反饋是很是明智的選擇。指出一些代碼的質量不夠高。若是你批判同事的代碼，請務必始終以尊重的方式進行，並一直提出改進建議。

另外一方面，也不須要在代碼審查過程當中加入過多的讚美之詞。在微軟的代碼審查研究中咱們發現，做者不太在乎對他們代碼的稱讚。

爲何會這樣？咱們要再次提到代碼審查的目標。一般每一個批註都是一個小的工做項。即便是讚美，有太多也不會增長價值。它只會加重處理批註的工做量。

指出良好的工做對於團隊合做精神是必不可少的，而且是一個很好的團隊合做的動力。可是這最好是在其餘場合提出，好比會議上或者是咖啡時間。

外部狀況影響反饋的價值

還有幾件事會影響你在代碼審查過程當中得到的價值。在研究中咱們發現開發人員很難查看非代碼的文件，好比配置文件或者編譯文件。換句話說，開發人員會針對源碼提供更有價值的反饋。

影響代碼反饋質量的另外一個因素是審查文件的數量。須要審查的文件數越多，你收到反饋的質量就越低。保持審覈的小巧有不少好處，而且是最有價值的代碼審查最佳實踐之一。

總而言之，有價值的反饋是針對代碼審查目標的反饋：檢查當前代碼更改是否正確以及是否高質量。不利於實現此目標的討論應該在代碼審查過程以外討論。由於好的代碼審查反饋也是及時提出的反饋，它會幫助做者更快經過審覈。

原文連接

www.michaelagreiler.com/great-code-…