原創：猿天地（微信公衆號ID：cxytiandi），歡迎分享，轉載請保留出處。
CodeReview我相信目前很多公司都會有這麼一個流程，關鍵是這個流程有沒有用就很難講。主要還是取決於你對CR的理解以及有沒有真正的去落地CR，去重視CR帶來的隱藏價值點。
正好最近也是有人在問我CR相關的問題，他們也要開始做CR了，想了解下有沒有最佳實踐之類的。所以今天跟大家聊聊CR這個話題，我說的也不一定都是對的，僅供參考哈。
其實說實話，我覺得CR不存在什麼最佳實踐。因爲每個公司或者說每個團隊所進行的方式都會不一樣，真正的想要做好CR只能先去做，在研發流程中去落地這個事情，然後慢慢的去提煉出符合你們團隊的CR方式。
1.CR的目的
既然要做CR那肯定就有原因，CR的目的到底是什麼？可以是走個流程，可以是提高代碼能力，也可以是大家都在做，我也要做。我認爲的目的有下面幾個，請往下看。
1.1 穩定生產
大家想想，每個迭代開發完成後會進行測試，測試完成後就要發佈到生產了。那麼最有可能出現的問題就是你的新功能裏面可能改到了老的邏輯，假設測試沒有迴歸出來這個問題。那麼一上線這個就影響到了生產的穩定性，所以CR最重要的目的就是穩定生產。
我們需要對代碼進行CR，看看有沒有改到老代碼，會不會影響老的邏輯，有沒有加開關呀，有沒有兜底動作呀。因爲一個團隊裏面總歸會有新人進來，在不是很熟悉業務的情況下，很有可能就會改錯，很有可能就會留下一個潛藏的Bug，這些都是需要CR去重點關注的。
上線可以，絕對不能影響到老版本，絕對不能出故障，否則你的績效就涼涼了。你說你不想做CR，你的同事們會允許麼，小夥子還是乖乖做CR吧！
1.2 間接培養backup
在管理團隊的時候一定要注意培養backup，因爲你也不知道下一個離開團隊的人會是誰。互聯網公司流動性還是挺大的，因爲只有跳槽才能漲工資呀，我又說出了大家的心裏話。
除了在明面上，可以指定誰作爲某一塊業務的owner，開發的時候由owner帶着其他的人一起進行開發，這個過程中其實就有了backup，因爲這一塊業務知道的不在是某一個人了。
在臺面下也要注意培養backup，此時CR就是一個很好的機會。CR的時候就可以讓更多的人熟悉這些業務，但是方式一定要注意，不要光禿禿的只看代碼，這樣沒參與開發的肯定是一個很懵的狀態。可以在CR前讓大家先大概的看下PRD，然後讓CR的人講解的時候不是一行行代碼去Review, 先要講自己這個迭代做的什麼需求，有哪些功能，對應的代碼就是現在CR的代碼。這樣才能讓大家即瞭解業務又做了CR，一箭雙鵰。
當然，此時你會說，就算按照你說的方式進行CR，也不一定其他人就很熟悉了呀！這個是當然的，最熟悉的還是寫代碼的那個人嘛！但是我們讓其他人有了一個大概的印象，假如後面寫代碼的那個人離職了，當有Bug要修的時候，其他人也是有映象當時這個功能的代碼在哪裏，我還記得CR過，我還提了一些建議。總比啥都不知道要強吧，你說對麼？
1.3 提高代碼質量
單純從技術層面出發，CR的目的就是讓大家來找茬，挑刺的。每個人的經驗都不同，每個人的思路也不一樣，往往你覺得這樣寫是最簡單的方式，別人可能有更簡單的方式去實現。
在CR的過程中，大家會提出自己的看法，實現的思路，代碼是否寫的夠簡潔，是否有開源框架能夠直接實現某個功能，是否能否用設計模式進行優化，提高擴展性。領域建模是否合理，模塊劃分是否到位等等一系列的問題。
對於新人來說，能夠得到很多有經驗的同事在CR時給出的建議，對他的成長是很有幫助的。而且也會讓你們的項目代碼的質量一直維持在一個高的水平。這就是我們要做CR的目的，當然現實往往可能很殘酷，很多項目到最後都會比較亂，代碼也很臃腫，我想可能是當時被業務方倒排期，趕着要上線導致的吧！這種情況很常見，特別在創業型公司。
2.CR的方式
前面講了幾點我認爲CR的目的，那麼如何進行CR呢？常見的方式有哪些，來，接着往下看。
2.1 Gitlab
使用Gitlab做CR之前一般都是先提一個MR請求，然後針對這個請求做CR。這個MR請求裏面所有的變動就是我們需要CR的點，如果有什麼需要修改的可以在對應的代碼處增加備註，CR結束之後各自根據當時的備註去修改。
2.2 開發工具
在我們的開發工具中直接進行CR也是非常的方便，好處在於可以看到整個功能的所有代碼，就是你可以跟着業務的流程去講解對應的代碼。然後也可以很清楚的對比出哪些是你自己的改動，哪些是老的代碼。
3.CR的時機
3.1 提測之前
在提測之前是最好的CR時機，這個時候我們有需要改進的再CR之後就直接改掉了。然後提測的時候就已經是我們改過之後的代碼了，也許就減少了很多Bug，測起來也如絲般順滑。
提測之前就CR影響的是什麼？是我們的開發時間，本來開發完成之後就馬上提測的，但是要在提測前進行CR，除非你的開發進度提前，否則還沒開發完怎麼做CR?
這個其實就是我們上面講的流程了，將CR融入到研發流程中去，這樣就可以在評估時間的時候給CR留出一天的buffer，比如11號要提測，那麼10號就CR, 9號就是開發完成。
3.2 提測之後
提測之後做CR其實很不好，我們之前也有這樣做過，做完之後立馬改成了提測之前。因爲在做的過程中會提出一些需要修改的點，然後這些點有可能測試已經測完了。然後你又改了，導致產生了新的Bug，增加了測試的工作量。
甚至還有一次是CR時候當場改的，然後沒注意直接提交了，也沒跟測試同步。第二天發生產環境直接出Bug了，所以一定不要在提測之後臨近上線之前進行CR。
再舉一個列子，之前有個團隊老是喜歡在上線當天進行CR，測試已經再整體迴歸了，他們還在CR。當然有沒有改動代碼我不太清楚，因爲不是一個團隊，但是最嚴重的是迴歸的時候是有Bug的，需要及時修復。然後找不到人修，他們去CR了，也沒人關注。導致的結果就是每次上線都要搞到好晚。
3.3 上線之後
上線之後就更不要CR了，你上線之後CR有什麼意義呢？代碼都發布了，這個時候CR出來的問題改還是不改呢？下個迭代改嗎？下個迭代改完是不是又要回歸一次，測試願意麼？
正所謂今日事今日畢，當前迭代的事情就在當前迭代解決，否則就是堆積如山了。
總結
對於CR我們還是要積極的擁抱，去落地，去實踐。看上去會花費一部分時間，但帶來的收益還是很不錯的。項目的代碼質量提高了，團隊的技術氛圍變好了，線上Bug明顯變少了，大家對業務更熟悉了。
如果你們沒有CR，請把這篇文章刷給你老闆，就是這麼任性。
如果對你有用，來個轉發唄！
關於作者：尹吉歡，簡單的技術愛好者，《Spring Cloud微服務-全棧技術與案例解析》, 《Spring Cloud微服務 入門 實戰與進階》作者, 公衆號猿天地發起人。