背景介紹和難點

1.1 為什麼重視Code Review?

結合下面這個例子，我們來談談為什麼要重視code review。假設你作為新人剛入職，領導分配了一個需求，於是接下來做了下面這些事：

為了完成任務瘋狂敲了三天程式碼，
你將一個包含大約 800行新程式碼的commit提交MR，
收到兩條關於程式碼風格的意見，以及一個對某塊程式碼不是很理解的疑問，
修復了程式碼風格問題並回答了reviewer的問題，接著reviewer通過了你寫的程式碼，
把程式碼分支合併到 Master，自動化測試完成，沒有異常發生，
此後 幾個月，你一直戰戰兢兢，不知道程式碼何時會crash，以及以什麼方式crash…….
聽完這個例子我們是不是有共鳴呢？也許這就是發生在我們身邊的真例項子。

我們將code review的作用歸納為以下幾個方面：

給編碼者帶來良性的社交壓力。你正寫一個比較緊急的需求，團隊對程式碼的單元測試有一個要求：凡是新增的程式碼，必須有完整的單元測試以及需要達到一定覆蓋率。此時你是否會有這樣的想法，為了應付測試工具的覆蓋率要求，先寫一點不那麼有用但是能帶來覆蓋率的測試。但是，一旦想到你的程式碼將會有你的同事參與review，有沒有為剛才的這種想法產生一絲絲壓力？這種壓力是良性的，會阻止你去選擇這些隱患很大的“投機”行為。
提高程式碼質量和可維護性。通過review發現缺陷，統一程式碼規範，功能模組化等保障程式碼質量和可維護性。
查缺補漏，發現一些潛在的問題。比如效能是否存在瓶頸，平臺相容性，錯誤異常處理。
知識分享，review他人程式碼其實也是一個學習的過程，自己可以從中學習別人的優點，反思自己平常開發過程中的不足。
對需求的double-check，與開發前的方案評審形成閉環。
讓別人易看懂，讓程式碼可以傳承。

大多數缺陷是在編碼過程中產生，在測試中被發現和修復，隨著功能的測試上線，修復缺陷的成本也成指數級增長。因此code review作為測試後上線前的階段，發現缺陷和解決缺陷也變得尤為關鍵，有效避免缺陷留到線上造成巨大損失。

1.2 Code Review存在哪些通用性難點？

在瞭解了code review及其重要性後，接下來我們分析下code review的難點：

review程式碼本身並不困難，但是需要耗費不少時間和精力去了解專案背景，需求背景，方案設計，甚至還需要了解關聯模組的相關資訊。除了讀懂程式碼，還需要找到程式碼中測試沒有發現的潛在的問題，這對reviewer的專業素養有較高要求。
review一般要求儘快完成，避免持續太長時間因為雙方記憶的遺忘造成review效率降低。假如此時你很忙，code review的工作在一定程度上會造成很大的負擔。
雖然我們提倡儘量不要出現大的程式碼量提交MR，但是也不能犧牲功能的完整性。假如你一下子收到了幾千行需要被review的MR。是不是感覺很崩潰？

瞭解完code review及其難點後，接下來簡單介紹下TDSQL-C以及code review在TDSQL-C存在哪些難點。

1.3 TDSQL-C是什麼？

隨著網際網路的發展，各種業務資料快速膨脹，使用者對資料庫計算和儲存能力的需求日益增長。在應對業務需求持續增長時，傳統資料庫的迭代和優化已經變得舉步維艱，而分散式架構的優勢則愈發明顯。藉助計算儲存分離的架構，新硬體優勢，物理複製特點，分散式系統優勢，雲原生資料庫 TDSQL-C對比傳統MySQL具有高效能，低成本，大儲存，主從複製延遲低，秒級擴縮容，極速回檔，serverless化等優勢。

前面講了TDSQL-C相對傳統資料庫的優勢，那麼接下來講講code review在TDSQL-C存在哪些難點？從下面的對比圖可以看出，傳統MySQL的資料，邏輯日誌，物理日誌，元資料都是存在本地盤，主從管理各自的資料，通過邏輯日誌進行主從同步。TDSQL-C分為計算層和儲存層，本地不再儲存任何資料，共享儲存層資料，主從通過物理日誌進行同步，儲存層通過接受主庫傳送的物理日誌進行回放生成資料及元資料，不再需要邏輯日誌。架構的巨大改變帶來了以下問題：

