怎么做好Code Review?
團隊為什么要做好Code Review？
一、Code Review的好處
?Code Reviewa可以保證項目質量，推升團隊技術水平
?
想要做好Code Review，必須讓參與的工程師充分認識到Code Review的好處
1、互相學習，彼此成就
2、知識共享，自動互備
3、統(tǒng)一風格，提升質量
二、推動Code Review落地執(zhí)行
1、選定工具
可以用來做Code Review的工具很多，這里主要介紹相對主流的Gerrit、GitLab
Gerrit
?Gerrit是Google開源的代碼審查工具，Gerrit也是一個基于Git構建的版本管理工具，Gerrit支持將其他Git倉庫的代碼跟Gerrit自己的倉庫做同步。所有的代碼審查的操作以及權限控制都是在Gerrit自己的倉庫上進行的。
?
GitLab家族
?GitLab是基于Git構建的源代碼管理系統(tǒng)，基于GitLab構建的 GitLab.com 是僅次于 GitHub.com 的在線源代碼管理平臺。
?
2、制定開發(fā)規(guī)范
?沒有規(guī)則，就沒有執(zhí)行。規(guī)則中首當其沖的就是開發(fā)規(guī)范。
?
規(guī)范中建議包含：
工程規(guī)范（工程結構，分層方式及命名等等） 命名規(guī)范（接口、類、方法名、變量名等） 代碼格式（括號、空格、換行、縮進等） 注釋規(guī)范（規(guī)定必要的注釋） 日志規(guī)范（合理的記錄必要的日志） 各種推薦與不推薦的代碼示例
3.制定流程規(guī)范
確定Code Review實施環(huán)節(jié) 確定Code Review實施環(huán)節(jié)
code review 行話
?最后分享下code review 行話
?
| 簡稱 | 全稱（解釋） |
|---|---|
| LGTM | Looks Good To Me「對我來說，還不錯」表示認可這次PR，同意merge合并代碼到遠程倉庫 |
| ASAP | As Soon As Possible「盡快」 |
| ACK | Acknowledgement「承認，確認，同意」i.e. agreed/accepted change |
| NACK/NAK | Negative acknowledgement「不同意」 i.e. disagree with change and/or concept |
| RFC | Request For Comments「請求進行討論」 i.e. I think this is a good idea, lets discuss |
| WIP | Work In Progress 「進展中」常見詞匯，這里作為 Best Practice 單獨提出來，主要針對改動較多的 PR，可以先提交部分，標題或 Tag 加上 WIP，表示尚未完成，這樣別人可以先 review 已提交的部分 |
| AFAIK/AFAICT | As Far As I Know / Can Tell 「據我所知；就我所知」 |
| IIRC | If I Recall Correctly「如果我沒有記錯的話」 |
| IANAL | I am not a lawyer , but I smell licensing issues「-」 |
| IMO | In My Opinion 「在我看來」 |
| TL;DR | Too Long; Didn’t Read 「太長懶得看」README 文檔常見。 |
| PR | Pull Request「合并請求」 |
| CR | Code Review 「代碼審查」 |
| PTAL | Please Take A Look.「你來瞅瞅？」用來提示別人來看一下 |
| TBR | To Be Reviewed「提示維護者進行 review」 |
| TBD | To Be Done(or Defined/Discussed/Decided/Determined). 「未完成，將被做」根據語境不同意義有所區(qū)別，但一般都是還沒搞定的意思。 |
| TBH | To Be Honest 「老實說」 |
| atm | at the moment 「現階段」 |
評論
圖片
表情