[[327859]]

怎么做 code review？本文分享了 Shopify 非常實(shí)用的 6 個(gè) code review 實(shí)踐技巧。

Code reviews 是打造高效團(tuán)隊(duì)的重要方面，這已經(jīng)成為共識(shí)。關(guān)于這個(gè)主題，有許多文章曾經(jīng)討論過，比如這篇論文——《An Empirical Study of the Impact of Modern Code Review Practices on Software Quality》?，F(xiàn)實(shí)中，許多企業(yè)的無數(shù)團(tuán)隊(duì)都進(jìn)行過某種形式的 code reviews。

https://sail.cs.queensu.ca/Downloads/EMSE_AnEmpiricalStudyOfTheImpactOfModernCodeReviewPracticesOnSoftwareQuality.pdf

而實(shí)際情況是，code reviews 剛開始時(shí)，人們的激情高漲，之后，code reviews 則流于形式，或者要么反饋不清晰、要么讓人難以執(zhí)行。長久以往，這讓團(tuán)隊(duì)錯(cuò)失了加快學(xué)習(xí)、分享知識(shí)的機(jī)會(huì)，最終難以提高代碼的質(zhì)量。

在 Shopify，我們不僅立足長遠(yuǎn)，而且希望追求發(fā)展更快。以我們的經(jīng)驗(yàn)來看，優(yōu)秀的 code reviews 實(shí)踐對(duì)工程師的成長和我們所打造的產(chǎn)品質(zhì)量有著巨大影響。

1. 噩夢般的編碼經(jīng)歷

這樣一個(gè)場景相信很多人都很熟悉：

你剛剛加入一個(gè)新團(tuán)隊(duì)，領(lǐng)導(dǎo)很快給你分配了一個(gè)編碼任務(wù)。作為新人，你特別想表現(xiàn)自己，因?yàn)槟阆胄阋幌伦约旱木幋a水平。于是，你接下來做了這些事：

1. 你為了完成任務(wù)瘋狂地敲了三周代碼；
2. 你將一個(gè)包含大約 1000 行新代碼的 Pull Request 提交評(píng)審；
3. 你收到兩條關(guān)于 code style 的評(píng)論，以及一個(gè)關(guān)于評(píng)審人表示他看不懂這些代碼用途的問題；
4. 你修復(fù) code style 并回答評(píng)審人的問題，然后評(píng)審人通過你寫的代碼；
5. 你把代碼分支合并到 Master，雙眼緊閉，緊握著拳頭，緊咬牙關(guān)等待著結(jié)果。幾分鐘后，CI 完成。幸好，Master 沒有崩潰。然而......
6. 此后 6 個(gè)月，你一直戰(zhàn)戰(zhàn)兢兢，不知道代碼何時(shí)會(huì)崩潰，以及以什么方式崩潰。

你可能經(jīng)歷過上述噩夢般的經(jīng)歷，那我們談?wù)勗鯓痈倪M(jìn)這個(gè)流程吧！

2. 實(shí)用的 Code Review 實(shí)踐

在 Shopify，我們看重交付速度、學(xué)習(xí)以及長期發(fā)展。這些價(jià)值觀雖然有時(shí)會(huì)產(chǎn)生沖突，但卻引導(dǎo)我們不斷嘗試許多新技術(shù)，并推動(dòng)團(tuán)隊(duì)變革。

我在本文總結(jié)了一系列 Shopify 內(nèi)部使用的實(shí)用技巧。借助這些技巧，我們能交付經(jīng)得起時(shí)間考驗(yàn)的有價(jià)值的代碼。

術(shù)語說明：我們將 Pull Requests（PR）定義為合并到基礎(chǔ)分支前進(jìn)行 code reviews 的一個(gè)工作單元。Github 和 Bitbucket 的用戶對(duì)這個(gè)術(shù)語很熟悉。

將 Pull Request 拆分為較小的代碼段

這個(gè)方法很簡單，可以成為提高 code reviews 工作流程最有用的技術(shù)。它之所以有效，主要有兩個(gè)原因：

