開(kāi)發(fā)者滿意度高達(dá) 97%,Google 如何擺脫代碼審查的痛苦?

代碼審查是軟件開(kāi)發(fā)流程中的重要部分，這一環(huán)節(jié)可以有效提升代碼質(zhì)量，減少 Bug 存在。然而，對(duì)于很多程序員而言，進(jìn)行代碼審查無(wú)疑是痛苦的，甚至有人認(rèn)為它拖慢了進(jìn)度、不利于快速上線......那么，代碼審查是否有必要？

本文將以科技大廠 Google 為例，分享 Google 內(nèi)部的做法以及代碼審查工具，希望我們可以從中吸取一些有益的經(jīng)驗(yàn)。

原文地址：https://read.engineerscodex.com/p/how-google-takes-the-pain-out-of

作者 | engineerscodex 譯者 | 彎月     責(zé)編 | 蘇宓
出品 | CSDN（ID：CSDNnews）

以下為譯文：

許多前 Google 工程師都提到他們非常懷念 Critique。這是 Google 自己的代碼審查工具，也是他們最戀戀不舍的一款 Google 內(nèi)部工具。

https://twitter.com/nsthorat/status/1728211545165828162

有人在 Reddit 的一篇文章中列舉了他們非?？春玫墓δ?，比如“attention set”等。

這與 Google 的調(diào)查結(jié)果相符，Google 內(nèi)部 97% 軟件工程師都很滿意 Critique。

那么，Critique 究竟是什么，它有何優(yōu)點(diǎn)？又如何與 Google 的代碼審查流程配合使用呢？

在本文中，我將探討：

• Google 的高效代碼審查準(zhǔn)則。

• Critique：Google的代碼審查工具，以及基于 AI 的改進(jìn)。

• Google代碼審查的內(nèi)部統(tǒng)計(jì)數(shù)據(jù)

• 為什么Critique在Google內(nèi)部備受推崇？我們可以從這學(xué)到什么？

Google的代碼審查準(zhǔn)則

Google的代碼審查準(zhǔn)則包括：

• 不求完美，但要持續(xù)改進(jìn) ：盡管經(jīng)驗(yàn)豐富的開(kāi)發(fā)者可能覺(jué)得經(jīng)驗(yàn)較少的開(kāi)發(fā)者的代碼達(dá)不到他們的個(gè)人標(biāo)準(zhǔn)，但Google鼓勵(lì)持續(xù)改進(jìn)，而非追求完美。開(kāi)發(fā)者需要不斷進(jìn)步，過(guò)于苛刻的審查不利于將來(lái)的提升。

• 保持或提高代碼庫(kù)的健康度。

• 遵循代碼指南 ：在涉及代碼風(fēng)格的問(wèn)題上，必須嚴(yán)格遵循和參考Google風(fēng)格指南（ https://go ogle.github.io/styleguide/ ）。

• 分享知識(shí)： 鼓勵(lì)審查者通過(guò)代碼審查分享有關(guān)語(yǔ)言特性、代碼庫(kù)以及其他相關(guān)的知識(shí)。通常，這些準(zhǔn)則會(huì)附上“支持文檔”，比如鏈接到Google/Abseil的C++每周技巧。

  Google內(nèi)部高度強(qiáng)調(diào)代碼審查的教育。

• 小范圍的變更： 盡量將變更限制在約200行代碼以內(nèi)。

• 嚴(yán)格的標(biāo)準(zhǔn)，但保持輕量級(jí)： Google希望審查者在24小時(shí)以內(nèi)審查代碼變更，并鼓勵(lì)只有一名審查者，目的是節(jié)省所有相關(guān) 人員的時(shí)間。 在Google，大多數(shù)代碼變更都很小，且只有一名審查者， 除了授權(quán)提交的確認(rèn)外，沒(méi)有其他評(píng)論。一周內(nèi)，70%的變更都會(huì)在初次審核申請(qǐng)后的24小時(shí)內(nèi)確認(rèn)提交。

• 禮貌和職業(yè)操守： 信任和尊重的文化至關(guān)重要。反饋應(yīng)專(zhuān)業(yè)，避免個(gè)人批評(píng)。審查者應(yīng)該對(duì)作者的方法持開(kāi)放態(tài)度，僅在必要時(shí)提供替代方案，并將每條評(píng)論視為學(xué)習(xí)的機(jī)會(huì)。

  我想特別說(shuō)一說(shuō)這一點(diǎn)，雖然看似很明顯，但在實(shí)踐中并不容易做到。人們往往對(duì)自己編寫(xiě)的代碼有特殊的感情，而審查者的嚴(yán)厲程度也有可能超過(guò)自己的預(yù)期。與面對(duì)面交流相比，書(shū)面文字可以減少溝通的語(yǔ)氣帶來(lái)的影響。