TDSQL-C基於開源MySQL(系統複雜，專案總程式碼數百萬級別)，重構了日誌系統，IO模組，事務模組，啟動流程等多個模組，程式碼改動量巨大
TDSQL-C專案包括計算層，儲存層，分散式檔案系統，管控，運維等，參與人數眾多，程式碼改動牽一髮動全身
複雜的系統對研發，測試，code review都提出了極高要求

TDSQL-C Code Review流程

作為一個比較大的專案團隊，經歷多年的發展和優化，我們形成了目前的研發流程：

基於master分支建立屬於自己的分支；
在自己的分支上進行開發；(開發之前要記錄詳細的設計方案，郵件的方式傳送所有相關人及相關領導）
進行單元測試，效能測試，長穩測試，使用valgrind工具進行缺陷檢查
上述測試通過後提交MR，自動觸發單測，靜態缺陷檢測，生成覆蓋率報告
全量覆蓋率和增量覆蓋率均需要達到90%以上才合格。
通知reviewer進行code review，並提供issue單，設計文件和測試資料，author和reviewer進行接下來的code review
code review通過後合入master分支
出包，正式提測

在這個過程中，對author和reviewer有不同的要求：

對author的要求

每次提交code review的程式碼量要少
以文件或其它方式向reviewer介紹修改了哪些檔案，增加了什麼樣的功能

對reviewer的要求

把程式跑起來，除錯一下是否符合預期，
儘可能及時的進行 code review，
在你讀程式碼之前，先想想自己會怎麼做，

Code Review主要參照以下幾個方面進行：

程式碼書寫規範，是否遵照程式碼規範進行書寫，
程式碼實現與需求文件是否一致：核對需求單，
演算法優化，思考最佳實現方法：if else的八二法則等，
細節把控：記憶體釋放問題，錯誤處理，
註釋是否合理，
單元測試是否完善，
程式碼提交commit規範

寫好commit log很重要，它可以幫助我們快速瞭解這段程式碼的很多資訊。為了從commit log中獲取足夠多的資訊，我們對commit log有嚴格要求，每一個commit需要包括完整的資訊：

類別：bug修復還是功能開發，
Issue：本地提交對應的issue，
主題：本次commit的概述，
Problem：要解決什麼問題，
Solution：解決方法是什麼，
MR：MR編號是多少，
Reviewer：記錄reviewer同學

TDSQL-C CodeReview規範優化

前面介紹完了TDSQL-C的code review流程，接下來講一下我們TDSQL-C在多年的code review實踐中做的一些改進。

3.1 Code Review 的呈現形式

過去我們在評論裡直接寫上自己的意見，有時候給author沒有傳遞準確的資訊。

後來對Review的評論進行分級，不同級別打上不同的Tag：

[blocker]：程式碼行的問題必須要修改
[optional]：程式碼行的問題可改可不改
[question]：對程式碼行不理解，有問題需要問，author需要針對問題進行回覆澄清

3.2 定期覆盤

過去開發和線上穩定性維護的同學各司其職，缺乏有效反饋機制幫助開發人員瞭解線上會出現的一些通用性問題。

目前團隊每週進行一次線上穩定性分析會，主要針對目前線上遇到的問題，討論解決辦法及後期如何避免，經驗豐富的reviewer可以藉助這些經驗幫助author找到一些設計上，甚至是使用者使用上可能觸發的異常情況。

3.3 Code Review是一種開發文化而不是制度

Code review 的執行，很大程度上依賴於reviewer的認真審查，以及author的積極配合。過去往往流於形式，審查不夠嚴格。

後來Code Review變成團隊的一種文化，開發人員從心底接受並認真執行：

讓開發人員認識到Code Review這件事為自己、為團隊帶來的好處，
團隊負責人及資深工程師帶頭做好表率作用，
把code review作為開發任務的一部分，給author和reviewer都留出時間，
進行模組owner劃分，每個子模組由資深工程師把關，提升效率，
程式碼合入master時需要註明reviewer，author和reviewer對程式碼承擔同等責任，
團隊定期組織topic share，加強技術分享