• 評(píng)審人心理上更容易接受開始和完成一小塊代碼的評(píng)審工作。更大的 PR 自然會(huì)讓評(píng)審人推遲和拖延評(píng)審，并且在評(píng)審過程中被打斷的可能性更大。
• 作為一名評(píng)審人，如果 PR 太長，就很難深入進(jìn)去。要檢查的代碼越多，我們?cè)叫枰馁M(fèi)更多腦力來理解整個(gè)代碼塊。

將 PR 拆分為更小的代碼段，讓你有更多機(jī)會(huì)在更短時(shí)間內(nèi)得到更深入的評(píng)審。

目前，我們無法設(shè)置一個(gè)適用于所有編程語言和所有類型工作的通用標(biāo)準(zhǔn)。對(duì)于內(nèi)部的數(shù)據(jù)工程項(xiàng)目，我們?cè)瓌t上是要將 PR 控制在 200-300 行代碼。如果超過這個(gè)閾值，我們一般會(huì)將它拆分成更小的塊。

當(dāng)然，我們也要注意不要將 PR 拆分得過小，因?yàn)檫@意味著評(píng)審人可能需要檢查好幾個(gè) PR 才能理解整體邏輯。

使用 Draft PRs

你聽過造一輛汽車與畫一輛汽車的比喻嗎？這個(gè)比喻是這么說的：

1. 用戶要你造一輛車；
2. 6 個(gè)月后，你造了一輛漂亮的保時(shí)捷；
3. 你向用戶展示這輛車后，他們問你這輛車能不能放得下他們的 5 個(gè)孩子和沖浪板。

顯然，這里的問題在于目標(biāo)不清晰，團(tuán)隊(duì)沒有收集到足夠的反饋就直接構(gòu)建解決方案。如果在第一步后，我們先畫一幅汽車的草圖，并將其展示給用戶，他們會(huì)問相同的問題，這樣就可以進(jìn)一步了解客戶需求。如此，就為我們節(jié)省了 6 個(gè)月的工作量。軟件也不例外，我們可能會(huì)犯同樣的錯(cuò)誤，在用戶不需要的特性或模塊上投入大量工作。

在 Shopify，一般用 Work In Progress (WIP) PRs 來獲得早期反饋，其目標(biāo)是驗(yàn)證方向（算法、設(shè)計(jì)、API 等等選擇）。盡早變更可以避免在細(xì)節(jié)、修飾、文檔等方面浪費(fèi)精力。

作為一名寫代碼的人，這意味著你要對(duì)變更工作方向持開放態(tài)度。

在 Shopify，我們信奉的原則是允許大家有自己的理解，但不固執(zhí)己見。我們希望大家能在有充足理由的情況下自信地做出決定，但同時(shí)也能樂于學(xué)習(xí)其他更好的新方案。在實(shí)際工作中，我們使用 Github 的 Draft PRs，它們明確表明這項(xiàng)工作仍在流程中流轉(zhuǎn)，Github 不允許你合并一個(gè) Draft PR。其他工具可能有類似的功能，至少你創(chuàng)建正常 PR 時(shí)可以加上一個(gè) WIP 標(biāo)簽，以明確表示該工作還處于前期階段。這將幫助你的評(píng)審人專注于適當(dāng)?shù)念I(lǐng)域，提出適當(dāng)?shù)姆答仭?/p>

https://engineering.shopify.com/blogs/engineering/scaling-mobile-development-by-treating-apps-as-services

One PR Per Concern

除了行數(shù)外，需要考慮的另一個(gè)維度是你的工作單元試圖解決的問題數(shù)量。一個(gè)關(guān)注點(diǎn)可以是一個(gè)特性、一個(gè)錯(cuò)誤修復(fù)、一個(gè)依賴項(xiàng)升級(jí)、一個(gè) API 變更等等。你是否在重構(gòu)的同時(shí)引入一個(gè)新特性？一次修復(fù)了兩個(gè)錯(cuò)誤？同時(shí)引入了類庫升級(jí)和新的服務(wù)？

