1.開(kāi)篇

5月份的時(shí)候突然接到 code.oa.com【騰訊內(nèi)部的一個(gè)代碼管理平臺(tái)】 的 summer 的通知， 說(shuō)廣點(diǎn)通的codereview 參與度在公司各部門中表現(xiàn)出色，而我們小組（廣點(diǎn)通廣告定向小組）的 codereview 綜合表現(xiàn)在全公司的小組中***。這讓我有點(diǎn)意外，有點(diǎn)無(wú)心插柳的感覺(jué)。 summer 希望我能寫寫我們小組做 code review 的一些心得體驗(yàn)， 回想我學(xué)習(xí)使用 codereview 的經(jīng)歷， 我***想到的一句話是我?guī)啄昵翱吹降年P(guān)于 codereview 的一句評(píng)述：

The biggest thing that makes Google’s code so good is simple: code review.That’s not specific to Google – it’s widely recognized as a good idea, and a lot of people do it. But I’ve never seen another large company where it was such a universal. At Google, no code, for any product, for any project, gets checked in until it gets a positive review.

http://scientopia.org/blogs/goodmath/2011/07/06/things-everyone-should-do-code-review/

這是一段讓我記憶深刻的話， 一個(gè)Google 工程師寫的， 我摘錄下來(lái)做作為文章的開(kāi)始，表達(dá)我在騰訊這些年和一些出色的工程師合作的過(guò)程中一起學(xué)習(xí)和實(shí)踐 CodeReview 之后， 對(duì)CodeReview 文化的一種由衷的認(rèn)同和尊敬。

2.Rietveld

我 2008 年進(jìn)入騰訊， 主要呆在 R2參與soso 的開(kāi)發(fā)， 從 2008 ~ 2010 年我都很不屑于 R2 的研發(fā)質(zhì)量管理，覺(jué)得做得實(shí)在很糟糕：沒(méi)有統(tǒng)一的編碼規(guī)范、沒(méi)有unittest，甚至經(jīng)歷過(guò)有些人不會(huì)用 svn, 不太懂代碼的版本控制， 當(dāng)然我自己也不怎么懂開(kāi)發(fā)流程中的質(zhì)量管理， 那時(shí)候連 codereview 是什么都沒(méi)聽(tīng)說(shuō)過(guò)。2010年初， 公司開(kāi)始在搜索上加大投入， 招聘了一些牛人，尤其是 Google 的一些工程師， 而這些人也把 Google 的一些開(kāi)發(fā)文化帶入了 R2。雖然 soso 最終的命運(yùn)并不如人所愿， 但是在 2010~2013年間， 許多soso 的工程師是學(xué)習(xí)并經(jīng)歷了什么是嚴(yán)謹(jǐn)而強(qiáng)大的開(kāi)發(fā)流程，也見(jiàn)過(guò)我們?cè)?jīng)山寨的 Google 的技術(shù)， 以及山寨的 Google 的開(kāi)發(fā)流程。 而至今為止，我們和很多同事回憶起來(lái)，我們常調(diào)侃說(shuō)我們是見(jiàn)過(guò)豬跑也吃過(guò)豬肉的。

2010年4月從Google 來(lái)到我們部門的一位牛人是 yiwang, 做機(jī)器學(xué)習(xí)的博士， 做了一次 LDA topic modeling 的報(bào)告， 令人印象深刻， 接觸了幾次之后，我主動(dòng)找了 yiwang 一起合作，學(xué)習(xí) LDA 并參與并行 topic modeling 的開(kāi)發(fā)。yiwang 讓我做的***件事就是研究一下 Google 開(kāi)源的 Rietveld code review 系統(tǒng)， 并找一臺(tái)機(jī)器把 Rietveld 搭建起來(lái)。于是一頓折騰之后， 我們搭建了公司的***套嚴(yán)格意義上的 codereview 系統(tǒng)， 當(dāng)然那個(gè)時(shí)候也只是供我們小組內(nèi)自己使用。 搭建好 Rietveld 之后， 我們做的第二件事就是把 code style 都統(tǒng)一到 Google 發(fā)布的 C++ coding style。 最早在這套系統(tǒng)上進(jìn)行 codereview 的就是4個(gè)工程師 yiwang, leostarzhou, charlieyan, 和我。

