不容錯過， Code Review 的最佳實踐方案來了

前言

我一直認爲Code Review（代碼審查）是軟件開發中的最佳實踐之一，能夠有效提升總體代碼質量，及時發現代碼中可能存在的問題。包括像Google、微軟這些公司，Code Review都是基本要求，代碼合併以前必需要有人審查經過才行。

然而對於我觀察到的大部分軟件開發團隊來講，認真作Code Review的不多，有的流於形式，有的可能根本就沒有Code Review的環節，代碼質量只依賴於過後的測試。也有些團隊想作好代碼審查，但不知道怎麼作比較好。網上關於如何作Code Review的文章已經有不少了，這裏我結合本身的一些經驗，也總結整理了一下Code Review的最佳實踐，但願能對你們作好Code Review有所幫助。

Code Review有什麼好處？

不少團隊或我的不作Code Review，根源仍是不以爲這是一件有意義的事情，不以爲有什麼好處。這個問題要從幾個角度來看。

首先是團隊知識共享的角度

一個開發團隊中，水平有高有低，每一個人側重的領域也有不一樣。怎麼讓高水平的幫助新人成長？怎麼讓你們都對本身側重領域以外的知識保持瞭解？怎麼能有人離職後其餘人能快速接手？這些都是團隊管理者關心的問題。而代碼審查，就是一個很好的知識共享的方式。經過代碼審查，高手能夠直接指出新手代碼中的問題，新手能夠立刻從高手的反饋中學習到好的實踐，獲得更快的成長；經過代碼審查，前端也能夠去學習後端的代碼，作功能模塊A的能夠去了解功能模塊B的。可能有些高手以爲給新手代碼審查浪費時間，本身也沒收穫。其實否則，新人成長了，就能夠更多的幫高手分擔繁重的任務；代碼審查中花時間，就少一些幫新人填坑擦屁股的時間；良好的溝通能力、發現問題的能力、幫助其餘人成長，都是技術轉管理或技術上更上一層樓必不可少的能力，而經過代碼審查能夠有效的去練習這些方面的能力。

而後是代碼質量的角度

現實中的項目老是人手缺進度緊，因此被壓縮的每每就是自動化測試和代碼審查，結果影響代碼質量，欠下技術債務，最後仍是要加倍償還。也有人寄但願於開發後的人工測試，然而對於代碼質量來講，不少問題經過測試是測試不出來的，只能經過代碼審查。好比說代碼的可讀性可維護性，好比代碼的結構，好比一些特定條件才觸發的死循環、邏輯算法錯誤，還有一些安全上的漏洞也更容易經過代碼審查發現和預防。也有人以爲本身水平高就不須要代碼審查了。對於高手來講，讓別人審查本身的代碼，可讓其餘人學習到好的實踐；在讓其餘人審查的同時，在給別人說明本身代碼的時候，也等於本身對本身的代碼進行了一次審查。這其實就跟咱們上學時作數學題同樣，真正能拿高分的每每是那些作完後還會認真檢查的。

還有團隊規範的角度

每一個團隊都有本身的代碼規範，有本身的基於架構設計的開發規範，然而時間一長，就會發現代碼中出現不少不遵照代碼規範的狀況，有不少繞過架構設計的代碼。好比難以理解和不規範的命名，好比三層架構裏面UI層繞過業務邏輯層直接調用數據訪問層代碼。

若是這些違反規範的代碼被糾正的晚了，後面再要修改就成本很高了，並且團隊的規範也會慢慢的形同虛設。經過代碼審查，就能夠及時的去發現和糾正這些問題，保證團隊規範的執行。關於代碼審查的好處，還有不少，也不一一列舉。仍是但願能認識到Code Review和寫自動化測試同樣，都是屬於磨刀不誤砍柴工的工做，在上面投入一點點時間，將來會收穫代碼質量，會節約總體的開發時間。

該怎麼作？

如今不少人都已經有意識到Code Review的重要性了，只是苦於不知道如何去實踐，不知道怎麼樣算是好的Code Review實踐。

把Code Review做爲開發流程的必選項而不是可選項

在很早之前，我就嘗試過將代碼審查做爲代碼流程的一部分，但只是一個可選項，沒有Code Review也能夠把代碼合併到master。這樣的結果就是想起來纔會去作Code Review，去檢查的時候已經有了太多的代碼變動，審查起來很是困難，另外就算審查出問題，也很可貴以修改。

咱們如今對代碼的審查則是做爲開發流程的一個必選項，每次開發新功能或者修復Bug，開一個新的分支，分支要合併到master有兩個必要條件：

•全部的自動化測試經過•有至少一我的Code Review經過，若是是新手的PR，還必須有資深程序員Code Review經過

圖片來源：How to Do Code Reviews Like a Human

這樣把Code Review做爲開發流程的一個必選項後，就很好的保證了代碼在合併以前有過Code Review。並且這樣合併前要求代碼審查的流程，好處也很明顯：

•因爲每一次合併前都要作代碼審查，這樣通常一次審查的代碼量也不會太大，對於審查者來講壓力也不會太大•若是在Code Review時發現問題，被審查者但願代碼能儘快合併，也會積極的對審查出來的問題進行修改，不至於對審查結果太過抵觸