把 PR 分解為一個(gè)個(gè)單獨(dú)的關(guān)注點(diǎn)，它會(huì)產(chǎn)生下列影響:

• 更獨(dú)立的評(píng)審單元，這意味著更好的審查質(zhì)量；
• 受影響的人更少，因此可以聚集在更少的幾個(gè)專業(yè)領(lǐng)域中；
• 原子性回滾，可以回滾小的 commit 或 PR。這是很有價(jià)值的，因?yàn)槿绻隽藛栴}，就更容易確定錯(cuò)誤是在哪里引入的，以及回滾哪些部分。
• 將易事和難事分開。假設(shè)有一個(gè)新特性，需要重構(gòu)一個(gè)頻繁使用的 API。你可以更改這個(gè) API，升級(jí)十幾個(gè)調(diào)用的站點(diǎn)，然后實(shí)現(xiàn)這個(gè)特性。你的變更中有 80% 不是功能上的變更，明顯可以忽略掉，而 20% 是需要仔細(xì)注意測試覆蓋率、預(yù)期行為、錯(cuò)誤處理等等的新代碼，并且可能要經(jīng)過多次修訂。對(duì)于每一個(gè)修訂，評(píng)審人都需要瀏覽所有的修改以找到相關(guān)的部分。通過將其分成兩個(gè) PR，很容易就可以快速完成大部分工作，并優(yōu)化評(píng)審工作，將主要精力投入到難點(diǎn)上。

如果你最終拿到手的 PR 包含多個(gè)關(guān)注點(diǎn)，那么你可以將其分解為多個(gè)單獨(dú)的塊。這樣能針對(duì)每一塊進(jìn)行單獨(dú)的評(píng)審，每次評(píng)審的迭代周期可以更快，從而加速這個(gè) PR 的總體評(píng)審周期。通常情況下，有一部分工作能先快速完成，避免代碼爛到不能用以及引起合并沖突。

將 PR 分解成單獨(dú)的關(guān)注點(diǎn)

上例的 PR 包含三個(gè)不同的關(guān)注點(diǎn)，我們將其進(jìn)行拆分?？梢钥吹剑總€(gè)評(píng)審人需要檢查的上下文少了許多。最重要的是，只要其中任何一個(gè)部分的評(píng)審?fù)瓿?，代碼作者就能一邊等待其他評(píng)審反饋，一邊著手處理已經(jīng)反饋的問題。在最極端的情況下，代碼作者會(huì)陸續(xù)收到各個(gè)部分的評(píng)審反饋，幾乎可以不間斷地處理完這一系列 PR，而不是完成初稿后，等上幾天（已經(jīng)去忙其他的事），然后最后再返回頭來處理反饋意見。

專注代碼，而不是人

專注于代碼，而不是人，這條實(shí)踐談的是人與人之間的溝通方式和關(guān)系。從根本上講，這是提倡我們嘗試把注意力集中在如何改進(jìn)產(chǎn)品上，避免作者將評(píng)審意見當(dāng)作對(duì)他個(gè)人的批評(píng)。

以下是一些你可以遵循的技巧：

1. 評(píng)審人可以這樣想：“這是我們自己的代碼，我們?cè)撊绾胃倪M(jìn)它呢？”
2. 提出肯定意見！如果你看到有些代碼部分寫得不錯(cuò)，就加條評(píng)論表揚(yáng)一下。這能讓代碼作者繼續(xù)保持好的一面，并有助于他在心理上更容易接受改進(jìn)建議。
3. 代碼作者不妨這么想，評(píng)審人的出發(fā)點(diǎn)肯定是好的，不要將評(píng)論當(dāng)作是對(duì)個(gè)人的批評(píng)。
4. 下表列出了一些存在不足的評(píng)審反饋，以及如何按以上建議進(jìn)行重寫的建議。

歸根結(jié)底，code review 給我們提供了互教互學(xué)的機(jī)會(huì)，我們應(yīng)該對(duì)此持開放歡迎的態(tài)度。

挑選合適的評(píng)審人

