對代碼評審的感想(回憶篇)
回想之前錢老板開代碼評審流程的討論會，有事沒去，有些遺憾，所以談下這個當前最fashion的話題，分享下之前對代碼等評審的體驗。
之前在CFT的研發氛圍還是比較重視代碼評審的，完成度也比較好，原因有以下幾個：
- 業務特性。我們是的業務跟錢打交道的，所以一發生問題，損失的都是錢，所以追責很嚴，懲罰很重，而且罰錢一般都罰老大，所以質量上的規范容易從上往下推動，事半功倍。當然線上出現問題，往往會讓QA(質量管理)追着問原因以及要求拿出改進措施，作為小兵也很煩很害怕有木有~
- 嚴格的流程。所有需求都是走需求系統，通過workflow電子流一步一步走下去，測試經理、測試、開發leader、運維leader有一個審批不過，就走不到上線發布。其中測試要求開發提供代碼評審結果，測試經理要求用例的評審，研發leader要求提供風險報告，並判斷是否要開安全評審，這三個評審都或多或少和代碼評審有關，這里順便都講下。
(1) 開發在提交代碼之前需要進行代碼評審，也有少數推到提測后再進行，這對測試來說很煩躁，因為測了一半了你跟我說要更新評審后的改動，早干嘛去了？
評審形式基本上都是線下訂個會議室講個半天，很少在線評審，由組長級帶頭，相關項目的開發人員對自己的代碼還有邏輯進行講解，然后總結改動點輸出會議紀要。
評審主要評審實現方法上的問題為主，很少涉及編碼規范和代碼結構方面的問題（一般不是新人的話這方面大家都會遵守），重點關注但不限於超時、鎖、系統調用、異常處理、數據字典設計等方面的問題。
測試會不會去參加代碼評審呢？一般會邀請測試參加，但效果並不是很好，究其原因主要有三:
- 沒有留太多的提前介入時間給測試。以前的系統是大系統下面多個子系統這樣子的，某個子系統的特性提測了，那么誰空閑了就誰去測，推崇的是測試人員的業務全精通，像我大部分時間測后台服務，有時候也被拉去測客戶端，或者支援其他項目，所以測試被邀請參加評審的時候手頭基本都是忙着其他項目，沒有預留提前介入的時間，所以往往會一頭霧水。
- 測試的代碼能力層次不齊。以前部門是很重視代碼的，在提交測試報告的時候還要用工具輸出代碼對比，意思便是：測試人員要知道開發改了什么，有什么影響，測試人員對代碼的檢視水平就慢慢上去了，有次漏測，組長還拉着我一起看代碼，問我為什么沒有看出來。但也有一些同事代碼能力比較弱的，去參加代碼評審就比較吃力。當然代碼能力並不決定測試水平，這個不能勉強。
- 有時候只有測試過才對流程和系統有着更深的思考。有時候測着測着發現有地方不合理或者動搖了之前的設計，總是感嘆在測試之前發現就好了，但是在測試前並沒有這么深刻的實踐和思考，所以在測試用例評審的時候才對於開發的實現邏輯有一些挑戰
(2)用例評審也是線下通過評審會的方式，主要在測試了一輪以后召開(這個時間點我覺得是蠻好的，測試對系統有了較深的認識)。邀請項目的開發，項目的測試人員，其他資深測試人員參與。主要由項目的測試人員講解系統實現和對應的測試用例
評審的范圍比一般的開發評審用例更為寬泛，對於系統設計或者代碼實現上有問題，可以提；如果開發邏輯有問題或者測試用例設計有問題，也會馬上拉出代碼一起確認，比如一個入參測試的用例為一個fee參數的長度超過32位報錯，遭到挑戰：為什么是32位，通過開發和代碼確認是因為fee字段的值類型用了int，評估后認為int太短，必須用long，於是開發和測試都要進行修正，而由開發評審用例一般看到這個的確符合了代碼邏輯往往就放過了。所以一般的評審結果里，測試的用例和開發的代碼都會有需要優化的地方。
(3)安全評審。項目需要出具風險報告；高風險的項目需要找安全接口人進行評審（組長或副總監級），講下涉及的風險點，解決的思路和實現的代碼。經常因為需要解決老大新提出的安全風險而延遲上線有木有，說多了都是淚。
風險報告的某一部分，比如這樣的
個人感覺代碼評審的好處有如下幾點：
- 對於開發來說。很多項目將模塊分給多人，然后大家分別開發或者是用先有代碼再有文檔這樣的開發模式開發，模塊之間的交互可能是支離破碎的，模塊代碼的風格不一、質量參差。通過評審，讓開發對互相的模塊有一定了解，同時針對自己不足的代碼先優化下，提高代碼質量。另外有新人的項目團隊，通過資深人士的review，也可以幫助新人更快融入項目，提高水平。
- 對於測試來說。參與代碼評審可以了解系統特性，需要關注的功能點，有時會請教開發這個地方如何測試或者要求開發給個工具或者加個開關，有助於測試用例的設計和后續的測試，當然最重要的：不要讓垃圾代碼浪費我時間。當然線下的評審可以討論，不懂還可以提問，比線上的評審有意思~~
當然缺點就是耗時~~如果開展了代碼評審但又不認真去做，那就是白白耗時。所以在CFT，大家開評審會還是蠻認真的，然而我不知道大家是真認識到了代碼評審的好處還是被流程束縛着。直到后來，之前在CFT的幾個開發組也一起去了WXG, 由於新部門沒有強制的代碼review流程，結果大家開始不做代碼評審了。。。這說明用流程強制容易，但讓質量意識深入人心，難啊~~所以，我一直想在項目中引入代碼評審，然而這不是用不用gerrit的問題，而是該如何讓開發心甘情願的接受代碼評審，用什么樣的方式去實現它並產生應有的效果的難題。