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

沒錯,Code Review系列還在繼續,今天我們一起來聊一聊如何提出好的Code Review反饋。

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

640?wx_fmt=jpeg

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

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

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

爲什麼會這樣呢?

前文我們已經有過介紹,降低團隊效率的原因可能有很多,但通常是反饋的等待時間長和響應慢有關。如果再加上毫無意義的反饋交流,那麼代碼審查對於所有開發者都將是噩夢般的存在。但團隊可以輕鬆規避這些問題。

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

微軟的代碼審查研究

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

代碼審查時應該看些什麼

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

  • 功能缺陷

  • 邏輯問題

  • 缺少驗證(例如邊界問題)

  • API的用法

  • 設計模式

  • 架構問題

  • 可測性

  • 可讀性

  • 安全問題

  • 命名約定

  • 團隊編碼規範

  • 文檔

  • 使用最佳做法

  • 特定語言的問題

  • 使用過期方法的問題

  • 性能(比如複雜度)

  • 替代解決方案

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

現在,你看了所有的問題,你一定會問自己:哪些是最有價值的問題?

哪個反饋是最有價值的

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

也許你打開審查之後,會先瀏覽所有文件,然後調整自己。哪裏發生了變化?代碼的哪部分受到影響?修改的中心在哪?

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

那麼,還要看哪些問題呢?

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

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

640?wx_fmt=jpeg

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

  • 功能缺陷。這看起來是輕而易舉的,評分最高的代碼審查反饋是發現系統中的功能缺陷。但代碼審查並不是發現功能缺陷的主要手段,事實上只有一小部分批註是關於功能缺陷的。但是,如果找到一個,那麼代碼審查帶來的收益就是巨大的。

  • 驗證缺失和極端案例。開發人員認爲顯示了被遺忘的方案、未涵蓋的邏輯問題或極端情況的代碼審查反饋是非常有價值的。這種反饋圍繞尋找當前方案可能失敗的情況和備用方案來展開。

  • 最佳實踐和代碼約定。代碼審查對於維護一致的、可維護和可理解的代碼庫非常有用。所以,那些指出代碼中包含不符合代碼規範和最佳實踐的反饋是很有價值的。

  • API使用和設計模式。其他的有價值的反饋主要是關注API或第三方庫使用是否正確,或者是缺少或錯誤的使用了設計模式。

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

我們討論的一些問題並不像功能缺陷那樣更容易顯示價值。這些問題可能很有價值,但也有可能是在浪費所有人的時間。可能你已經猜到了,我們在討論的是代碼風格、代碼規範和註釋。這類問題通常被稱爲“挑剔問題”。

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

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

儘管如此,它們還是會被看作是“挑剔”的行爲,並且這個詞已經具有負面含義了。所以團隊必須保證所有人都能理解這類反饋的價值所在。

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

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

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

  • 替代解決方案。即使替代解決方案被認爲是有價值的,但是對當前代碼沒有明顯價值的實現並不能幫助你的團隊提升生產效率。

  • 現有技術債務和重構。類似的,開始突顯的舊的技術債務和潛在的重構機會超出了常規的代碼審查範圍。這些問題應該單獨討論。

  • 計劃和未來的工作。另一個沒有用的反饋類型就是批註過於關注未來的工作或者不在當前開發週期的工作。如果你看到這些問題,用backlogs或issue tracker這樣的工具記錄下來,這樣做對你的團隊是有價值的。之後,在合適的時間可以拿出來討論。

  • 提出問題只是爲了瞭解實現。即使代碼審查是一種學習和分享知識的工具,但提出瞭解實現的問題並不是代碼審查的目的。別忘了,代碼審查是作者爲了獲得同意以便繼續工作。

如果你不理解代碼時應該做什麼?

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

這是一個好問題,實際上,研究和經驗告訴我們,如果你不理解代碼,你無法提供有價值的反饋,至少能提供的不多。

如果是這種情況,你最好先了解一些潛在問題。你爲什麼不能理解代碼?因爲你是團隊的新成員?因爲你缺乏經驗?你以前沒有使用過代碼庫?新編寫的代碼一團糟?

如果是最後一個原因,那麼你所有的問題都是有效的,應該作爲代碼審查的一部分。但是可能你添加的不僅僅是問題,也許會加一些關於如何改進代碼,爲什麼難以理解代碼的反饋等等。

如果你對代碼不熟悉怎麼辦?

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

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

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

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

不只是你,也不是初級開發者的錯。這只是一個事實。我們的研究表明經驗豐富的開發人員更能提出有價值的反饋。剛開始在組織內部工作的經驗較少的開發人員,在前三個月很少能提出有價值的反饋。之後我們可以看到他們提出反饋的價值在一年內如何增加和穩定。

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

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

640?wx_fmt=jpeg


領域專家可以提高你的代碼審查價值

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

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

像對待自己一樣對待別人

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

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

另一方面,也不需要在代碼審查過程中加入過多的讚美之詞。在微軟的代碼審查研究中我們發現,作者不太在意對他們代碼的稱讚。

爲什麼會這樣?我們要再次提到代碼審查的目標。通常每個批註都是一個小的工作項。即使是讚美,有太多也不會增加價值。它只會加劇處理批註的工作量。

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

外部情況影響反饋的價值

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

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

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

原文鏈接

https://www.michaelagreiler.com/great-code-review-feedback

640?wx_fmt=gif

掃碼關注

有趣的靈魂在等你

640?wx_fmt=jpeg
640?wx_fmt=gif

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章