• Google針對(duì)代碼評(píng)論對(duì)開(kāi)發(fā)者的生產(chǎn)力和動(dòng)力的影響做了大量研究。

  - 預(yù)測(cè)開(kāi)發(fā)者對(duì)代碼審查的負(fù)面感受 （https://storage.googleapis.com/pub-tools-public-publication-data/pdf/7ac08fa960dfe10561c1f5953419a0c945279faa.pdf）

  -  代碼審查中的破壞性批評(píng)影響包容性 （https://research.google/pubs/pub51232/）

  -  檢測(cè)問(wèn)題和代碼審查中的人際沖突： 跨開(kāi)源和閉源方法的交叉匯流 （https://research.google/pubs/pub51204/）

  - 使代碼審查更加公平的研究 （https://developers.googleblog.com/2022/06/Using-research-to-make-code-review-more-equitable.html）

一個(gè)變更列表（變更列表是Google的拉取請(qǐng)求，相當(dāng)于PR）要想通過(guò)審查，就不能有殘留的未解決評(píng)論，而且至少有一名審查者給出“我覺(jué)得沒(méi)問(wèn)題”的意見(jiàn)，并獲得兩種類(lèi)型的審核批準(zhǔn)：

• 文件所屬代碼庫(kù)部分的“擁有者”的批準(zhǔn)。

• 可讀性批準(zhǔn)，負(fù)責(zé)批準(zhǔn)代碼的“可讀性”和風(fēng)格。

一個(gè)人可以同時(shí)負(fù)責(zé)以上三種審核工作。

Critique：Google的代碼審核工具

Critique是Google的代碼審核工具，可幫助工程師高效地審核和提交代碼變更。

另外，Critique還提供了當(dāng)前代碼庫(kù)和建議變更之間的差異視圖。

重要的是，2023年Google最新發(fā)布的消息顯示，他們內(nèi)部擁有全面的人工智能驅(qū)動(dòng)的代碼審查工具（如上圖所示）。

當(dāng)審查者在代碼上留下評(píng)論時(shí)，Critique將顯示一些建議，而這些建議都來(lái)自機(jī)器學(xué)習(xí)，這意味著代碼的作者只需點(diǎn)擊一個(gè)按鈕就可以解決評(píng)論。

根據(jù)Google的研究論文，最近的進(jìn)展表明Google正在盡可能地通過(guò)人工智能驅(qū)動(dòng)的代碼審查工具提高開(kāi)發(fā)人員的生產(chǎn)力。

代碼審核流程 我總結(jié)了Critique的一些關(guān)鍵要點(diǎn)，原文請(qǐng)點(diǎn)擊這里 （https://abseil.io/resources/swe-book/html/ch19.html）。 階段1：創(chuàng)建變更 在Google的內(nèi)部代碼編輯器Cider中創(chuàng)建一個(gè)CL（變更列表，即PR），該編輯器“緊密集成”了Critique以及其他Google內(nèi)部工具，從而提高了開(kāi)發(fā)人員的生產(chǎn)力。

• 預(yù)審工具：在審核開(kāi)始之前，在Critique的幫助下最后一次打磨代碼，然后顯示差異、構(gòu)建和測(cè)試結(jié)果，并進(jìn)行風(fēng)格檢查。
• 差分比較和可視化：比較結(jié)果帶有高亮顯示語(yǔ)法、交叉引用、行內(nèi)差異、忽略空白，以及檢測(cè)并隱藏了被移動(dòng)的代碼。
• 分析結(jié)果：顯示靜態(tài)分析器的結(jié)果，突出顯示重要發(fā)現(xiàn)并提供修復(fù)建議。包括“預(yù)提交”，即Critique中運(yùn)行的自動(dòng)化測(cè)試，可強(qiáng)制執(zhí)行項(xiàng)目特定的不變量。

Critique整合了分析作者的反饋渠道。 審核者可以點(diǎn)擊分析生成的評(píng)論上的“請(qǐng)修復(fù)”，表示作者應(yīng)該解決這個(gè)問(wèn)題。 代碼的作者和審核者都可以點(diǎn)擊“沒(méi)有幫助”，用于標(biāo)記對(duì)審查過(guò)程沒(méi)有提供實(shí)質(zhì)性幫助的分析結(jié)果。

