?譯者 | 崔皓

審校 | 孫淑娟

一、開篇

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1.BPMN透視

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

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

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

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

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

我們是否希望無限循環(huán)成為日常運(yùn)作的一部分？我不確定，因為擁有更快的交付通常是我們所期待的。

2.解決問題的方式方法

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

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

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

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

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

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

代碼審查備忘錄

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

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

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

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

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

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

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

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

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

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

代碼審查流程圖

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

五、補(bǔ)充思考

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

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

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

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

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

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

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

如果目標(biāo)能在保證質(zhì)量的情況下達(dá)成，可以取消代碼審查。為了實現(xiàn)這個目標(biāo)，我們需要建立一個輔助決策框架，以幫助開發(fā)人員應(yīng)用最佳實踐。當(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)驗，10年分布式架構(gòu)經(jīng)驗。