所有和 yiwang 合作過(guò)的人在 codereview 中都苦不堪言， 他是近乎苛刻的嚴(yán)格執(zhí)行 Google C++ coding style, 我們提交的的 code 中多一個(gè)空格，多一個(gè)空行；或者是注釋符號(hào) “//” 后面少一個(gè)空格， 全都被打回來(lái)修改；更別說(shuō)變量、函數(shù)名命名不符合規(guī)范，隨意使用變量縮寫這些大的禁區(qū)了。對(duì)于我們最初的代碼， yiwang 挨個(gè)細(xì)致的指出我們違反規(guī)范的地方， 在 comment 中貼上Google C++ 規(guī)范的具體要求的 URL anchor， 以說(shuō)明我們?yōu)楹芜`反了規(guī)范。 一開(kāi)始我是有點(diǎn)不以為然的， 來(lái)回幾次之后我自己也不好意思了， 把 Google coding style 從頭到尾仔仔細(xì)細(xì)的看上3遍， 認(rèn)真的記住一些細(xì)節(jié)， 于是很快就開(kāi)始上手了。

自然， 后續(xù)我們合作的工程師逐漸多了起來(lái)， 對(duì)于 codereview 的必要性，許多人是有質(zhì)疑和挑戰(zhàn)的， 于是在和yiwang合作的幾年里， 我反復(fù)聽(tīng)他說(shuō)了三個(gè)故事。

***個(gè)是關(guān)于他自己的，他從小開(kāi)始 coding, 高中的時(shí)候已經(jīng)拿到工程師的認(rèn)證，進(jìn)入 Google 之前 coding 無(wú)數(shù)， 進(jìn)入 Google 之后寫的***個(gè)100行的程序， 被貼的 comment 超過(guò)了100行。 所以不要抱怨我們的標(biāo)準(zhǔn)嚴(yán)格， 嚴(yán)格的標(biāo)準(zhǔn)才能產(chǎn)出漂亮的代碼， 我們今天在騰訊做的 codereview 真是不算啥。

第二個(gè)是關(guān)于Google 內(nèi)部 codereview 的爭(zhēng)議的， 據(jù)說(shuō) Google 內(nèi)部建立 codereview 制度的時(shí)候，也是很多工程師不樂(lè)意， 尤其是年長(zhǎng)的工程師， 寫了多少年代碼了， 被一群年輕的小屁孩在代碼上指指點(diǎn)點(diǎn)，實(shí)在是受不了。 ***說(shuō)是 Google 的一位極有地位的人物出來(lái)說(shuō)話了：我們要想把工程質(zhì)量控制好， 無(wú)論是資歷深淺，都一定要遵守共同的代碼規(guī)范，于是 codereview 制度得以建立。

第三個(gè)是解釋為何要用 Google C++ coding style 的， Google 的代碼規(guī)范是一群***的 coder 制定的， 變量名用小寫， 函數(shù)名用駝峰式， 那都是有嚴(yán)格的視覺(jué)美學(xué)講究的，讓人看了很舒服的，甚至是做過(guò)視覺(jué)對(duì)照研究的。雖然我對(duì)此存疑, 我還是認(rèn)同 Google C++ coding style 是我見(jiàn)過(guò)的***的 coding style。 而我們騰訊的一位 HR 在和我閑聊的時(shí)候也表示過(guò)同樣的觀點(diǎn) :-)。

