?譯者 | 崔皓

審校 | 孫淑娟

一、開篇

為了提升代碼質(zhì)量，需要將批判性思維帶入到編程中去。因此，需要將工程方法應(yīng)用到代碼的審核過程。雖然，軟件工程師，在討論抽象類和函數(shù)時(shí)信心十足，但談?wù)?管理 "時(shí)，這種信心卻蕩然無存。

在整個(gè)編程過程中，由于各種原因會(huì)存在大量的缺陷，這就需要通過代碼審查的方式將這些缺陷找出，才能保證軟件質(zhì)量。這篇文章將從不同的角度來看待代碼審查，并提出改進(jìn)的意見。

在《軟件工程的事實(shí)與謬誤》一書中，有這樣的描述：“嚴(yán)格的檢查可以在運(yùn)行第一個(gè)測試用例之前消除軟件產(chǎn)品中高達(dá)90%的錯(cuò)誤?！?/p>

Bob 對代碼審查的回復(fù)

雖然無法確定這話是針對代碼審查的，但是可以理解為不同種類的檢查確實(shí)對軟件質(zhì)量有幫助。1976年，Michael Fagan在他的文章《設(shè)計(jì)和代碼檢查以減少程序開發(fā)中的錯(cuò)誤》中提出了代碼檢查的想法。

包括以下三種類型的檢查：

• 設(shè)計(jì)檢查
• 單元測試前的代碼檢查
• 單元測試后的代碼檢查

Michael Fagan關(guān)于設(shè)計(jì)和規(guī)范檢查的文章中的一個(gè)方案

Fagan的工作沒有提出新的代碼審查方法，而是記錄了已經(jīng)存在的現(xiàn)象，并為其進(jìn)行論證。然而，這篇文章是最早的記錄代碼檢查的書面作品。

代碼檢查（Code inspection）看起來像現(xiàn)代的代碼審查（Code review）。那我們?yōu)槭裁唇裉鞎?huì)錯(cuò)過其他類型的檢查？

二、為什么今天只有代碼審查的假設(shè)

先進(jìn)代碼檢查的流以及其他類型檢查方式的銷聲匿跡，得益于我們使用的代碼工具。例如：GitHub、BitBucket或GitLab它們都內(nèi)置了代碼檢查的工具，并天然地適合Git flow、GitHub flow和其他方法。

在設(shè)計(jì)活動(dòng)中使用什么工具？這與UI/UX無關(guān)，只和代碼結(jié)構(gòu)相關(guān)。你可能聽說過CASE或UML工具。在我工作過的7家公司中，并沒有看到它們被認(rèn)真使用。

在HackerNoon上，關(guān)于"UML "的搜索查詢結(jié)果只有兩個(gè)。所以當(dāng)沒有解決方案設(shè)計(jì)過程時(shí)，并不需要介紹設(shè)計(jì)檢查。在我領(lǐng)導(dǎo)的團(tuán)隊(duì)中，使用Miro進(jìn)行界面設(shè)計(jì)。整個(gè)設(shè)計(jì)過程本很令人滿意：和其他圖表工具一樣，你很快就開始畫圖，而不是解決設(shè)計(jì)方面的問題。我們要解決的問題和工具提供的功能被割裂了。下面是 《投資無限 》一書中的一小段話，可以支持這個(gè)觀點(diǎn)。

“......如果我們只是做工具能做的事--那么我們將永遠(yuǎn)局限于工具的能力?！?/p>

三、現(xiàn)有的代碼審查有什么缺陷？

讓我們從不同的角度看如下幾個(gè)處理過程，每一個(gè)都存在重大的問題。

1.BPMN透視

BPMN是業(yè)務(wù)流程建模標(biāo)記系統(tǒng)的建成。它用動(dòng)作、事件、邏輯網(wǎng)關(guān)、消息和其他手段來描述流程。如果你想開發(fā)一種算法，我甚至建議使用它，因?yàn)樗攘鞒虉D更具有描述性。讓我們用這個(gè)符號(hào)來描述代碼審查過程，并對其進(jìn)行分析。我使用了一個(gè)基于文本的工具來生成圖表。

經(jīng)典的代碼審查流程圖

