建站
咨詢
售后
建站咨詢
新聞中心
Code Review(CR) 的本質(zhì)是什么?是為了查錯?還是為了 KPI?本文分享阿里資深技術(shù)專家的看法：CR 是一種關(guān)于社會學(xué)的長期行為和組織文化，通過 CR，形成一種良性互動的技術(shù)氛圍，傳播和分享知識，提升代碼質(zhì)量，并給出了 7 個提高 CR 效率和質(zhì)量的實(shí)踐建議。
關(guān)于代碼評審(Code Review)的文章也算是汗牛充棟了，代碼評審也已經(jīng)是許多組織的標(biāo)準(zhǔn)化實(shí)踐。不過，許多團(tuán)隊(duì)在嘗試代碼評審實(shí)踐時，卻有如下疑問：
- “政治正確” 的代碼評審活動究竟有沒有達(dá)到期望的實(shí)際效果?
- 給了我一大堆代碼，到底該從哪里看起?哪些方面是我該評審的?哪些不是?
- 別人有沒有認(rèn)真評審我的代碼?如何讓別人更容易的評審代碼?
這些都不是什么新問題，但是它們是如此的普遍，而且經(jīng)年累月地在不同的上下文中被提起，不外乎兩個方面：
- 理解代碼評審的核心目標(biāo)，建立關(guān)于代碼評審的正確預(yù)期。
- 了解代碼評審為什么可能無效，并采取有針對性的實(shí)踐來提升代碼評審的效果。
為什么要做代碼評審
不少同學(xué)認(rèn)為代碼評審就是用來查錯的，甚至希望用代碼的缺陷數(shù)量來檢驗(yàn)代碼評審的效果。這低估了代碼評審的價值。代碼評審最本質(zhì)的作用不是問題發(fā)現(xiàn)。除了代碼評審，我們有更多更好的手段來發(fā)現(xiàn)問題。代碼評審的作用更多是關(guān)于社會學(xué)的，是一種長期行為和組織文化。
CR 是代碼規(guī)范性的保證
編碼者視角：良性的社交壓力
你正在緊張地編碼，交付時間迫在眉睫。你的組織對代碼的單元測試有一個要求：凡是新增的代碼，必須有完整的自動化單元測試。但是，在壓力之下，你想給自己降低一點(diǎn)要求，不寫這部分的單元測試了，以后再編寫吧，或者為了應(yīng)付工具的覆蓋率要求，先寫一點(diǎn)不那么有用但是卻能帶來覆蓋率的測試(例如沒有斷言的測試)。
但是，一旦想到你的代碼將會發(fā)出去給你的同事做 Review，有沒有為剛才的這種想法產(chǎn)生一絲絲壓力?這種壓力是良性的，它能給你帶來一種即時的反饋，阻止你去選擇那些短期收益、長期損失的 “投機(jī)” 行為。如果沒有代碼評審這個環(huán)節(jié)，或許你就會真的 “為所欲為” 了，其實(shí)最終還是要為這種取巧行為買單。
維護(hù)者視角：代碼可讀性的保證
有許多方式能實(shí)現(xiàn)同一個軟件需求。有興趣的讀者可自行搜索 “Hello World 的 N 種寫法”。盡管條條大路通羅馬，但是，不同的道路代價是不一樣的。小到變量命名，大到設(shè)計(jì)結(jié)構(gòu)，如果你采用的是一種不那么常見的做法，往往就是給后來的代碼維護(hù)者挖坑。這種維護(hù)活動可能發(fā)生在 1 個月以后，也可能發(fā)生在 1 年以后，甚至是更久之后。甚至那時候，作為作者的你，已經(jīng)不在這個團(tuán)隊(duì)了，已經(jīng)沒有人能理解當(dāng)時的軟件為什么這樣設(shè)計(jì)。
代碼評審強(qiáng)制提前了這個反饋周期，代碼編寫完成之后，就立即有了一位或多位讀者——他們是這個代碼的 Reviewer。所以，這段代碼在編碼完成之后，立即經(jīng)歷了可讀性的檢驗(yàn)。更理想地，如果組織已經(jīng)有了編碼規(guī)范和設(shè)計(jì)規(guī)范，還能確保這段代碼遵循了這些規(guī)范。如果 CR 過程中發(fā)現(xiàn)這段代碼沒有遵循規(guī)范，那更是好事，它指向了 CR 的另外一個關(guān)鍵價值：知識傳播。
CR 帶來了知識傳播和設(shè)計(jì)共識
你可能是一個團(tuán)隊(duì)的 Leader，正在為如何提升團(tuán)隊(duì)成員的編程能力發(fā)愁。你希望他們?nèi)プx書，所以你介紹了諸如《整潔代碼》之類的入門書籍，你還介紹了經(jīng)典名著《設(shè)計(jì)模式》，還推薦了《領(lǐng)域驅(qū)動設(shè)計(jì)》。你也希望團(tuán)隊(duì)成員能理解產(chǎn)品的業(yè)務(wù)邏輯，所以希望團(tuán)隊(duì)成員周期性地進(jìn)行業(yè)務(wù)分享。
所有這些努力都很好。但是，也有可能你會被打擊。一個月過去了，似乎團(tuán)隊(duì)成員對命名規(guī)范都建立了概念，但是在怎么命名這件事上，大家并未形成共識。不少同學(xué)已經(jīng)了解了一些設(shè)計(jì)模式，但是有人過度運(yùn)用模式，搞得代碼臃腫不堪，有人則只知道singleton。團(tuán)隊(duì)成員為什么是實(shí)體對象，什么是值對象爭的不可開交，沒有人說得清楚聚合是什么，應(yīng)該在什么場景下使用。
你真正缺乏的，是一個場景。抽象的概念如果不落到具體的事情上，就很難形成共識。有人或許知道海洋法系的 “判例”，這是在法律層面形成共識的一種非常好的方法。代碼評審，其實(shí)也是在形成判例：哪一類設(shè)計(jì)是合理的，哪一類設(shè)計(jì)是不合理的。通過針對具體的問題進(jìn)行分析，團(tuán)隊(duì)就會逐漸形成設(shè)計(jì)共識，在過程中，對這些共識不那么熟悉的新同學(xué)，也可以慢慢融入。
檢驗(yàn)邏輯正確性
當(dāng)然，CR 也能用來檢驗(yàn)邏輯正確性。
保證代碼邏輯正確，是設(shè)計(jì)者的責(zé)任
為了不讓 CR 被濫用并被寄予過高期望，我們在此首先申明一點(diǎn)：保證代碼的邏輯正確，是設(shè)計(jì)者的責(zé)任。出現(xiàn)了一個空指針錯誤，究竟是編碼做的不好，是 CR 做的不好，還是測試做的不好?首先肯定是代碼作者制造了這個問題。把這個板子打在 Reviewer 身上公平嗎?或許，Reviewer 確實(shí)有責(zé)任發(fā)現(xiàn)這樣的問題，但是，如果代碼本來就錯誤多多呢?如果一次性 Review 了 1000 行代碼，根本看不過來呢?我能找到一大把的理由，來說明為什么漏掉這么一個空指針錯誤。
發(fā)現(xiàn)邏輯錯誤的其他方法
你還有許多其他的方法來發(fā)現(xiàn)錯誤，它們的成本往往并不高，例如：
- 編寫自動化單元測試
- 使用代碼靜態(tài)檢查工具
無論是否存在 CR 活動，上述兩點(diǎn)都是一名專業(yè)的開發(fā)者和開發(fā)組織應(yīng)該大力倡導(dǎo)的行為。
發(fā)現(xiàn)錯誤的價值
在上述兩點(diǎn)得到承認(rèn)的前提下，代碼評審確實(shí)也應(yīng)該用于發(fā)現(xiàn)錯誤——它本質(zhì)上建立了一種冗余機(jī)制，通過多人工作在同一段代碼上，發(fā)現(xiàn)代碼中可能發(fā)生的認(rèn)知錯誤(這對于單個開發(fā)者往往是很難發(fā)現(xiàn)的)以及疏忽。
高效高質(zhì)的代碼評審
哪些因素阻礙了代碼評審的效果
代碼評審本身并不困難，但是，如果考慮到如下因素，可能就比較復(fù)雜了：
- 你可能對要評審的代碼的設(shè)計(jì)上下文一無所知
- 你可能非常忙碌
- 你一下子收到了幾千行需要被評審的代碼
- ...
實(shí)際操作建議
建議一：小批量——每次 Review 的代碼量要少
研究發(fā)現(xiàn)， 成功的 CR 活動一定是小規(guī)模的。例如，《Modern Code Review：A Case at Google》論文介紹說， Google 的 CR 活動中，有 35% 的 CR 僅僅修改了一個文件，90% 的 CR 修改的文件數(shù)在 10 個文件以內(nèi)，甚至有 10% 的 CR 僅僅修改了1行代碼。
代碼量少的好處顯而易見：修改了哪里非常清晰，問題也會一目了然。一次推給別人 1000+ 行代碼，還想得到有價值的 Review，可能性微乎其微。
當(dāng)然，一次 Review 它代表的功能應(yīng)該是有意義的，是完整的，如果不是修復(fù)缺陷，這一定程度上也對開發(fā)者迭代地開發(fā)功能的能力提出了要求。
建議二：多批次——Review 要頻繁發(fā)生
小批量必然導(dǎo)致了多批次。在微軟 2013 年的一篇論文《iExpectations, Outcomes, and Challenges Of Modern Code Review》和前述的 Google 的論文中都提到了頻繁 Review 的做法。其中，Google 的每周每 Developer 的代碼變更中位數(shù)是 3 個，每周每 Reviewer 的 Review 中位數(shù)是 4 個。
建議三：找對人——合適的 Reviewer
誰適合 Review 你的代碼?選一個和被 Review 的代碼毫不相干的人肯定是不明智的。下面列出了一些潛在的候選人：
- 如果你的組織有 Owner 機(jī)制，Owner 應(yīng)該是合適人選
- 和你工作在相同上下文的同事
- 近期修改過相同代碼的同事
- 比你更資深的程序員，希望得到他們的專業(yè)反饋
現(xiàn)在已經(jīng)有一些工具，能夠根據(jù)上下文推薦 Reviewer，這也為選擇合適的 Reviewer 提供了便利。
建議四：快速響應(yīng)
當(dāng)每次 Review 的粒度不大，Review 又比較頻繁時，快速響應(yīng)才能成為可能，也是必然的要求。在這個數(shù)據(jù)上，Google 的中位數(shù)是 4 小時。這個指標(biāo)可以成為一個較好的參照。
建議五：使用現(xiàn)代工具
快速響應(yīng)、高質(zhì)量的 Review 離不開現(xiàn)代工具?，F(xiàn)代的 Review 工具能自動集成進(jìn)工作流，高亮變化，甚至能自動匯總變更。這方面已經(jīng)有許多現(xiàn)代的工具可以使用，還沒有選好工具的讀者，可以自行搜索。
建議六：考慮結(jié)對編程
當(dāng)我們提到 “小批量、多批次、快速反饋” 的時候，如果有過結(jié)對編程經(jīng)驗(yàn)的同學(xué)，馬上就會反映過來，結(jié)對編程和 CR 何其相似。
結(jié)對編程，共同編程的兩位同學(xué)擁有完全相同的上下文，不存在上下文切換的煩惱，沒有缺乏時間的煩惱，不需要借助額外的工具，反饋隨時隨地。事實(shí)上，在我的眼中，結(jié)對編程才是最好的 Code Review。
建議七：綜合在線 Review 和線下 Review
在線 Review 應(yīng)該是常態(tài)化的行為。考慮到 CR 的 “知識傳播” 價值，線下 Review 是有益的補(bǔ)充。有經(jīng)驗(yàn)的團(tuán)隊(duì)，會周期或者不定期的組織線下 Review，這樣能獲得比在線 Review 更為廣泛的知識傳播面，也能引起更為熱烈的討論和辯論，有助于形成更高質(zhì)量的共識。
數(shù)字化的指標(biāo)
研發(fā)行為的全面數(shù)字化，帶來了一些有價值的數(shù)據(jù)洞察。如果工具支持，可以通過一些指標(biāo)的觀測，持續(xù)推進(jìn) CR 活動。我們把一些建議的指標(biāo)和數(shù)據(jù)總結(jié)如下：
從 Author 角度：
- 單次評審的代碼行數(shù) (主要指標(biāo))
- 評審的頻度 (參考)
從 Reviewer 角度：
- 響應(yīng)時間
- 評論數(shù)和拒絕率
從 Reviewer 的團(tuán)體角度，還可以發(fā)現(xiàn) Author-Reviewer 之間的社群關(guān)系，也是一種有價值地了解知識傳播的信息。
不要做什么：
避免用 CR 的數(shù)字化指標(biāo)進(jìn)行考核，即使動機(jī)良好。CR 的本質(zhì)是文化建設(shè)，強(qiáng)烈建議僅僅把 CR 的指標(biāo)用作提升指引，而不要用于和績效有關(guān)的評價，無論是前述的幾種指標(biāo)，還是和 Review 的質(zhì)量甚至是缺陷相關(guān)的數(shù)據(jù)。
實(shí)踐
你的組織的代碼質(zhì)量和技術(shù)氛圍如何?你們正在實(shí)施代碼評審嗎?
- 如果暫時還沒有，是否愿意做一些嘗試?
- 如果已經(jīng)在實(shí)施，既有的實(shí)踐是否達(dá)到了代碼評審的真正目標(biāo)?
文章標(biāo)題：7個建議讓CodeReview高效又高質(zhì)
瀏覽路徑：http://www.dlmjj.cn/article/djochpp.html