Coding style 的規(guī)則制定很多都是相對(duì)的， 而Google style做得 NB 的地方就是， 他設(shè)定的大多數(shù)規(guī)則的目的他并不是要證明自己是正確的， 而是詳細(xì)的列出各規(guī)則的優(yōu)缺點(diǎn)(pros and cons)，讓你更深刻的理解這些規(guī)則。著名的統(tǒng)計(jì)學(xué)家 George E.P. Box 在數(shù)據(jù)建模中說(shuō)過(guò)一句廣為流傳的話： All models are wrong, but some are useful. 套用這句話到 code review 的 coding style 中， 我想說(shuō) All coding rules are wrong, but some are useful。當(dāng)然 Google style 好的一個(gè)額外的原因是 Google 提供了 cpplint 這個(gè)工具自動(dòng)檢查你的 code 中是否有違反規(guī)范的地方， 大部分的低級(jí)錯(cuò)誤都會(huì)被檢查出來(lái)。

3.推廣 CodeReview

我們小組剛開(kāi)始把 Google 的 Rietveld 在內(nèi)部搭建起來(lái)并在部門內(nèi)推廣使用以后， 發(fā)現(xiàn)了一些問(wèn)題， 主要包括：

1.issue 提交之后如何通過(guò) email 發(fā)送到公司的 outlook 帳號(hào)

2.Rietveld 提供的提交 issue 的工具 upload.py 對(duì)中文的支持不好

3.底層用的文本文件做存儲(chǔ)， 訪問(wèn)量大的時(shí)候，提交 issue 多的時(shí)候， 速度不行

前面兩個(gè)問(wèn)題charlieyan 和我對(duì) Rietveld 的 python 源代碼做了一些修改， 很快解決了。 第3個(gè)問(wèn)題我們一直解決得不好。 不過(guò)當(dāng)時(shí)來(lái)說(shuō)支撐我們幾個(gè)小組的開(kāi)發(fā)還是 OK的。 所以 yiwang 開(kāi)始繼續(xù)推動(dòng) Rietveld 在 R2 的使用。 到了 2011 年的時(shí)候這套工具已經(jīng)在 R2 的多個(gè)部門被使用了。 下面一張圖是我們?cè)?jīng)統(tǒng)計(jì)過(guò)的各個(gè)部門當(dāng)時(shí)的使用情況

2010 年我們?cè)谕茝V codereview 的時(shí)候， yiwang 也聯(lián)系了研發(fā)管理部的同事， 也就是 code.oa.com 的維護(hù)人員， 當(dāng)時(shí) code.oa.com 并沒(méi)有嚴(yán)格意義的 codereview 功能。 它提供一個(gè)代碼 checkin 之后進(jìn)行 codereview 的功能， 所以也沒(méi)有發(fā)送 codereview 的 upload.py 腳本；這個(gè)功能自然是有用的，但是事后的 review 往往有缺陷， 很難替代事前的 review。事實(shí)上更重要的問(wèn)題是， 公司內(nèi)部當(dāng)時(shí)并沒(méi)有形成 codereview 的文化。 yiwang 和研發(fā)管理部的人交流的時(shí)候強(qiáng)烈的推薦了 Rietveld 系統(tǒng)， 不久之后code.oa.com 也仿照 Rietveld 開(kāi)發(fā)了正式的 codereview 功能，而用于提交issue 的 tcr.py 也正是基于Rietveld 的 upload.py 做的修改。

