CodeReview是什么呢？字面意思，就是對你的代碼進行評審，talkis cheap，showme the code就是這意思。越來越多的企業(yè)都要求研發(fā)團隊在代碼的開發(fā)過程中要進行CodeReview（簡稱CR），在保障代碼質(zhì)量的同時，促進團隊成員之間的交流，提交代碼水平。

不過CR文化的推崇卻是近些年才開始的，國外像Amazon、Google的大廠要求代碼合并進主干分支時必須要做CR，國內(nèi)互聯(lián)網(wǎng)起步比國外晚，再加上略微復雜的中國特色（不太好意思當面評論別人的代碼寫的不好….），早期的CR更多流于形式，現(xiàn)在隨著互聯(lián)網(wǎng)流量的劇增，必須要保障代碼質(zhì)量才能保障業(yè)務高穩(wěn)定高可用，所以CR開始成為企業(yè)開發(fā)中必須要做的事情。

簡單來說，CR就像吃早餐一樣，不吃好像不見得對身體會有什么不好，所以大家因為工作忙或睡懶覺等原因，忽略了早餐，或者隨便吃吃應付。

但隨著身體在高負荷、高壓力的情況下逐漸有些異樣，大家開始意識到了“身體是革命的本錢”，早餐必須要吃，必須堅持吃，這樣對身體是最有益的，身體好才有力氣走的更遠、做的更好。不過早餐為什么吃，什么時候吃，怎么吃，吃什么也是有考究的。就像CR什么時候做，怎么做，該注意什么也是有考究的。

Why？--為什么需要評審？

CR是代碼規(guī)范性的保障、帶來知識傳播、團隊建設。有的人可能覺得代碼評審就是找出錯誤的，覺得代碼評審沒有必要，實際上并不是這樣。

從編碼者的角度來說，每天都忙于緊張的coding，交付時間馬上到了，為了快速交付于是降低了要求，不寫單元測試用例，coding的時候也沒有從性能、安全角度去考慮更好的實現(xiàn)，雖然按期提交了代碼，然而卻不是一份高質(zhì)量的代碼，在運行中可能出問題、后來人接手也不好接。

如果有CR的存在，想到你的代碼即將被你的同事、領導進行評審，你還會降低要求嗎？肯定加班加點保質(zhì)保量的完成代碼編寫呀。

另外在CR的過程中有資深的前輩對你的代碼設計思路、算法進行講解，這肯定比自己低頭琢磨進步快啊。

CR評審的理由就像和家人朋友一起吃早餐一樣，一個人的時候起晚了或者著急就不吃了，而如果你家人或朋友與你一起居住時，一想到家人的健康、家人對你的擔憂，你還會不早點起床吃早餐、甚至做早餐嗎？

When？—什么時候評審？

每一次的代碼合并（PullRequest/Merge Request）就是最好的時機。PullRequest就是說你沒有權(quán)限往一個特定的倉庫或分支提交你寫的代碼，通過請求有權(quán)限的人將你提交的代碼從你的源倉庫的源分支合并進目標倉庫的目標分支。

每個需求的改動都應當盡快提合并請求合并到主分支，這樣可以盡早的發(fā)現(xiàn)代碼編寫中的問題。我們現(xiàn)在所倡導的持續(xù)集成也是這個思想，不要等到所有的需求都開發(fā)完在進行合并，一次提交大量的代碼給評審的人也帶來很大負擔，修改一次提交一次。當然這個提交也是要有質(zhì)量的提交，至少在提交之前自己已經(jīng)全面review、通過了單元測試。

CR評審的時間就像做早餐一樣，必須自己都嘗試生熟合適、甜咸得當再叫別的人一起來吃。

How？—怎么評審？

選擇合適的工具、配合合適的開發(fā)流程、選取適當?shù)男问竭@三者非常重要。

對于工具來說，目前很多代碼托管工具如Github、Gitlab、阿里云云效、騰訊工蜂等都自帶了CR工具，開發(fā)團隊可根據(jù)自己情況選擇。

