也談談CodeReview

文章目錄

前言

Talk is cheap. Show me the code.

So, Let’s go!

一個注重技術規範和分享的團隊，往往會做好Code review工作，在緊張的項目之餘，爲了後期的效率和技術上的提高，我們需要引入Code review。本文是第一次準備Code Review時查閱了大量相關資料，整理總結形成本文，後期的博客中會記錄第一次Code review的實例。希望對你有所幫助。

爲什麼要Code review？

提高代碼整理質量，提前發現bug,不留技術債務，利於後期維護。

一個項目就像有很多窗戶的房子，當有人打碎一扇窗戶而沒人管時，會有人打碎更多的窗戶，一個項目隨着時間的推移，慢慢變成了一堆垃圾，無法維護下去，只能全部重來。

提高了團隊成員對他人代碼的熟悉程度，對整個項目的現狀也有清晰的認識，在需要接替任務，在同事基礎上繼續維護項目時，有助於快速進入感覺。
從成員角度看，有助於養成良好習慣，代碼書寫更加規範，整潔。隨着習慣的養成，後期將會逐漸轉化爲文化與技術的交流，會對技術還是境界都有一定的提升。從團隊來看，有助於形成積極的技術氛圍，融洽的關係。

Code review 工作範疇

檢查代碼是否整潔，命名是否規範合理及語法問題。

多一個空格，少一個空行這種格式問題，儘量通過自動化工具完成，不要浪費他人寶貴的時間，主要是檢查命名是否明白易懂
檢查邏輯是否正確，清晰
檢查是否有可改進的地方，更高效的方法、算法。
架構是否靈活，合理。

小結：讓團隊Code review前，先做好自查。比如，在Android團隊開發中，先根據事先團隊約定的開發規範自查。Code review前，團隊得有一個Code review清單，類似這樣的Android開發代碼規範總結

團隊成員對code review 應該有什麼樣的態度

Code Review不是批鬥會，評審者不能以錯誤、缺陷打擊成員的積極性
作者應該以學習的態度虛心接受評審員的建議，遇到分歧可以討論。
評審員職責是發現問題，跟蹤改進，不是替作者修改。作者同意後應該按建議自行修改。
作者不要過分依賴於審覈，要在提交前自己先檢查，避免浪費他人的時間。

小結：虛心使人進步，多思考別人的思考方式和不同的技術思路。

高效執行 code review 面臨的挑戰

上級領導不認可，認爲浪費時間，團隊很難執行下去，團隊之間不接受批評建議也很難開展下去，團隊技術氛圍很重要。
時間緊任務重。先快速迭代完成任務，新功能可能隨時被砍掉，不要過早優化。
團隊成員沒有提高自身技能與素養的意願。需要有極客精神，對代碼質量有自身要求，敢於嘗試新鮮技術，希望更上一層樓。
不認同價值觀

是人的複雜讓本來簡單的事情變得異常複雜。如何通過成員間討論設計出所有成員都認同的規則，形成所有人認同的價值觀對事情的可持續發展至關重要。

實踐方案

先確定代碼規範，git使用規範，代碼審覈機制。
先按代碼規範自查。
至少有一名經驗較他人豐富的骨幹成員當主審，以及不限數量的其他成員作爲可選審覈員。代碼通過需要至少一個主審同意，所有審覈員都可以對代碼發表意見。
審覈時機確定

固定時間段或項目結束後進行。在項目中待優化的地方加上TODO, 有時間及時優化。
激勵機制

對code review 中積極幫助他人，分享大量知識，及時發現重大bug的成員進行獎勵。

如何有效開展CodeReview活動？

1、代碼規範：明確Coding規則

如果一開始不定義好團隊Coding標準，那在檢視過程中就會存在兩種情況：一種是各種不同的意見很難快速達成一致，影響review效率，另外一種是團隊根本就不會重視代碼規範的檢視，如果是前者還好，畢竟大家都還在關注什麼寫法是好的或對的這個問題，只要中途願意建立起Coding規則，問題就能很快解決。而筆者跟進過的一個團隊恰恰就出現了後者的情況：該團隊由於前期沒有明確Coding規則，過程中大部分開發人員對規範類問題直接無視，CodeReview運作一段時間後代碼中依然存在命名不規範，可讀性較差等問題，直接影響了活動效果，這是我們非常不願意看到的。

當然也有團隊負責人說了，每天糾結於空格少了，行數字符多了等細節問題沒意義啊，不想浪費這個時間，因此我們不需要代碼規範。我個人不認同這個觀點，因爲代碼規範並不只包括空格和字符等約束緯度，還包括了註釋的要求，命名的規範，命名是否詞能達意，代碼結構安排等等影響代碼可讀性的因素，如若這些方面連基本規則都沒有，那一定會出現之前說的那兩種情況（爭議太多 or 完全忽視），效果可想而知。所以你可以根據自己的看法或需求做一定的規則定製，但不能沒有Coding規則。

2、檢視指南：消除困惑和迷茫

檢視指南又名CodeReview-checklist。一個團隊並不是所有人都是老司機，有很多同學是沒有代碼review經驗的，他們往往不知道應該重點 check哪些點。

這個時候結合自身業務特點和團隊之前踩過的坑，制定一個checklist是非常必要的:

什麼寫法可能導致性能低下？
哪個接口要慎用？
哪些設計方式需要規避？
什麼習慣容易引發內存泄漏？
等等。。。

這樣可以讓經驗不足者在不知道要review什麼時，能有的放矢，過程中逐步積累起經驗。

Code review 工具推薦

GitLab

GitLab,GitHub這些倉庫託管平臺如今也具有code review 功能，基本可以滿足需求。

Gerrit

Gerrit 是一個基於 web 的代碼評審工具, 它基於 git 版本控制系統。Gerrit 旨在提供一個輕量級框架, 用於在代碼入庫之前對每個提交進行審閱。這是比較流行的code review 工具，是谷歌用來管理Android項目的工具。

流程：

（流程git review提交代碼 -> 提交到Gerrit庫 -> 觸發Jenkins自動測試，測試通過Verified -> 人工審覈Review，review通過 -> Gerrit執行Replication -> push Git remote）
SonarQube

代碼質量管理平臺，具有完善的功能，適合對代碼質量要求很高的團隊。