而在搜搜內(nèi)部，狀況則有些不同。 Google 來(lái)的朱會(huì)燦帶領(lǐng)的搜索云平臺(tái)(搜索基礎(chǔ)架構(gòu)部）對(duì) codereview 文化建設(shè)做了強(qiáng)力的推動(dòng)， 基礎(chǔ)架構(gòu)部門的幾個(gè)牛人開(kāi)始使用這套系統(tǒng)之后， wujie, phong 他們接管了這套 CodeReview 系統(tǒng)， 當(dāng)時(shí)上面提到的第三個(gè)問(wèn)題當(dāng)時(shí)已經(jīng)成為了一個(gè)嚴(yán)重的問(wèn)題， wujie， phong 開(kāi)始改進(jìn) Rietveld 的性能問(wèn)題， 把底層的文本文件存儲(chǔ)替換為 mysql 數(shù)據(jù)庫(kù)， 使用 apache 服務(wù)器替換了 Rietvled 基于 Django 的 HttpServer, 所以Rietveld 第三個(gè)和性能相關(guān)的問(wèn)題也徹底被解決了。 后續(xù) huanyu 申請(qǐng)了 codereview.soso.oa.com 這個(gè)域名專門提供 codereview 服務(wù)， 于是直到搜搜和搜狗合并， 搜搜內(nèi)部的好幾個(gè)部門的兄弟們一直基于 Rietveld 系統(tǒng)做 codereview。

4.C++ Readability

搜索廣告部門的情境廣告中心應(yīng)該是我經(jīng)歷的 code review 文化建立得最徹底完善的地方。 當(dāng)時(shí) yiwang 是這個(gè)中心的總監(jiān)，我和 huan 各負(fù)責(zé)一個(gè)小組， 我們中心要負(fù)責(zé)開(kāi)發(fā)一套 AFC(ads for content) 的情境廣告產(chǎn)品， 和現(xiàn)在廣點(diǎn)通有很多相似之處。 huan, yiwang, 包括我們的 GM paulyan 都是 Google 的工程師， 而 AFC 這個(gè)產(chǎn)品幾乎是從零開(kāi)始開(kāi)發(fā)， 所以很自然的， 許多開(kāi)發(fā)流程都是山寨的 Google 的， 雖然 AFC 這個(gè)產(chǎn)品最終由于各種原因并沒(méi)有在公司內(nèi)部成功， 但是許多參與開(kāi)發(fā)的工程師對(duì)于我們當(dāng)時(shí)建立起來(lái)的開(kāi)發(fā)流程應(yīng)該是印象深刻的。 當(dāng)然 codereview 是其中很重要的一個(gè)環(huán)節(jié)。 Huan 借鑒 Google 的CodeReview 流程， 在中心推動(dòng)了一個(gè) C++ readability 制度的建立。 一個(gè)語(yǔ)言的 readability 表示工程師對(duì)這個(gè)語(yǔ)言和相應(yīng)的編碼規(guī)范的熟悉， 這個(gè) C++ readability 最初只授予有限幾個(gè)高職級(jí)的工程師。 每一個(gè) codereview issue 至少需要得到一位具有 C++ readabiltiy 的工程師的認(rèn)可， 這個(gè) issue 才能夠提交到代碼庫(kù)中。

而每一個(gè)沒(méi)有 C++ readability 的工程師要想獲得這個(gè) readability, 需要提交一個(gè) codereview issue 做專門的申請(qǐng)， 這個(gè)issue 的標(biāo)題必須包含 “Apply for C++ Readability”, issue 至少包含三個(gè)文件， xxx.cc, xxx.h, xxx_test.cc, 如果這個(gè) issue 通過(guò)嚴(yán)格的 codereview 被通過(guò)了， 就可以授予這個(gè)工程師 C++ readability 。 而通常這種申請(qǐng)的 review 過(guò)程大家都會(huì)特別的認(rèn)真細(xì)致。

5.在廣點(diǎn)通 CodeReview

[[131760]]

2013年10月， 搜索廣告平臺(tái)部并入廣點(diǎn)通成立了SNG 的效果廣告平臺(tái)部， 原來(lái)AFC 的系統(tǒng)由于這個(gè)合并事實(shí)上基本廢棄， 只是在開(kāi)發(fā)過(guò)程中很多模塊組件被逐步遷移到了廣點(diǎn)通的系統(tǒng)上。 我們剛進(jìn)入廣點(diǎn)通的時(shí)候， 廣點(diǎn)通使用 code.oa.com 平臺(tái)做 codereview, 也建立了一些 codereview 的文化， 但是有很多地方是執(zhí)行不到位的。 coding style 雖然也推崇 Google coding style, 但是執(zhí)行上不嚴(yán)格， 所以整個(gè)代碼庫(kù)的代碼風(fēng)格是很不統(tǒng)一的。 這也給我們的 codereview 執(zhí)行帶來(lái)很大的挑戰(zhàn)：

舊的代碼風(fēng)格不統(tǒng)一，我們?nèi)绾谓y(tǒng)一代碼風(fēng)格， 舊的代碼是否需要基于新的風(fēng)格重寫？