一切從創(chuàng)建PR（Pull Request）開始，下一步是通知審查員，這是做了簡化，可以說。"嘿，我的PR在等著你！這里需要等待，然后審查員進(jìn)入任務(wù)，進(jìn)行審查。有可能一個(gè)PR會(huì)馬上被合并。當(dāng)然，相反的情況也可能發(fā)生：會(huì)提出一些修正意見。此時(shí)代碼的作者可能已經(jīng)在做下一個(gè)任務(wù)了，那么就需要等待一段時(shí)間。當(dāng)作者返回到有修改意見的任務(wù)時(shí)，就需要恢復(fù)上下文，解釋注釋并進(jìn)行修復(fù)。

在修復(fù)之后，下一步就是通知審查員重新進(jìn)行代碼審查了。

這種情況仿佛似曾相識(shí)，是的，代碼審查和修復(fù)是一個(gè)無限的循環(huán)，上面描述的僅僅是這個(gè)循環(huán)中的一次而已。審查員總能夠發(fā)現(xiàn)新的問題，拋出新的修改建議。又或者整個(gè)循環(huán)會(huì)在程序作者的其他工作影響下，一直等待下去。

我們是否希望無限循環(huán)成為日常運(yùn)作的一部分？我不確定，因?yàn)閾碛懈斓慕桓锻ǔＪ俏覀兯诖摹?/p>

2.解決問題的方式方法

有時(shí)，團(tuán)隊(duì)中的高級開發(fā)人員或架構(gòu)師會(huì)擔(dān)當(dāng)審查員。他們希望有一致的代碼庫，同時(shí)還會(huì)堅(jiān)持一些編程的方法和模式。也就是說審查員有自己一套想法（愿景）的，當(dāng)然開發(fā)人員也有他們的想法。通常，兩波人不知道對方的意圖。這需要有一種方式將他們之間的觀點(diǎn)和看法打通，有助于他們能夠站在同一層面思考問題，但實(shí)際上這種情況很少發(fā)生。讓我們看看下面的圖片。

在經(jīng)典的代碼審查過程中，代碼創(chuàng)建者和

審查者的觀點(diǎn)隨著時(shí)間的推移而出現(xiàn)分歧

可以看到代碼審查參與者的兩個(gè)思想觀念是不同的。在第一次迭代之后，他們開始對齊，但仍有一段路要走。評審員調(diào)整一個(gè)人的視野，而代碼作者則根據(jù)建議來行動(dòng)。

就好像"你已經(jīng)要了一棟房子，然后驚喜地發(fā)現(xiàn)!它不是你所期望的那個(gè) "。想象一下，你已經(jīng)要求一個(gè)人去實(shí)現(xiàn)一些事情。實(shí)現(xiàn)以后再看結(jié)果，讓你非常驚訝。不要慌著驚訝，因?yàn)槟悴]有告訴執(zhí)行者做這件事情的“決策框架”，才導(dǎo)致結(jié)果和你預(yù)期的存在偏差。

3.人際關(guān)系的角度

代碼審查備忘錄

這張圖片本身就說明了問題，審查的代碼量越少發(fā)現(xiàn)越多的問題，代碼量越大反而“不會(huì)發(fā)現(xiàn)問題”。坦率地說，如果你是審查者，你會(huì)要求你的同事花費(fèi)很長時(shí)間（好幾天）徹底修復(fù)一個(gè)設(shè)計(jì)問題嗎？特別是在迭代的沖刺階段，在開發(fā)時(shí)間本來就非常緊張的情況下，會(huì)這么做嗎？恐怕，你想得是快點(diǎn)完成功能，合并代碼發(fā)布吧？！另一方面，如果存在代碼修復(fù)需要修改系統(tǒng)中很多地方，你會(huì)做出修改的決定嗎？

雖然，精益生產(chǎn)的思想并沒有影響到編程。然而，在Mary Poppendieck和Tom Poppendieck的《精益軟件開發(fā)》中就有對軟件開發(fā)7大浪費(fèi)的描述。它們包括：

• 部分完成的工作
• 額外功能
• 重新學(xué)習(xí)
• 交接
• 延遲
• 任務(wù)轉(zhuǎn)換
• 缺陷

下面，我們花一點(diǎn)篇幅對這7點(diǎn)進(jìn)行展開說明：

部分完成的工作。審查代碼沒有得到足夠的重視，審查只是提升代碼質(zhì)量的開始，而不是軟件開發(fā)的結(jié)束。有一種有趣的心態(tài)："開發(fā)完成了，審查任務(wù)提交了，剩下的就不是我的工作了！"，這就導(dǎo)致了，代碼審查是 "三不管"的地方，只有上級問起的時(shí)候才得到重視。

