不做代碼審查又怎樣？

來源: TW洞見發布時間: 2019-07-11 18:43 閱讀: 4976 次推薦: 30 原文鏈接 [收藏]

　　從一次回顧會議開始

　　“要不……我們不做……代碼審查了……試試？”還記得當有人拋出這個建議時周圍同學的表情，那種表情用兩個字加兩個標點符號就可以形容：“什么？！”

　　對了，先介紹一下背景，這是項目一次普通的回顧會議，我們正在討論的是如何讓代碼審查更有效率和效果。我們做代碼審查的方式比較簡單直接，就是每日站會后，大家圍在一臺開發機周圍，逐一輪換講解昨天所有提交的內容，就像下圖中的那樣。還有，這是一個已經超過了7年的比較大型的項目，代碼審查是我們從項目開始就堅持的一個實踐，所以當有人提議廢除它的時候，這在很多同學心里是想都沒想過的事情。

　　代碼審查是一個很好的實踐，可以幫助團隊里的同學了解其他同學在做什么，可以分享項目的上下文，可以分享技術上的一些小魔法，可以發現很多潛在的代碼缺陷，可以提高代碼質量，還可以有很多很多好處……

　　但是，在真正的實施過程中，很多情況下并不像想象的那般美好，經常出現例如有些同學由于跟不上其他人講解的速度（畢竟不是自己寫的）或是沒有相關的上下文（例如剛加入項目的新成員），或是由于提交沒有被很好的切分和組織，導致整個過程都處于游離狀態（就像下圖中的我……毫無擺拍痕跡），而代碼審查的效果也打了折扣，漸漸的變成了一個流程，一個過場，一個習慣。

　　于是團隊里就有人站了出來，引導大家去發現背后的問題，也就引來了這樣一場激烈的討論。在討論中，有些同學堅持在說代碼審查還是很有用的，有這樣那樣的好處，需要保持下去；有些同學則非常實際地指出了執行上的各種困難和問題。討論異常激烈，直到有人小心翼翼地提出了文章開頭的那個建議，一片嘩然后大家都陷入沉寂：是啊，不做代碼審查了，我們會失去或是得到什么呢？

　　溝通的收益和成本

　　在我看來，代碼審查所暴露出的問題本質上就是如何權衡溝通的成本和收益的問題。

　　在軟件開發過程的發展中，無論是從一開始的瀑布，后來的敏捷，還是當下的精益。都有很大一部分篇幅是在強調溝通或者說是強調溝通方式的演進，都是為了解決已有溝通方式所帶來的各種限制和問題。

　　例如在我們自己的項目中就采用以下的實踐來促進團隊內外的溝通，包括：迭代計劃會（Iteration Planning Meeting），每日站會（Daily Standup），代碼評審會（Code Review），回顧會議（Retrospective Meeting）；還有XP中的結對編程(Pair programming)，現場客戶 ( On-site Customer )等。

　　而溝通的好處是可以得到快速的反饋，無論是80年之前就出現的PDCA環還是前兩年大熱的精益創業，都是在強調快速反饋和基于反饋的快速迭代，通過這種方式來消除生產和創業過程中造成的各種浪費。

　　但是（對，又是但是……），溝通也是有成本的，而且成本一般都還不低，相信這點也不需要多解釋，大家肯定都經歷過各種各樣效率極低令人抓狂的討論或是會議。

　　在溝通的成本和收益同時擺在我們面前，如何做出選擇？如何才能設計一套剛剛好的溝通體系，平衡收益與成本，來滿足團隊和項目的需要呢？

　　溝通金字塔

　　在讀《重構》的時候，我深深地體會到：這個世界上沒有什么是不變的，包括變化本身。所以要想得到解脫，我們就需要從簡單的對與錯，好與壞的漩渦中跳脫出來，用變化的眼光來看待周圍的事物，并做好一直變化的準備。