整個(gè)產(chǎn)品都在高速的開(kāi)發(fā)迭代中，老大對(duì)于產(chǎn)品功能的開(kāi)發(fā)演進(jìn)有明確的期望， 產(chǎn)品經(jīng)理天天在開(kāi)發(fā)人員后面催進(jìn)度， 我們是否要執(zhí)行嚴(yán)格的 code review ？

廣點(diǎn)通***還是明確的規(guī)定 coding style 統(tǒng)一到 Google C++ coding style， 我們團(tuán)隊(duì)的 CodeReview 也整體轉(zhuǎn)戰(zhàn) code.oa.com, 我們自己不再使用 Rietveld（不過(guò)這套系統(tǒng)并沒(méi)有被廢棄， wujie 2014年一月的時(shí)候把這套系統(tǒng)搭建起來(lái)服務(wù)于微信， 并申請(qǐng)了域名 cr.oa.com), code.oa.com 的 CodeReview 功能經(jīng)過(guò)幾年的改進(jìn)， 也確實(shí)變得很好用。 考慮到產(chǎn)品迭代的節(jié)奏， 我們廣告質(zhì)量中心在推進(jìn)的過(guò)程是漸進(jìn)的：

所有新提交的文件必須使用 google style

所有新修改的代碼必須使用 google style

在指定的時(shí)間范圍內(nèi)， 重要模塊的 code 必須重構(gòu)為 google style

為了讓 codereview 文化在廣點(diǎn)通能更加徹底的建立起來(lái)、執(zhí)行到位， 幾位總監(jiān)和架構(gòu)師也迅速推動(dòng) code.oa.com 中實(shí)現(xiàn)了 code owner 的機(jī)制， 每個(gè)目錄下面明確設(shè)置 code owner, 每個(gè)change issue 要想提交， 必須有 code owner 通過(guò)才可以。 而剛開(kāi)始執(zhí)行的時(shí)候， 廣告質(zhì)量中心為了保證 code review 執(zhí)行到位， code review 是非常集權(quán)的， 所有相關(guān)目錄的 owner 只寫上總監(jiān)。所以質(zhì)量中心發(fā)出的所有 code review issue 只有總監(jiān)通過(guò)了之后才可以提交， 在一定的時(shí)間內(nèi)這確實(shí)影響開(kāi)發(fā)效率， 不過(guò)對(duì)教育所有開(kāi)發(fā)人員的 code review 意識(shí)是高效的。 在經(jīng)歷了近三周的嚴(yán)格控制之后， 目錄的owner 才加上組長(zhǎng)， 然后逐步放開(kāi)到組內(nèi)的一些骨干成員。

對(duì)于我們小組而言， 有一半是之前 AFC的開(kāi)發(fā)人員， 經(jīng)歷過(guò)嚴(yán)格的 codereview 訓(xùn)練； 有一半是廣點(diǎn)通原來(lái)的開(kāi)發(fā)人員，沒(méi)有經(jīng)歷過(guò)嚴(yán)格的 codereview 訓(xùn)練。 為了教育大家的 codereview 意識(shí)，在小組的周會(huì)上我要反復(fù)的強(qiáng)調(diào) codereview 的重要性；同時(shí)我明確的指出每個(gè)人的考評(píng)是和 codereview 的表現(xiàn)相關(guān)的。

對(duì)于廣告業(yè)務(wù)的工程輸出主要包括項(xiàng)目中的設(shè)計(jì)文檔， 代碼實(shí)現(xiàn)， 線上A/B test實(shí)驗(yàn)和實(shí)驗(yàn)結(jié)果跟進(jìn)分析， 以及日常在小組內(nèi)的分享(平常積極的郵件討論，wiki 建設(shè)， 組內(nèi)的 techtalk 分享等)。 所有的一線工程師， 無(wú)論職級(jí)高低，最重要的工程輸出原則還是 show me the code, 而 codereview 是最能夠反應(yīng)這個(gè)客觀輸出的。 在小組內(nèi)部， 我們盡量讓每個(gè)人的 codereview 參與狀況都公開(kāi)透明， 所以我們要求

