來源：r6d.cn/NzDTjava
衆所周知，Code Review是開發過程當中一個很是重要的環節，可是不少公司或者團隊是沒有這一環節的，今天筆者結合本身所在團隊，淺談Code Review的價值及如何實施。web
1. Code Review的價值
許多團隊沒有Code Review環節，或者由於追求項目快速上線，認爲CR浪費時間；或者團隊成員缺乏CR觀念，認爲CR的價值並不大。因此想要推進CR在團隊中的實施，最最重要的一點即是加強團隊成員對CR環節的認同感。api
Code Review環節，它更加依賴於團隊成員的主觀能動性，只有團隊成員對其承認，他們纔會積極地參入這一環節，CR的價值才能最大化的體現。若是團隊成員不承認CR，即便強制設置了CR流程，也是形同虛設，反而可能阻礙正常開發流程的效率。那麼如何讓團隊成員承認CR環節呢，天然是讓他們意識到CR的價值，而後就會……真香！
微信
1.1 提高團隊代碼質量
隨着團隊規模的擴大和項目的迭代升級，團隊之間的信息透明度會愈來愈低，項目的可維護性也會愈來愈差，可能引起以下一系列問題：app
已有的utils方法，重複造輪子編輯器
代碼過於複雜，缺乏必要註釋，後人難以維護學習
目錄結構五花八門，雜亂不堪測試
……
合理的CR環節，能夠有效地把控每次提交的代碼質量，不至於讓項目的可維護性隨着版本迭代和時間推移變得太差，這也是CR的首要目的。CR環節並不會下降開發效率，就一次代碼提交來講，也許部分人認爲CR可能花費了時間，可是有效的CR給後人擴展和維護時所節省的時間是遠超於此的。優化
1.2 團隊技術交流
Reviewer和Reviewee，在參與CR的過程當中，都是能夠收穫到許多知識，進行技術交流的。ui
有利於幫助新人快速成長，團隊有新人加入時（如實習生和校招生），每每須要覺得導師帶領一段時間，經過CR環節，可使導師最直接的瞭解到新人開發過程當中所遇到的問題，做出相應的指導。
經過CR環節，團隊成員能夠了解他人的業務，而不侷限於本身的所負責的業務範圍。項目發現問題時，能夠迅速定位到相關業務的負責人進行修改。同時如有的團隊成員離職後，也能夠減小業務一人負責所帶來的後期維護困難。
學習他人的優秀代碼。經過CR環節，能夠迅速接觸到團隊成員在項目中解決某些問題的優秀代碼，或者使用的一些你所未接觸過的一些api等。
1.3 保證項目的統一規範
既然要進行CR，首先要對項目的規範制定要求，包括編碼風格規範、目錄結構規範、業務規範等等。一方面，統一的項目規範才能保證項目的代碼質量，提升項目的質量和可維護性；另外一方面，在你們熟悉了統一的規範後，可以提高CR的效率，節省時間。
2. Code Review的實踐
關於Code Review的實踐，要考慮的包括CR所花費的時間、CR的形式、什麼時候進行CR等等。
2.1 預留CR的時間
首先不得不認可，CR環節是要耗費必定時間的，因此在項目排期中，不只要考慮開發、聯調、提測、改bug等時間，還要預留出CR的時間。包括擔任Reviewer和Reviewee角色的時間都要考慮。
另外若是遇到的需求比較複雜，爲了不由於CR過程致使代碼須要大量修改，最好提早和團隊成員溝通好需求的設計和結果思路。
2.2 CR的形式
我所見過的CR大多有兩種形式。一種是設立一個特定時間，例如每週或者每半月等等，團隊成員一塊兒對以前的Merge Request進行CR；另外一種是對每次的Merge Request都進行CR。
我我的更偏向於後者。第一種按期CR，Merge Request的數量太多，不太可能對全部的MR進行CR，若是CR以後再對以前的諸多MR進行修改爲本太大；並且一次性太多的CR會打擊團隊成員的積極性。第二種MR相對就輕鬆的多，能夠考慮輪班天天設置2-3人對當天的MR進行CR便可。
2.3 CR的時機
CR的環節應該設立在提測環節以前。由於CR後若是優化代碼雖然理論上只是代碼優化，但極可能會對業務邏輯產生影響，若是在提測時候，那麼可能會影響到已經測試過的功能點。
固然也要分狀況，若是遇到比較緊急的需求或者bug修復，那麼也能夠先提測，後續再作相應的CR。
3. 對團隊成員要求
前面已經提到，要加強團隊成員對CR環節的認同感。做爲CR環節的參與者，還應該根據本身的團隊特色，對團隊成員作出相應要求，能夠參考咱們團隊。
3.1 Reviewer
指明review的級別。reviewer再給相應的代碼添加評論時，建議指明評論的級別，能夠在評論前用[]做出標識，例如：
[request]xxxxxxx 此條評論的代碼必須修改才能予以經過
[advise]xxxxxxxx 此條評論的代碼建議修改，但不修改也能夠經過
[question]xxxxxx 此條評論的代碼有疑問，需reviewee進一步解釋
講明該評論的緣由。在對代碼作出評論時，應當解釋清楚緣由，若是本身有現成的更好地解決思路，應該把相應的解決思路也評論上，節省reviewee的修改時間。
平等友善的評論。評論者在review的過程當中，目的是提高項目代碼質量，而不是抨擊別人，質疑別人的能力，應該保持平等友善的語氣。
享受Code Review。只有積極的參與CR，把CR做爲一種享受，才能將CR的價值最大化的體現。
3.2 Reviewee
注重註釋。對於複雜代碼寫明相應註釋，在進行commit時也應簡明的寫清楚背景，幫助reviewer理解，提升review的效率。
保持樂觀的心態接受別人的review。團隊成員的review不是對你的批判，而是幫助你的提高，因此要尊重別人的review，若是review你感受不正確，能夠在下面提出疑問，進一步解釋。
完成相應review的修改應當在下面及時進行回覆，保持信息同步。
本文分享自微信公衆號 - 肥朝（feichao_java）。
若有侵權，請聯繫 support@oschina.cn 刪除。
本文參與「OSC源創計劃」，歡迎正在閱讀的你也加入，一塊兒分享。