• 重新學(xué)習(xí)。在BPMN圖上看到重新學(xué)習(xí)的情況，程序員在收到修改建議時(shí)，手上可能有其他的任務(wù)。當(dāng)著手對審查代碼進(jìn)行修改的時(shí)候，已經(jīng)離完成該項(xiàng)任務(wù)有一段時(shí)間了，為了根據(jù)意見進(jìn)行修改，就不得不對業(yè)務(wù)和技術(shù)背景進(jìn)行回顧，這也就是重新學(xué)習(xí)?；謴?fù)業(yè)務(wù)和技術(shù)的上下文對程序員來說是有開發(fā)成本的。（這種情況對于審查者也適用）
• 交接。代碼的交接，修改建議的描述，中間存在團(tuán)隊(duì)成員的溝通，有溝通就存在損耗。
• 延遲。代碼審查設(shè)計(jì)包含我們前面討論過的兩種類型的延遲：修改本身的延遲和思想觀念的延遲。
• 任務(wù)轉(zhuǎn)換。人們暫停他們的任務(wù)，對審查給予一些關(guān)注。
• 缺陷。審查有利于發(fā)現(xiàn)表面問題，但不能發(fā)現(xiàn)設(shè)計(jì)缺陷，而設(shè)計(jì)缺陷會(huì)造成最大的傷害。上面提到的缺乏向研究員提出重大修改的動(dòng)機(jī)，導(dǎo)致了項(xiàng)目中的大量缺陷。

我們已經(jīng)從很多方面闡述了代碼審查的問題。我們能做些什么來解決這些問題呢？

四、重新設(shè)計(jì)代碼審查

在本節(jié)中，我們將針對上面提出的問題，看看如何對其進(jìn)行優(yōu)化。

1.修復(fù)流程結(jié)構(gòu)

代碼審查流程圖

圖中有代碼作者在等待審查完成，以及在審查員的概述問題之后的結(jié)對編程會(huì)議。

在過程中，可以看到與之前過程相比，有幾個(gè)顯著的變化。

• 不再有潛在的無限審查循環(huán)。
• 在等待的未知時(shí)間內(nèi)也會(huì)得到處理。
• 不需要為代碼作者恢復(fù)上下文或解釋反饋。評論只是作為提醒。

這個(gè)過程發(fā)生的核心條件是什么？團(tuán)隊(duì)需要一個(gè)額外的角色。這意味著有人做一些輔助活動(dòng)，例如：處理技術(shù)債務(wù)，或修復(fù)優(yōu)先級較低的錯(cuò)誤。當(dāng)代碼審查出現(xiàn)時(shí)，這個(gè)人就會(huì)立即放下當(dāng)前的任務(wù)，進(jìn)行PR工作。

2.修復(fù)觀念差異

我們在代碼審查中討論的內(nèi)容，在開發(fā)過程中做出的任何決定，無論何時(shí)何地都需要有同理心，都要站在對方的角度思考而不是從自身出發(fā)。

對于設(shè)計(jì)的決定需要在設(shè)計(jì)完成時(shí)就進(jìn)行，而不要等到編碼階段。當(dāng)然，這里需要一個(gè)額外的審查類型：設(shè)計(jì)審查。有時(shí)，問題具有挑戰(zhàn)性，就需要花一些時(shí)間在計(jì)劃上，與知識(shí)淵博的同事聊聊會(huì)有意外收獲。

有一句著名的軍事格言道：“沒有任何作戰(zhàn)計(jì)劃能在與敵人的接觸中幸存下來?！?/p>

如果把它翻譯成系統(tǒng)語言，應(yīng)該是："當(dāng)?shù)谝粋€(gè)反饋到來時(shí)，系統(tǒng)肯定需要進(jìn)行調(diào)整"。在編程過程中，反饋就是將設(shè)計(jì)實(shí)施到系統(tǒng)中所面臨的問題。因此，一些之前做出的決定需要修改的時(shí)候就應(yīng)該被修改。在修改的過程中，會(huì)因?yàn)橛^念和愿景的差異再次與評審員產(chǎn)生分歧。

Adam Thornhill在他那本 《軟件設(shè)計(jì)X射線》書中，提出了一種方法。