每個(gè) codereview issue 要明確發(fā)送到你的項(xiàng)目合作者， 項(xiàng)目合作者 review 之后才允許提交

每個(gè) issue 都必須全員轉(zhuǎn)發(fā)到小組內(nèi)所有成員， 小組內(nèi)的任何人只要愿意，都可以去review 其他人的代碼

由于所有的 codereview issue 都會(huì)發(fā)送到小組內(nèi)所有成員， 所以我是能夠在 code.oa.com 上看到所有人的 code 產(chǎn)出情況的。我通過(guò)給大家做 codereview 判斷小組每個(gè)工程師的工程輸出， code.oa.com 上大致是可以看到小組內(nèi)每個(gè)人參與 codereview 的程度的， 包括他發(fā)出的 issue, 他給組內(nèi)成員做的 codereview comments 等等。 code.oa.com 上提供了一個(gè)功能， 可以 dump 出所有人的 codereview issue, 所以考評(píng)的時(shí)候我會(huì)檢查每個(gè)成員在半年之內(nèi)的 codereview 輸出狀況，檢查組內(nèi)成員提交的 issue 的質(zhì)量。

不過(guò) code.oa.com 上查看每個(gè)人的 codereview 參與狀況的功能現(xiàn)在還是太弱， 如果code.oa.com 能提供一個(gè)統(tǒng)計(jì)分析功能, 使得每個(gè)人可以看到自己的一些統(tǒng)計(jì)指標(biāo)， 包括

我修改的文件總數(shù)，修改和提交的代碼總行數(shù)

我給合作者做了多少次 codereview, 提供了多少次 comments

合作者給我做了多少次 comments

如果小組的組長(zhǎng)能夠看到組內(nèi)成員的這些統(tǒng)計(jì)指標(biāo)，無(wú)疑對(duì)于考評(píng)每一個(gè)小組成員的工程輸出會(huì)提供很多客觀公正的信息。

6.CodeReview 感悟

做了4年的 CodeReview, 基本上這個(gè)流程在我們的團(tuán)隊(duì)已經(jīng)深入骨髓，成為了小組工程工作中的種行為習(xí)慣。 如果有一天我離開(kāi)了騰訊， 我相信我在騰訊所經(jīng)歷的相對(duì)嚴(yán)格的 CodeReview 訓(xùn)練會(huì)幫我做好下一個(gè)項(xiàng)目的工程質(zhì)量管理。 為何要做 CodeReview 網(wǎng)絡(luò)上有很多的論證， 之前和 yiwang 合作的時(shí)候， 團(tuán)隊(duì)內(nèi)總結(jié)的幾點(diǎn)如下(主要都是 yiwang 總結(jié)的):

[[131761]]

Code Review保證開(kāi)發(fā)質(zhì)量，整個(gè)過(guò)程有章可循，無(wú)需顧及“面子”，能夠修正很多平時(shí)不注意或者明知故犯的小毛病

Code Review高效溝通交流，不需電話和視頻會(huì)議，讓北京深圳兩地的同事們一起協(xié)同工作

Code Review幫助知識(shí)傳遞，團(tuán)隊(duì)內(nèi)細(xì)粒度的知識(shí)分享， 大家一起逐行的點(diǎn)評(píng)代碼比用技術(shù)交流會(huì)以及KM投稿更細(xì)致

Code Review保證代碼的可持續(xù)使用，代碼風(fēng)格不一致導(dǎo)致一個(gè)系統(tǒng)每次移交負(fù)責(zé)人都被重寫一次

Code Review和敏捷開(kāi)發(fā)相容，而不是相斥，敏捷不是片面追求發(fā)布次數(shù)，而是保證質(zhì)量的發(fā)布

CodeReview 是一種社交的途徑， 鼓勵(lì)小組成員之間多做技術(shù)交流