若是你以爲Code Review難以推行，不妨先嚐試着把Code Review變成你開發流程的一個必選項。

把Code Review變成一種開發文化而不只僅是一種制度

把Code Review 做爲開發流程的必選項後，不表明Code Review這件事就能夠執行的很好，由於Code Review 的執行，很大部分程度上依賴於審查者的認真審查，以及被審查者的積極配合，二者缺一不可！若是僅僅只是看成一個流程制度，那麼就可能會流於形式。最終結果就是看起來有Code Review，但沒有人認真審查，隨便看下就經過了，或者發現問題也不肯意修改。真要把Code Review這件事作好，必須讓Code Review變成團隊的一種文化，開發人員從心底接受這件事，並認真執行這件事。要造成這樣的文化，不那麼容易，也沒有想象的那麼難，好比這些方面能夠參考：

•首先，得讓開發人員認識到Code Review這件事爲本身、爲團隊帶來的好處•而後，得要有幾我的作好表率做用，榜樣的力量很重要•還有，對於管理者來講，你激勵什麼，每每就會獲得什麼•最後，像寫自動化測試同樣，把Code Review要做爲開發任務的一部分，給審查者和被審查者都留出專門的時間去作這件事，不能光想着馬兒跑得快又捨不得給馬兒吃草

如何造成這樣的文化，有心的話，還有不少方法能夠嘗試。只有真正讓你們都認同和踐行，纔可能去作好Code Review這件事。

一些Code Review的經驗技巧

在作好Code Review這件事上，還有一些經驗技巧能夠參考。

選什麼工具輔助作CODE REVIEW？

如今不少源代碼管理工具都自帶Code Review工具，典型的像Github、Gitlab、微軟的Azure DevOps，尤爲是像Gitlab，還能夠本身在本地搭建環境，根據本身的須要靈活配置。

配合什麼樣的開發流程比較好？

像Github Flow這樣基於分支開發的流程是特別適合搭配Code Review的。其實無論什麼樣的開發流程，關鍵點在於代碼合併到master（主幹）以前，要先作Code Review。

真遇到緊急狀況，來不及代碼審查怎麼辦？

雖然原則上，必需要Code Review才能合併，但有時候確實會存在一些緊急狀況，好比說線上故障補丁，而又沒有其餘人在線，那麼這種狀況下，最好是在任務管理系統中，建立一個Ticket，用來後續跟蹤，確保後續補上Code Review，並對Code Review結果有後續的代碼更新。

先設計再編碼

有些新人發現本身的代碼提交PR（Pull Request）後，會收到一堆的Code Review意見，必需要作大量的改動。這多半是由於在開始作以前，沒有作好設計，作出來後才發現問題不少。建議在作一個新功能以前，寫一個簡單的設計文檔，表達清楚本身的設計思路，找資深的先幫你作一下設計的審查，發現設計上的問題。設計上沒問題了，再着手開發，那麼到Review的時候，相對問題就會少不少。

代碼在提交CODE REVIEW以前，做者要本身先REVIEW和測試一遍

我在作代碼審查的時候，有時候會發現一些很是明顯的問題，有些甚至本身都沒有測試過，就等着別人Code Review和測試幫助發現問題。這種依賴心理不管是對本身仍是對團隊都是很不負責任的。一個好的開發人員，代碼在提交Code Review以前，確定是要本身先Review一遍，把該寫的自動化測試代碼寫上，本身把基本的測試用例跑一遍的。我對於團隊提交的PR，有個要求就是要在PR的描述中增長截圖或者錄屏，就是爲了經過截圖或者錄屏，確保提交PR的人本身是先測試過的。這也是一個有效的輔助手段。

PR要小

在作Code Review的時候，若是有大量的文件修改，那麼Review起來是很困難的，但若是PR比較小，相對就比較容易Review，也容易發現代碼中可能存在的問題。因此在提交PR時，PR要小，若是是比較大的改動，那麼最好分批提交，以減輕審查者的壓力。

對評論進行分級

在作Code Review時，須要針對審查出有問題的代碼行添加評論，若是隻是評論，有時候對於被審查者比較難甄別評論所表明的含義，是否是必需要修改。建議能夠對Review的評論進行分級，不一樣級別的結果能夠打上不一樣的Tag，好比說：

•[blocker]: 在評論前面加上一個[blocker]標記，表示這個代碼行的問題必需要修改•[optional]：在評論前面加上一個[optional]標記，表示這個代碼行的問題可改可不改•[question]：在評論前面加上一個[question]標記，表示對這個代碼行不理解，有問題須要問，被審查者須要針對問題進行回覆澄清

相似這樣的分級能夠幫助被審查者直觀瞭解Review結果，提升Review效率。評論要友好，避免負面詞彙；有說不清楚的問題當面溝通 雖然評論是主要的Code Review溝通方式，但也不要過於依賴，有時候面對面的溝通效率更高，也容易消除誤解。另外文明用語，不要用一些負面的詞彙。

總結

Code Review是一種很是好的開發實踐，若是你還沒開始，不妨逐步實踐起來；若是已經作了效果很差，不妨對照一下，看有沒有把Code Review做爲開發流程的必選項而不是可選項？有沒有把Code Review變成一種開發文化而不只僅是一種制度？

2019秋招必備面試題彙總+阿里P6P7安卓進階資料分享