對于開發(fā)流程，目前流行的GitFlow、主干開發(fā)模式、fork開發(fā)模式都支持在將代碼合并到master分支時需要發(fā)起PullRequest/MergeRequest。對于適當?shù)男问剑€上評審、線下評審、特殊處理三種，對于輕量級的CR（比如小功能模塊的開發(fā)、不超過500行的代碼）可直接在代碼托管工具中邀請同組的人或資深的人對代碼進行評審，結(jié)合反饋意見進行修改；對于大功能模塊的開發(fā)或是涉及架構(gòu)變動，可組織團隊人員線下進行評審，開發(fā)者講自己的設計邏輯，評審人給出意見，一行一行的進行代碼評審；對于某些緊急情況，比如線上有緊急bug需緊急上線但又沒有人在，這時候可以進行緊急合并，但事后仍然需要補上CR。

CR的評審方法就像吃早餐一樣，如果是一個人可以簡單一些，牛奶面包補充必要的蛋白質(zhì)即可；如果是當一家人在一起時，必然會豐盛一些，包子、粥、豆?jié){、油條、咸菜都會來一點，五谷雜糧都進行補充；如果是緊急趕火車或趕飛機來不及吃時，可以先不吃，等上了火車或飛機再補上。

What？—評審什么？

CR評審什么呢？在CR中我們對代碼的規(guī)范性、一致性、編碼風格、代碼的安全問題、代碼冗余、代碼的功能性能設計等進行評審。

對于規(guī)范性，在java中我們會去check后臺線程是否有同步訪問主線程、函數(shù)及變量命名是否準確、組件分層是否合理，公共邏輯是否合理抽出，文件組織是否合理、函數(shù)注釋是否清晰全面、代碼的可讀性是否良好，是否有更優(yōu)雅的寫法、程序設計是否滿足單一原則，開放封閉原則。

對于完整性，我們check代碼是否完全實現(xiàn)了設計文檔中提出的功能需求、是否創(chuàng)建了需要的數(shù)據(jù)庫、是否包含正確的初始化數(shù)據(jù)。

對于正確性，我們check是否所有的變量都被正確定義和使用，是否有未定義的變量被使用、是否有明顯的或潛在的邏輯bug、是否無意中陷入了死循環(huán)、是否避免了無窮遞歸。

對于健壯性，我們check代碼是否做了異常處理，是否存在數(shù)組塌陷、內(nèi)存溢出。

對于可重用性，我們check組件是否可復用、代碼是否存在重復。

對于可擴展性，我們check功能組件是否便于擴展、代碼是否可以下沉復用。

對于安全性，我們check是否進行身份驗證，授權(quán)，輸入數(shù)據(jù)驗證，避免諸如SQL注入和跨站腳本（XSS）等安全威脅，加密敏感數(shù)據(jù)（密碼，信用卡信息等）、引入的依賴項是否安全，成熟、公共組件&工具函數(shù)的改動，是否會影響其他業(yè)務。可見CR并不是一件簡單的事情，一份好的代碼、好的工程師也必定是受過千錘百煉。

CR的評審內(nèi)容就像早餐一樣，我們會注意食材營養(yǎng)搭配是否均衡、烹飪是否得當、量是否足夠、食材是否安全、是否清洗干凈、就餐環(huán)境是否干凈衛(wèi)生、價格是否合適等等。

不要說業(yè)務迭代太多、需求太多、上線時間緊張沒有時間做CR，不要為自己丑陋的代碼找華麗的借口，沒有時間好好做CR，那將有大量的時間用于焦頭爛額的處理故障和投訴。

就像不要說自己沒時間吃早餐、工作太忙、太困一樣，現(xiàn)在省的時間將來有的是各種病讓你渾身不舒服。

所以如果你在的團隊還沒有做CR、CR踐行的不好，一定要push你的leader找到根本的原因，將CR踐行下去，為了一份有質(zhì)量的代碼，一切都是值得的。

就像如果你現(xiàn)在還沒有好好的吃早餐，從現(xiàn)在開始好好的吃早餐，為了一個健康的身體，一切都是值得的。