CodeReview 對(duì)新人的成長(zhǎng)極其有利。 很多新人***次做 codereview 的時(shí)候感覺(jué)都是慘不忍睹， 被拍暈了， 我見(jiàn)過(guò)的最慘的 issue 被要求修改了20多次之后才被允許提交。然而這種方式對(duì)新人的成長(zhǎng)非常高效，一個(gè)coding 能力不錯(cuò)的工程師， 幾個(gè) codereview issue 之后， 很快就能寫出合格的代碼。

CodeReview 增加團(tuán)隊(duì)內(nèi)代碼的可維護(hù)性, 同一份代碼至少會(huì)有兩個(gè)人熟悉——代碼的作者和審閱者。

如何建設(shè)一個(gè)團(tuán)隊(duì)的 code review 文化， 跟隨 Google 的腳步， 也有一些具體的意見(jiàn)：

需要培養(yǎng)合格的reviewer。 建立各種編程語(yǔ)言的readability認(rèn)證機(jī)制，從一組“種子”reviewer開(kāi)始，讓更多同事獲得認(rèn)證成為合格的reviewers

需要細(xì)化和公開(kāi)各種語(yǔ)言的code style。 評(píng)注中可以給出建議的出處的URL，使得保持代碼風(fēng)格和可維護(hù)性落到實(shí)處

需要建立Code Lab機(jī)制。 幫助工程師們?nèi)腴T開(kāi)發(fā)流程和規(guī)范

需要建立change approval機(jī)制。 鼓勵(lì)組內(nèi)更多工程師改進(jìn)代碼（敏捷），但是修改在提交前除了必須通過(guò)review，還需要相關(guān)責(zé)任人的approval；在加速開(kāi)發(fā)滾動(dòng)的同時(shí)，保證權(quán)責(zé)分明

引導(dǎo)輕量 review。我們都經(jīng)歷過(guò)有些工程師發(fā)一個(gè) change issue 的時(shí)候， 幾十個(gè)文件一并發(fā)出來(lái)， 一個(gè) issue 可能是累積一周的修改， reviewer 看到這種 issue 幾乎都是崩潰的，不可能保證 review 質(zhì)量。 所以好的 issue 應(yīng)該是輕量的， 大的 issue 應(yīng)該拆分為小的 issue 發(fā)送。下圖是 Cisco 公司的codereview 報(bào)告中摘出的， 如果一個(gè) issue 的修改代碼行數(shù)超過(guò) 400， 基本上 reviewer 是不可能認(rèn)真 review 幫你找出 bug 的 。

明確issue 能否提交是工程師自己的責(zé)任。開(kāi)發(fā)人員有時(shí)候抱怨別人 review 得慢， 拖延時(shí)間。 我們小組內(nèi)部通常明確指出：一個(gè) issue 能否提交是開(kāi)發(fā)人員自己的責(zé)任。 開(kāi)發(fā)人員自己要積極推動(dòng)合作人員幫忙 review issue， 推動(dòng) issue 被通過(guò)并及時(shí)提交。

7.結(jié)語(yǔ)

學(xué)術(shù)界的所有高質(zhì)量論文都是 peer review 之后才有可能發(fā)表的。 寫過(guò) paper 的碩士博士都有一個(gè)體會(huì)， 接到的各種 review 意見(jiàn)有時(shí)候令你非常的痛苦， 然而無(wú)論是你拒絕了 reviewer 的意見(jiàn)，還是接受意見(jiàn)修改了文章， 你都會(huì)經(jīng)歷一個(gè)認(rèn)真思考的過(guò)程去提升你文章的質(zhì)量。 高質(zhì)量的論文是科研人員嚴(yán)格 review 出來(lái)的， 我相信高質(zhì)量的 code 也可以通過(guò)工程師的 review 產(chǎn)生。 把CodeReview 打造成團(tuán)隊(duì)的習(xí)慣，而我們逐漸會(huì)發(fā)現(xiàn)這種習(xí)慣所釋放出來(lái)的正能量。 希望有一天, 我們也能做到：

At Tencent, no code, for any product, for any project, gets checked in until it gets a positive review。