這就是為什么我建議你更早地進(jìn)行初步的代碼演練。與其等待一個(gè)功能的完成，不如在每一個(gè)功能完成三分之一的時(shí)候就進(jìn)行介紹和討論，這是一個(gè)慣例。少關(guān)注細(xì)節(jié)，多關(guān)注整體結(jié)構(gòu)、依賴關(guān)系，以及設(shè)計(jì)與問題領(lǐng)域的一致性如何。當(dāng)然，三分之一的完成度是主觀的，但它應(yīng)該是一個(gè)基本結(jié)構(gòu)到位、問題被很好地理解、并且存在初始測試的節(jié)點(diǎn)。在這個(gè)早期階段，重新設(shè)計(jì)仍然是一個(gè)可行的選擇，抓住潛在問題會(huì)有很大的回報(bào)。

受到上面話的啟發(fā)，我為我的團(tuán)隊(duì)創(chuàng)造了一句話：“架構(gòu)式審查”。我希望它有助于反映活動(dòng)背后的想法。

在代碼審查過程中，代碼創(chuàng)建者和審查者的愿景隨著時(shí)間的推移而出現(xiàn)分歧。

3.精益視角下的推薦處理方式

代碼審核的推薦處理方式可以消除或大大解決浪費(fèi)行為。

部分完成的工作。在代碼作者的預(yù)期時(shí)間內(nèi)切換到另一個(gè)任務(wù)是不允許的，所以不存在用戶意義上的部分完成的工作。優(yōu)先級較低的部分完成的活動(dòng)是權(quán)衡的結(jié)果。

再學(xué)習(xí)。由于在完成編碼和結(jié)對編程之間的時(shí)間很少，所以不會(huì)發(fā)生重新學(xué)習(xí)。

延遲。我們已經(jīng)大大縮短了代碼審查員的延遲，消除了作者的延遲。

任務(wù)轉(zhuǎn)換。對作者來說不再允許，而對審核者來說可以通過管理解決。

缺陷?，F(xiàn)在，修復(fù)設(shè)計(jì)缺陷變得更加便利，其中最重要的設(shè)計(jì)缺陷也變得可以修復(fù)了。

五、補(bǔ)充思考

我們已經(jīng)討論了單個(gè)作者和單個(gè)審查員的代碼審查方法和流程。當(dāng)更多的審查者出現(xiàn)時(shí)，問題會(huì)成倍增加。

在試圖引入推薦處理流程時(shí)，面臨兩個(gè)最具挑戰(zhàn)性問題：

第一，開發(fā)人員把審查階段當(dāng)作一項(xiàng)工作來完成。當(dāng)在日常工作中引入冗余人員會(huì)讓經(jīng)理們感到驚恐。解決這個(gè)問題的方法是適當(dāng)?shù)娜哂嗪图涌鞂徍说乃俣取?/p>

第二個(gè)問題更加復(fù)雜。在這里我想引用丹尼爾-瓦坎蒂《可預(yù)測的敏捷指標(biāo)》書中的一段話。

聯(lián)邦快遞采用了很多策略，但最重要的可能是，在任何時(shí)候聯(lián)邦快遞都有空飛機(jī)在空中。是的，我說的是空飛機(jī)。這樣一來，如果一個(gè)地方被淹沒了，或者如果包裹被遺棄了，如果安排的飛機(jī)已經(jīng)滿了，那么就會(huì)有一架空飛機(jī)被轉(zhuǎn)到問題地點(diǎn)（應(yīng)該說是及時(shí)的）。在任何時(shí)候，聯(lián)邦快遞都有 "備用飛機(jī)"!

如果你是一個(gè)經(jīng)理，下次在規(guī)劃利用率最大化時(shí)請考慮如下問題。（翻譯者：這里是讓經(jīng)理們考慮在產(chǎn)出最高，上升成本最低的情況下，為了軟件質(zhì)量，需要有部分的備份和冗余）

• 我們對這次更新滿意嗎？是的，它看起來比我們現(xiàn)在的情況要好。
• 我們能做得更好嗎？是的，我們可以。

如果目標(biāo)能在保證質(zhì)量的情況下達(dá)成，可以取消代碼審查。為了實(shí)現(xiàn)這個(gè)目標(biāo)，我們需要建立一個(gè)輔助決策框架，以幫助開發(fā)人員應(yīng)用最佳實(shí)踐。當(dāng)然，我們從來沒有聽說過這樣的框架，但in-IDE linters是向它邁出的一步。

原文鏈接：https://hackernoon.com/code-reviews-is-inherently-flawed-heres-how-to-fix-it

譯者介紹

崔皓，51CTO社區(qū)編輯，資深架構(gòu)師，擁有18年的軟件開發(fā)和架構(gòu)經(jīng)驗(yàn)，10年分布式架構(gòu)經(jīng)驗(yàn)。