建站
咨詢
售后
建站咨詢
新聞中心
怎么做 code review？本文分享了 Shopify 非常實(shí)用的 6 個 code review 實(shí)踐技巧。
創(chuàng)新互聯(lián)公司成立以來不斷整合自身及行業(yè)資源、不斷突破觀念以使企業(yè)策略得到完善和成熟，建立了一套“以技術(shù)為基點(diǎn)，以客戶需求中心、市場為導(dǎo)向”的快速反應(yīng)體系。對公司的主營項(xiàng)目，如中高端企業(yè)網(wǎng)站企劃 / 設(shè)計、行業(yè) / 企業(yè)門戶設(shè)計推廣、行業(yè)門戶平臺運(yùn)營、成都app軟件開發(fā)、移動網(wǎng)站建設(shè)、微信網(wǎng)站制作、軟件開發(fā)、成都棕樹電信機(jī)房等實(shí)行標(biāo)準(zhǔn)化操作，讓客戶可以直觀的預(yù)知到從創(chuàng)新互聯(lián)公司可以獲得的服務(wù)效果。
Code reviews 是打造高效團(tuán)隊的重要方面，這已經(jīng)成為共識。關(guān)于這個主題，有許多文章曾經(jīng)討論過，比如這篇論文——《An Empirical Study of the Impact of Modern Code Review Practices on Software Quality》?，F(xiàn)實(shí)中，許多企業(yè)的無數(shù)團(tuán)隊都進(jìn)行過某種形式的 code reviews。
https://sail.cs.queensu.ca/Downloads/EMSE_AnEmpiricalStudyOfTheImpactOfModernCodeReviewPracticesOnSoftwareQuality.pdf
而實(shí)際情況是，code reviews 剛開始時，人們的激情高漲，之后，code reviews 則流于形式，或者要么反饋不清晰、要么讓人難以執(zhí)行。長久以往，這讓團(tuán)隊錯失了加快學(xué)習(xí)、分享知識的機(jī)會，最終難以提高代碼的質(zhì)量。
在 Shopify，我們不僅立足長遠(yuǎn)，而且希望追求發(fā)展更快。以我們的經(jīng)驗(yàn)來看，優(yōu)秀的 code reviews 實(shí)踐對工程師的成長和我們所打造的產(chǎn)品質(zhì)量有著巨大影響。
1. 噩夢般的編碼經(jīng)歷
這樣一個場景相信很多人都很熟悉：
你剛剛加入一個新團(tuán)隊，領(lǐng)導(dǎo)很快給你分配了一個編碼任務(wù)。作為新人，你特別想表現(xiàn)自己，因?yàn)槟阆胄阋幌伦约旱木幋a水平。于是，你接下來做了這些事：
- 你為了完成任務(wù)瘋狂地敲了三周代碼；
- 你將一個包含大約 1000 行新代碼的 Pull Request 提交評審；
- 你收到兩條關(guān)于 code style 的評論，以及一個關(guān)于評審人表示他看不懂這些代碼用途的問題；
- 你修復(fù) code style 并回答評審人的問題，然后評審人通過你寫的代碼；
- 你把代碼分支合并到 Master，雙眼緊閉，緊握著拳頭，緊咬牙關(guān)等待著結(jié)果。幾分鐘后，CI 完成。幸好，Master 沒有崩潰。然而......
- 此后 6 個月，你一直戰(zhàn)戰(zhàn)兢兢，不知道代碼何時會崩潰，以及以什么方式崩潰。
你可能經(jīng)歷過上述噩夢般的經(jīng)歷，那我們談?wù)勗鯓痈倪M(jìn)這個流程吧！
2. 實(shí)用的 Code Review 實(shí)踐
在 Shopify，我們看重交付速度、學(xué)習(xí)以及長期發(fā)展。這些價值觀雖然有時會產(chǎn)生沖突，但卻引導(dǎo)我們不斷嘗試許多新技術(shù)，并推動團(tuán)隊變革。
我在本文總結(jié)了一系列 Shopify 內(nèi)部使用的實(shí)用技巧。借助這些技巧，我們能交付經(jīng)得起時間考驗(yàn)的有價值的代碼。
術(shù)語說明：我們將 Pull Requests（PR）定義為合并到基礎(chǔ)分支前進(jìn)行 code reviews 的一個工作單元。Github 和 Bitbucket 的用戶對這個術(shù)語很熟悉。
將 Pull Request 拆分為較小的代碼段
這個方法很簡單，可以成為提高 code reviews 工作流程最有用的技術(shù)。它之所以有效，主要有兩個原因：
- 評審人心理上更容易接受開始和完成一小塊代碼的評審工作。更大的 PR 自然會讓評審人推遲和拖延評審，并且在評審過程中被打斷的可能性更大。
- 作為一名評審人，如果 PR 太長，就很難深入進(jìn)去。要檢查的代碼越多，我們越需要耗費(fèi)更多腦力來理解整個代碼塊。
將 PR 拆分為更小的代碼段，讓你有更多機(jī)會在更短時間內(nèi)得到更深入的評審。
目前，我們無法設(shè)置一個適用于所有編程語言和所有類型工作的通用標(biāo)準(zhǔn)。對于內(nèi)部的數(shù)據(jù)工程項(xiàng)目，我們原則上是要將 PR 控制在 200-300 行代碼。如果超過這個閾值，我們一般會將它拆分成更小的塊。
當(dāng)然，我們也要注意不要將 PR 拆分得過小，因?yàn)檫@意味著評審人可能需要檢查好幾個 PR 才能理解整體邏輯。
使用 Draft PRs
你聽過造一輛汽車與畫一輛汽車的比喻嗎？這個比喻是這么說的：
- 用戶要你造一輛車；
- 6 個月后，你造了一輛漂亮的保時捷；
- 你向用戶展示這輛車后，他們問你這輛車能不能放得下他們的 5 個孩子和沖浪板。
顯然，這里的問題在于目標(biāo)不清晰，團(tuán)隊沒有收集到足夠的反饋就直接構(gòu)建解決方案。如果在第一步后，我們先畫一幅汽車的草圖，并將其展示給用戶，他們會問相同的問題，這樣就可以進(jìn)一步了解客戶需求。如此，就為我們節(jié)省了 6 個月的工作量。軟件也不例外，我們可能會犯同樣的錯誤，在用戶不需要的特性或模塊上投入大量工作。
在 Shopify，一般用 Work In Progress (WIP) PRs 來獲得早期反饋，其目標(biāo)是驗(yàn)證方向（算法、設(shè)計、API 等等選擇）。盡早變更可以避免在細(xì)節(jié)、修飾、文檔等方面浪費(fèi)精力。
作為一名寫代碼的人，這意味著你要對變更工作方向持開放態(tài)度。
在 Shopify，我們信奉的原則是允許大家有自己的理解，但不固執(zhí)己見。我們希望大家能在有充足理由的情況下自信地做出決定，但同時也能樂于學(xué)習(xí)其他更好的新方案。在實(shí)際工作中，我們使用 Github 的 Draft PRs，它們明確表明這項(xiàng)工作仍在流程中流轉(zhuǎn)，Github 不允許你合并一個 Draft PR。其他工具可能有類似的功能，至少你創(chuàng)建正常 PR 時可以加上一個 WIP 標(biāo)簽，以明確表示該工作還處于前期階段。這將幫助你的評審人專注于適當(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ù)外，需要考慮的另一個維度是你的工作單元試圖解決的問題數(shù)量。一個關(guān)注點(diǎn)可以是一個特性、一個錯誤修復(fù)、一個依賴項(xiàng)升級、一個 API 變更等等。你是否在重構(gòu)的同時引入一個新特性？一次修復(fù)了兩個錯誤？同時引入了類庫升級和新的服務(wù)？
把 PR 分解為一個個單獨(dú)的關(guān)注點(diǎn)，它會產(chǎn)生下列影響:
- 更獨(dú)立的評審單元，這意味著更好的審查質(zhì)量；
- 受影響的人更少，因此可以聚集在更少的幾個專業(yè)領(lǐng)域中；
- 原子性回滾，可以回滾小的 commit 或 PR。這是很有價值的，因?yàn)槿绻隽藛栴}，就更容易確定錯誤是在哪里引入的，以及回滾哪些部分。
- 將易事和難事分開。假設(shè)有一個新特性，需要重構(gòu)一個頻繁使用的 API。你可以更改這個 API，升級十幾個調(diào)用的站點(diǎn)，然后實(shí)現(xiàn)這個特性。你的變更中有 80% 不是功能上的變更，明顯可以忽略掉，而 20% 是需要仔細(xì)注意測試覆蓋率、預(yù)期行為、錯誤處理等等的新代碼，并且可能要經(jīng)過多次修訂。對于每一個修訂，評審人都需要瀏覽所有的修改以找到相關(guān)的部分。通過將其分成兩個 PR，很容易就可以快速完成大部分工作，并優(yōu)化評審工作，將主要精力投入到難點(diǎn)上。
如果你最終拿到手的 PR 包含多個關(guān)注點(diǎn)，那么你可以將其分解為多個單獨(dú)的塊。這樣能針對每一塊進(jìn)行單獨(dú)的評審，每次評審的迭代周期可以更快，從而加速這個 PR 的總體評審周期。通常情況下，有一部分工作能先快速完成，避免代碼爛到不能用以及引起合并沖突。
將 PR 分解成單獨(dú)的關(guān)注點(diǎn)
上例的 PR 包含三個不同的關(guān)注點(diǎn)，我們將其進(jìn)行拆分?？梢钥吹?，每個評審人需要檢查的上下文少了許多。最重要的是，只要其中任何一個部分的評審?fù)瓿?，代碼作者就能一邊等待其他評審反饋，一邊著手處理已經(jīng)反饋的問題。在最極端的情況下，代碼作者會陸續(xù)收到各個部分的評審反饋，幾乎可以不間斷地處理完這一系列 PR，而不是完成初稿后，等上幾天（已經(jīng)去忙其他的事），然后最后再返回頭來處理反饋意見。
專注代碼，而不是人
專注于代碼，而不是人，這條實(shí)踐談的是人與人之間的溝通方式和關(guān)系。從根本上講，這是提倡我們嘗試把注意力集中在如何改進(jìn)產(chǎn)品上，避免作者將評審意見當(dāng)作對他個人的批評。
以下是一些你可以遵循的技巧：
- 評審人可以這樣想：“這是我們自己的代碼，我們該如何改進(jìn)它呢？”
- 提出肯定意見！如果你看到有些代碼部分寫得不錯，就加條評論表揚(yáng)一下。這能讓代碼作者繼續(xù)保持好的一面，并有助于他在心理上更容易接受改進(jìn)建議。
- 代碼作者不妨這么想，評審人的出發(fā)點(diǎn)肯定是好的，不要將評論當(dāng)作是對個人的批評。
- 下表列出了一些存在不足的評審反饋，以及如何按以上建議進(jìn)行重寫的建議。
歸根結(jié)底，code review 給我們提供了互教互學(xué)的機(jī)會，我們應(yīng)該對此持開放歡迎的態(tài)度。
挑選合適的評審人
決定由誰來評審你的工作通常很有挑戰(zhàn)性。以下問題可作為參考：
- 誰具備你正在構(gòu)建的特性或組件的上下文？
- 誰精通你正在使用的語言、框架或工具？
- 誰對這一主題知之甚深，有自己的理解？
- 誰關(guān)心你所寫代碼的結(jié)果？
- 誰應(yīng)該學(xué)習(xí)這些東西？或者，如果你是一名正在評審“老鳥"的菜鳥程序員，不妨抓住這個機(jī)會多多提問學(xué)習(xí)。別怕你的問題太幼稚，一個強(qiáng)大的團(tuán)隊會找時間來分享知識。
無論你的團(tuán)隊遵循哪些原則，請記住，作為一名代碼的作者，你有責(zé)任尋求并接受適當(dāng)?shù)娜藢δ愕拇a進(jìn)行高質(zhì)量的 code review。
給評審人提供關(guān)鍵的上下文
最后但同樣非常重要的一點(diǎn)是，你的 PR 描述至關(guān)重要。這取決于你選擇的評審人，不同的人會有不同的上下文。代碼的作者有責(zé)任提供關(guān)鍵信息或更多上下文的鏈接，幫助評審人能夠反饋有價值的意見。
你可以把以下問題放到你的 PR 模板中：
- 為什么這個 PR 是必要的？
- 誰會從中受益？
- 可能會出什么問題？
- 你還考慮過其他方法嗎？你為什么決定采用這種方法？
- 這對其他系統(tǒng)有什么影響?
好的代碼不僅沒有錯誤，還非常有用。作為一名代碼的作者，請確保你的 PR 描述將代碼與團(tuán)隊目標(biāo)聯(lián)系起來，最好能與待辦事項(xiàng)中的特性或缺陷描述聯(lián)系起來。作為評審人，會先評審 PR 描述，如果它不夠完整，你是無法針對未定義的目標(biāo)來判斷代碼是否適當(dāng)?shù)?，不如在評審代碼前就把它打回去。請記住，有時代碼審查的最佳結(jié)果是認(rèn)識到根本不需要這些代碼！
3. 我們會有哪些收獲?
通過采用上面的一些技術(shù)，你可以在很大程度上影響軟件構(gòu)建過程的速度和質(zhì)量。但除此之外，還有潛在的文化影響：
- 團(tuán)隊將達(dá)成共識。團(tuán)隊會更了解你的工作，除你之外，其他團(tuán)隊成員可以完善代碼庫的這一部分。
- 團(tuán)隊將共同承擔(dān)責(zé)任。如果出現(xiàn)問題，不只是某個人的代碼需要修復(fù)，而是整個團(tuán)隊的代碼都需要修復(fù)。
任何團(tuán)隊成員都應(yīng)該能夠休上幾天假，他幾天不工作不會讓公司面臨風(fēng)險，也不會因?yàn)閾?dān)心世界末日而不停地去看電子郵件。
4. 個人可以如何改進(jìn)團(tuán)隊的代碼審查流程？
如果你是團(tuán)隊主管，不妨開始嘗試這些技巧，找出適合你所帶團(tuán)隊的方法。
如果你是獨(dú)立貢獻(xiàn)者，可以與主管討論一下為什么你認(rèn)為代碼審查技術(shù)很重要，以及它如何提高效率和幫助團(tuán)隊。
在下次一對一交流或團(tuán)隊會議上，探討一下這個問題。
文章題目：6個實(shí)用的CodeReview實(shí)踐技巧
當(dāng)前URL：http://www.5511xx.com/article/cddgcic.html