決定由誰來評(píng)審你的工作通常很有挑戰(zhàn)性。以下問題可作為參考：

• 誰具備你正在構(gòu)建的特性或組件的上下文？
• 誰精通你正在使用的語言、框架或工具？
• 誰對(duì)這一主題知之甚深，有自己的理解？
• 誰關(guān)心你所寫代碼的結(jié)果？
• 誰應(yīng)該學(xué)習(xí)這些東西？或者，如果你是一名正在評(píng)審“老鳥"的菜鳥程序員，不妨抓住這個(gè)機(jī)會(huì)多多提問學(xué)習(xí)。別怕你的問題太幼稚，一個(gè)強(qiáng)大的團(tuán)隊(duì)會(huì)找時(shí)間來分享知識(shí)。

無論你的團(tuán)隊(duì)遵循哪些原則，請(qǐng)記住，作為一名代碼的作者，你有責(zé)任尋求并接受適當(dāng)?shù)娜藢?duì)你的代碼進(jìn)行高質(zhì)量的 code review。

給評(píng)審人提供關(guān)鍵的上下文

最后但同樣非常重要的一點(diǎn)是，你的 PR 描述至關(guān)重要。這取決于你選擇的評(píng)審人，不同的人會(huì)有不同的上下文。代碼的作者有責(zé)任提供關(guān)鍵信息或更多上下文的鏈接，幫助評(píng)審人能夠反饋有價(jià)值的意見。

你可以把以下問題放到你的 PR 模板中：

• 為什么這個(gè) PR 是必要的？
• 誰會(huì)從中受益？
• 可能會(huì)出什么問題？
• 你還考慮過其他方法嗎？你為什么決定采用這種方法？
• 這對(duì)其他系統(tǒng)有什么影響?

好的代碼不僅沒有錯(cuò)誤，還非常有用。作為一名代碼的作者，請(qǐng)確保你的 PR 描述將代碼與團(tuán)隊(duì)目標(biāo)聯(lián)系起來，最好能與待辦事項(xiàng)中的特性或缺陷描述聯(lián)系起來。作為評(píng)審人，會(huì)先評(píng)審 PR 描述，如果它不夠完整，你是無法針對(duì)未定義的目標(biāo)來判斷代碼是否適當(dāng)?shù)模蝗缭谠u(píng)審代碼前就把它打回去。請(qǐng)記住，有時(shí)代碼審查的最佳結(jié)果是認(rèn)識(shí)到根本不需要這些代碼！

3. 我們會(huì)有哪些收獲?

通過采用上面的一些技術(shù)，你可以在很大程度上影響軟件構(gòu)建過程的速度和質(zhì)量。但除此之外，還有潛在的文化影響：

1. 團(tuán)隊(duì)將達(dá)成共識(shí)。團(tuán)隊(duì)會(huì)更了解你的工作，除你之外，其他團(tuán)隊(duì)成員可以完善代碼庫的這一部分。
2. 團(tuán)隊(duì)將共同承擔(dān)責(zé)任。如果出現(xiàn)問題，不只是某個(gè)人的代碼需要修復(fù)，而是整個(gè)團(tuán)隊(duì)的代碼都需要修復(fù)。

任何團(tuán)隊(duì)成員都應(yīng)該能夠休上幾天假，他幾天不工作不會(huì)讓公司面臨風(fēng)險(xiǎn)，也不會(huì)因?yàn)閾?dān)心世界末日而不停地去看電子郵件。

4. 個(gè)人可以如何改進(jìn)團(tuán)隊(duì)的代碼審查流程？

如果你是團(tuán)隊(duì)主管，不妨開始嘗試這些技巧，找出適合你所帶團(tuán)隊(duì)的方法。

如果你是獨(dú)立貢獻(xiàn)者，可以與主管討論一下為什么你認(rèn)為代碼審查技術(shù)很重要，以及它如何提高效率和幫助團(tuán)隊(duì)。

在下次一對(duì)一交流或團(tuán)隊(duì)會(huì)議上，探討一下這個(gè)問題。