階段2：請(qǐng)求審查 當(dāng)PR準(zhǔn)備好，可以開(kāi)始審核時(shí)，代碼的作者會(huì)添加審查者，并正式將代碼發(fā)送給他們進(jìn)行審查。 當(dāng)PR或變更列表已送審核時(shí)，如果尚未在當(dāng)前代碼快照上運(yùn)行“預(yù)提交”，則運(yùn)行這些測(cè)試。這意味著，參與審查的所有人都能知道代碼是否有問(wèn)題。

代碼審查也可以匿名，即代碼作者的身份對(duì)審查者保持匿名。然而，Google并未發(fā)現(xiàn)匿名審查和“真實(shí)”的審查之間有太大的差異。

階段3~4：理解代碼變更，并給予評(píng)論

任何人都可以針對(duì)代碼變更發(fā)表評(píng)論，并且有跟蹤審查進(jìn)度和解決評(píng)論的功能。

未解決的評(píng)論表示代碼的作者必須解決的問(wèn)題。代碼變更作者在回復(fù)評(píng)論時(shí)，可以將其標(biāo)記為“已解決”。

已解決的評(píng)論包括可選或信息性的評(píng)論，表示可能不需要變更作者采取任何行動(dòng)。

此外，還有一個(gè)審查狀態(tài)的儀表板和一個(gè)attention set，可以讓代碼審查者知道當(dāng)前正在等待誰(shuí)的回復(fù)。

attention set是Google工程師非常喜歡的一個(gè)功能。

階段5：變更批準(zhǔn)

如上所述，Google的代碼審查至少需要一名審核者給出“我覺(jué)得沒(méi)問(wèn)題”的意見(jiàn)。此外，代碼變更不能有殘留的未解解決評(píng)論，但代碼作者可以在回復(fù)時(shí)自行將評(píng)論標(biāo)記為已解決。最后，還需要相關(guān)代碼庫(kù)部分所有者的批準(zhǔn)，以及可讀性批準(zhǔn)。

如前所述，所有這些都可以由一名審核者完成。

階段6：提交變更

在Critique中提交代碼并確認(rèn)提交。

在提交變更后，Critique還能發(fā)揮作用。

“Google研究人員發(fā)現(xiàn)，Critique的用途不僅限于代碼審查。代碼變更的作者使用Critique來(lái)檢查代碼的差分，并瀏覽分析工具的結(jié)果。在有些情況下，代碼審查是變更開(kāi)發(fā)過(guò)程的一部分：審核者可能會(huì)發(fā)送未完成的變更，以決定如何完成實(shí)現(xiàn)。此外，在代碼變更被批準(zhǔn)很久之后，開(kāi)發(fā)人員還會(huì)使用Critique來(lái)檢查提交的變更歷史。”

Google的現(xiàn)代代碼審查統(tǒng)計(jì)數(shù)據(jù)

Google特意針對(duì)公司的代碼審查進(jìn)行了一項(xiàng)研究。下面是他們的論文中一些有趣的統(tǒng)計(jì)數(shù)據(jù)。

變更作者頻率：

• 中位數(shù)：每周3次變更。

• 80％的作者每周的變更次數(shù)少于7次。

審查頻率：

• 中位數(shù)：每周4次變更審查。

• 80％的審查者每周處理的變更審查少于10次。

代碼審查每周所花費(fèi)的時(shí)間：

• 平均：每周3.2小時(shí)

• 中位數(shù)：每周2.6小時(shí)

初始反饋的等待時(shí)間：

• 小變更：中位數(shù)小于1小時(shí)。

• 非常大的變更：約5小時(shí)。

審查流程整體的時(shí)間：

• 審查的延遲中位數(shù)（包括所有規(guī)模的代碼）：低于4小時(shí)。

• 與其他公司的比較：

  AMD：17.5小時(shí)（批準(zhǔn)時(shí)間中位數(shù)）。

  Chrome OS：15.7小時(shí)。

  微軟項(xiàng)目：14.7小時(shí)、19.8小時(shí)和18.9小時(shí)。

  微軟（另一項(xiàng)研究）：24小時(shí)。

“先前的研究發(fā)現(xiàn)，隨著變更規(guī)模的增加，有幫助的評(píng)論數(shù)量會(huì)減少，審查延遲將增加。變更的大小還會(huì)影響開(kāi)發(fā)人員對(duì)代碼審查過(guò)程的看法。Mozilla貢獻(xiàn)者的一項(xiàng)調(diào)查發(fā)現(xiàn)，開(kāi)發(fā)人員認(rèn)為與代碼規(guī)模相關(guān)的因素對(duì)審查延遲的影響最大。”

