Code Review是提高開發團隊技能以及保持團隊疊代更新最佳的實踐方法，也是代碼品質管理中一個非常有效的方法。
什麼？你不知道什麼是Code Review？
Code Review中文譯作“代碼審查”或是“代碼評審”，這是一個流程，當開發人員寫好代碼後，需要讓别人來review一下他的代碼，我們可以審查代碼的風格、邏輯、思路……，找出問題，以及改進代碼。因為這是代碼剛剛出爐的時候，是以，這也是代碼重構，代碼調整，代碼修改的最佳時候。是以，Code Review是編碼實作中最最重要的一個環節。
我們真的需要做CodeReview嗎？
Code Review原本是整個流程中不可或缺，且較為耗時的一個品質保證環節，雖省略之後給業務方造成機關時間生産效率更高的假象，但低品質的代碼，會把團隊帶入漩渦，滾雪球一樣的技術債，會讓團隊付出巨額利息。
1、保證項目品質、提高代碼可讀性
- code review可以通過reviewers的建議增進代碼的品質，也能提高owner的程式設計态度
- code review有利項目流轉，可以讓其它并不熟悉代碼的人知道作者的意圖和想法，進而在以後輕松維護代碼
- code review鼓勵程式員們互相學習對方的長處和優點，同時可以達到知識傳播
- code review可以用來确認自己的設計和實作是清楚和合理的
- code review幫助找到程式的bug和保證代碼風格和編碼标準
2、加速個人成長、突出團隊價值
個人的技能成長不再隻依靠自己或技術主管的建議，整個團隊對單人的成長都能起到幫助，成員可以獲得别處無法達成的發展
進而進一步促進整個團隊生産力的提升，最終項目進度和品質都能得到很好的保障
那為什麼有些人偏偏不願意進行CodeReview呢？
- 時間不夠問題：業務倒逼工期，時間太緊，連coding都勉強，以上線為目的。解決方法：其實這不是CodeReview的問題，這是需求管理與項目管理的問題
- 需求變化問題：需求變得快，代碼的生命周期太短，是以都寫一次性爛代碼。解決方法：臨時代碼不是單獨存在的，會影響長期在用的代碼，會影響長期穩定的技術團隊。
- 人員态度問題：不想精益求精，幹活交差為主。解決方法：那麼更需要Review來保障品質和促進上進了。
好吧，既然這麼好，那是不是任何團隊都合适實施呢？
當然不是，你團隊中的項目得滿足以下前提條件：
- 統一的标準：沒有評審标準的評審是混亂的
- 隻實施于高價值子產品：關注在核心系統代碼、重用的元件等對品質有高要求的子產品，而快速搶占市場的疊代型項目可在傳遞後再補Review
- Reviewer獎勵機制：reviewer的評審會占用工作量，是項目品質的保證者，貢獻者，應建立适當鼓勵機制與每月績效關聯
- 代碼充分注釋：要求核心代碼，加上充分的業務注釋、邏輯注釋，以便reviewer更易了解代碼思路
- 先跑CodeStyle檢查工具：不應該把人工CodeReview的精力放在指出代碼樣式和規範上，是以代碼請先用插件跑一遍CodeStyle自行檢查與修改
好了，我一切準備就緒了，具體怎麼實施呢？
我建議有2種做法：
- 方法一：代碼評審會議，我稱之為Code Review Meeting，就是将團隊成員都組織起來開會，讓代碼Owner上去講自己代碼的實作和思路，其它人發表意見和進行讨論。
- 方法二：一對一評審，我稱之為Single Review，就是項目owner送出代碼之後，讓reviewer在空閑的時候幫忙評審代碼，并且寫出批注，owner收到批注後，進行修改或者回複。但注意這裡的reviewer并不是隻有技術主管或架構師之類的才能做，代碼品質監管僅僅靠架構師是不夠的，需要所有經驗豐富或有專長的同學參與其中。
那Single Review與Review Meeting根本上哪些不同呢？
一、Review Meeting
- 優點：
- 團隊内新技術/新觀點的交流Meeting、項目開發思路、解決方案讨論，偏頭腦風暴式；
- 各類項目都适合進行；
- 缺點：
- 依賴于主持者（項目Owner）的素質、時間成本高（為會議上所有人時間的總和）；
- 集體評審的代碼行數有限；
二、Single Review
- 優點：
- 更偏重與具體的代碼評審，人員分散參與，評審代碼行數有保證；
- 時間自由，Reviewer什麼時候進行評審時間可自控；
- 缺點：
- 流程稍複雜，隻适用于重要項目或核心子產品；
以前我們團隊每周隻進行 Review Meeting，從會議産出和面談回報來看，确實有一些的作用。但也不可否認的是，其中是有些弊端的，例如Meeting時評審的代碼量很有限，且一些細節問題不容易暴露等等，但這卻又是項目品質管理的重點。
那怎麼辦呢，後來也引入了Single Review，采用Review Meeting與Single Review相結合的模式。
即每次代碼送出後，針對代碼的變更進行Single Review，然後每周進行一次Review Meeting。
Single Review的主要流程
（我這裡推薦使用facebook開源的phabricator工具，後面附圖）：
- 開發者user1在使用SVN送出核心代碼時，在comment中添加Reviewer（向Reviewer提起代碼稽核請求，例如：Auditors: user2, user3，all）
- 開發者user2、user3……收到系統發來評審請求郵件，登陸web進行評審，并可在不同的代碼行處标注出修改建議和疑慮，最後送出評審
- 開發者user1收到評審意見郵件，進行處理代碼修改，重新送出評審，直到user2、user3……批注評審通過，代碼才可傳遞測試
參考圖：
更多文章，請關注我的微信訂閱号：