　　而面對溝通成本與收益的選擇困境時，我第一個想到的就是測試金字塔。了解測試金字塔的同學肯定都知道，測試金字塔是一個很好的工具，它幫助我們從單一的測試選擇困境中跳脫出來，將各種不同類型的測試建立起關聯、納入一個統一的體系，從而讓我們可以在一個更高的維度來系統的思考和審視每一種測試的策略，關注點也從簡單的“該不該”變為了“如何變化”。

　　至于“如何變化”？我們可以通過在金字塔上添加一層新的測試種類來彌補整體測試策略中粒度太粗的問題；也可以根據項目情況通過移除一層測試種類，用其上層或是下層的測試來覆蓋其測試用例，來減少成本；也可以通過將某個測試用例在金字塔中向上層或是向下層移動來尋找收益與成本的平衡。

　　舉個實際點兒的例子，例如我可以將一些基于UI的集成測試用例下移，用成本更低的單元測試來覆蓋從而減少成本，加快反饋速度；也可以將一個單元測試用例上移，用基于UI的測試來增加其穩定性的和體現的業務價值。

　　看，我們討論的內容從簡單的要不要寫UI測試，需要寫多少單元測試測試已經被轉換到對于整體策略的變化和調整上來了。那對于代碼審查的問題能否也通過金字塔這個工具轉換到更大的空間上尋求突破呢？這就是溝通金字塔。

　　相比于測試金字塔中的“UI－－Service－－UT，“Iteration Planning Meeting（見上圖）－－ Code Review（見上上上圖）－－ Pair programming（見下圖）”就可以類比成溝通金字塔，和測試金字塔一樣更靠近金字塔頂端的（例如迭代計劃會）溝通頻率越低，成本越高，但越接近業務；越靠近金字塔底端的（例如結對編程）溝通頻率越高，成本越低，越接近實現。這幾種不同的溝通方式所溝通的內容肯定也會有所重疊，通過將各個層次的溝通方式進行組合來保證我們團隊的整體溝通質量，就像通過金字塔中的各種測試層次的組合來保證產品質量的一樣。

　　如果可以這么類比的話，那我們對于溝通質量的管理也應該是動態的、系統的、從整體上出發的。例如就可以通過在溝通金字塔中添加一層新的溝通機制來彌補溝通粒度過粗的問題，例如QA Team現在在做的每周例會就是一個好的例子；也可以將一些溝通內容通過層次（上下）的調整，甚至是通過直接減少一層溝通方式來優化我們的整體溝通效率，例如我們可以通過增加結對編程的Switch頻度來替換掉成本更高的代碼審查。而目標就是通過不斷地動態調整和優化溝通結構，試圖尋求一個溝通成本，溝通收益，溝通效率平衡的溝通環境。

　　回到問題上來

　　如果溝通金字塔的理論說的通，那代碼評審就不再是一個：“必須要做的敏捷實踐”，而只是溝通金字塔上的一層而已。那它的存在必然是為了彌補上下層溝通之間的空隙，那這個空隙到底是什么呢？是什么樣的溝通是結對編程所不能覆蓋，而用類似于迭代計劃會這種更高層的溝通機制覆蓋又不太經濟的呢？為了讓團隊重新找回這個答案，我們最終決定試一試：停止代碼審查一個月，在這一個月的時間我們去體會沒有代碼審查的得與失，在一個月之后重新舉行回顧會議再來討論是否要繼續做代碼審查。

　　在一個月后如期進行的回顧會議上，團隊又重新討論了這個議題，最終覺得通過這一個月的嘗試，在還無法做到更頻繁地Switch Pair的情況下，代碼審查還是很有必要的。例如在這個月中，大家對于其他人在做的工作了解變少，集成出現了很多沖突；缺陷的數量也有所增加，其中有些是很明顯的錯誤，很容易通過代碼審查的方式發現并在前期消除；代碼質量也有明顯下降，出現了測試的缺失和很多代碼壞味道。

　　而另一方面為了讓代碼審查能夠真正的發揮其作用和價值，經過討論我們也優化了代碼審查的方式，讓大家更有參與感，更有效率，也更有樂趣（見下圖抓拍）。