此外，每次變更收到的評(píng)論數(shù)量會(huì)隨著資歷的增加而減少。

https://storage.googleapis.com/pub-tools-public-publication-data/pdf/80735342aebcbfc8af4878373f842c25323cb985.pdf

為什么Critique在Google內(nèi)部備受青睞？

大多數(shù)Google員工以及前員工都是Critique的忠實(shí)用戶。

在Google內(nèi)部，對(duì)Critique感到滿意的軟件工程師數(shù)量高達(dá)97%。

我詢問(wèn)了7名Google員工，為什么相較于過(guò)去使用過(guò)的工具（比如GitHub），他們更喜歡Critique。

他們指出：

• 靜態(tài)分析 ：Google擁有一套功能完備的靜態(tài)分析工具，可自動(dòng)為代碼提供可操作的反饋。這為代碼作者和審查者節(jié)約了很多時(shí)間，因?yàn)閷彶檎卟槐卦陲@而易見(jiàn)的問(wèn)題吹毛求疵。

• 僅關(guān)注最新變更的文件 ：只關(guān)注代碼的最新“快照”。不關(guān)心以前的快照、提交和代碼變更，這樣用戶界面更清晰。

• 熟悉的、并排顯示差分的界面 ：默認(rèn)顯示“與上次審核相比的差異”。

• 機(jī)器學(xué)習(xí)提供建議 ：Google最新的機(jī)器學(xué)習(xí)提供支持的建議極大地加快了代碼審查的速度。

• 與Google其他工具的緊密集成 ：Critique與Google的IDE以及其他內(nèi)部工具（如bug跟蹤器） 的集成非常好，能夠提高生產(chǎn)力。包括代碼、評(píng)論以及任務(wù)票的鏈接。

• “行動(dòng)集”跟蹤 ：讓人們知道誰(shuí)應(yīng)該采取下一步的行動(dòng)。

• 令人滿意的游戲機(jī)制 ：雖然Critique不是為了游戲化而構(gòu)建的，但有的Google員工報(bào)告說(shuō)，他們很喜歡看到Critique“變綠” ，因?yàn)檫@意味著PR已準(zhǔn)備好提交了，即通過(guò)了所有測(cè)試，且得到了審核者的批準(zhǔn)。

引用關(guān)于靜態(tài)分析的一個(gè)調(diào)查報(bào)告：

一項(xiàng)針對(duì)88名Mozilla開(kāi)發(fā)人員的定性研究發(fā)現(xiàn)，靜態(tài)分析集成是代碼審查中最常請(qǐng)求的功能。

有了自動(dòng)分析，審查者就可以專(zhuān)注于代碼變更的可理解性和可維護(hù)性，而不會(huì)因瑣碎的評(píng)論（例如格式）分心。

思考和收獲

雖然如今許多工具都具備這些功能，但我認(rèn)為正是因?yàn)榕c各種工具的緊密集成，以及Google的特定工作流和代碼庫(kù)的極端“個(gè)性化”，使Critique備受喜愛(ài)。

與此同時(shí)，這也意味著并不是每家公司都能完整地復(fù)制Critique以及其他相關(guān)工具。例如，他們的一些工具主要是為了解決單一代碼庫(kù)結(jié)構(gòu)帶來(lái)的挑戰(zhàn)。

雖然Critique永遠(yuǎn)不會(huì)成為開(kāi)源項(xiàng)目，但Gerrit（ https://gerrit.googlesource.com/gerrit/ ）是一款類(lèi)似于Critique的工具，這是由Google創(chuàng)建并維護(hù)的開(kāi)源代碼審查工具。

然而，我認(rèn)為Google確實(shí)為提高開(kāi)發(fā)者的生產(chǎn)力做了很多努力和思考。我們可以從中吸取很多有益的經(jīng)驗(yàn)。

推薦閱讀：

?大模型時(shí)代程序員應(yīng)有的正確姿勢(shì)

? 在 Excel 中構(gòu)建 16 位 CPU！國(guó)外大牛極限“整活”：128KB RAM、16 色顯示，還有自定義匯編

?“刪不掉”的 AI 助手！開(kāi)發(fā)者向 JetBrains 發(fā)出抗議：公司不讓用 AI，代碼可能會(huì)被泄露