?譯者 | 崔皓

審校 | 孫淑娟

一、開篇

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

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

在《軟件工程的事實與謬誤》一書中，有這樣的描述：“嚴格的檢查可以在運行第一個測試用例之前消除軟件產品中高達90%的錯誤。”

Bob 對代碼審查的回復

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

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

• 設計檢查
• 單元測試前的代碼檢查
• 單元測試后的代碼檢查

Michael Fagan關于設計和規范檢查的文章中的一個方案

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

代碼檢查（Code inspection）看起來像現代的代碼審查（Code review）。那我們為什么今天會錯過其他類型的檢查？

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

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

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

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

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

三、現有的代碼審查有什么缺陷？

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

1.BPMN透視

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

經典的代碼審查流程圖

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

在修復之后，下一步就是通知審查員重新進行代碼審查了。

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

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

2.解決問題的方式方法

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

在經典的代碼審查過程中，代碼創建者和

審查者的觀點隨著時間的推移而出現分歧

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

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

3.人際關系的角度

代碼審查備忘錄

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

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

• 部分完成的工作
• 額外功能
• 重新學習
• 交接
• 延遲
• 任務轉換
• 缺陷

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

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

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

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

四、重新設計代碼審查

在本節中，我們將針對上面提出的問題，看看如何對其進行優化。

1.修復流程結構

代碼審查流程圖

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

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

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

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

2.修復觀念差異

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

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

有一句著名的軍事格言道：“沒有任何作戰計劃能在與敵人的接觸中幸存下來。”

如果把它翻譯成系統語言，應該是："當第一個反饋到來時，系統肯定需要進行調整"。在編程過程中，反饋就是將設計實施到系統中所面臨的問題。因此，一些之前做出的決定需要修改的時候就應該被修改。在修改的過程中，會因為觀念和愿景的差異再次與評審員產生分歧。

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

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

受到上面話的啟發，我為我的團隊創造了一句話：“架構式審查”。我希望它有助于反映活動背后的想法。

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

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

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

部分完成的工作。在代碼作者的預期時間內切換到另一個任務是不允許的，所以不存在用戶意義上的部分完成的工作。優先級較低的部分完成的活動是權衡的結果。

再學習。由于在完成編碼和結對編程之間的時間很少，所以不會發生重新學習。

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

任務轉換。對作者來說不再允許，而對審核者來說可以通過管理解決。

缺陷。現在，修復設計缺陷變得更加便利，其中最重要的設計缺陷也變得可以修復了。

五、補充思考

我們已經討論了單個作者和單個審查員的代碼審查方法和流程。當更多的審查者出現時，問題會成倍增加。

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

第一，開發人員把審查階段當作一項工作來完成。當在日常工作中引入冗余人員會讓經理們感到驚恐。解決這個問題的方法是適當的冗余和加快審核的速度。

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

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

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

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

如果目標能在保證質量的情況下達成，可以取消代碼審查。為了實現這個目標，我們需要建立一個輔助決策框架，以幫助開發人員應用最佳實踐。當然，我們從來沒有聽說過這樣的框架，但in-IDE linters是向它邁出的一步。

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

譯者介紹

崔皓，51CTO社區編輯，資深架構師，擁有18年的軟件開發和架構經驗，10年分布式架構經驗。