Code Review體系與團隊文化

Code Review不只是一種管理方法，也是開發者特有的溝通方式，更是一種團隊文化。Code Review機制是否健全是評價一個研發團隊技術氛圍好壞的重要參考。

Code Review的意義

• 交叉排查缺陷 - 絕大多數BUG都可以在代碼層面被發現，甚至測試難以覆蓋到的深層次BUG也可以通過團隊成員相互審覈而避免
• 提高代碼質量 - Code Review意味着開發者要接受團隊成員的建議與監督，在完成功能的基礎之上不斷完善代碼結構
• 建立團隊意識 - 代碼是團隊財產，團隊成員在相互督促與改進中共同成長

Code Review的體系

• Daily Code Review - 開發者完成初步結構設計，或者完成一個相對完整的小模塊都可以提交PR讓團隊成員Review
  
• 需求Code Review - 評估需求完成度，與其它需求的潛在衝突
  
• 上線Code Review - 上線前Review，重點排查配置問題，安全問題，代碼衝突
  
• 重點代碼走讀 - 每個迭代/雙週/月度對具有代表性的代碼集體走讀，重點在於解決團隊共性問題，討論改進方法

是整個Code Review體系中最重要的是Daily Code Review，絕大多數問題應該在每天的Code Review中溝通解決，也就是功夫在平時。

Code Review有幾個重要的參考指標：

• 單次提交Review的代碼量 - 在思路相對完整的情況下越少越好
  
• 評論的數量，參與程度 - 每個PR至少2人Review通過之後才能合併代碼，但參與人數也不宜過多，避免盲目通過的情況
  
• 更新的次數 - 通常情況下Code Review不應該直接通過，平均要Update至少一次

Code Review的文化

通過多層次的Code Review體系，在團隊中建立起集體認知：

• 代碼是團隊共有的知識財富，而不是個人的私有地
• 所有人對所有代碼的最終質量負責，而非某個人對某些代碼負責
• 完成功能只是開始，代碼需要持續改進以符合團隊標準

Code Review對於團隊中的新人來說是很好的鍛鍊機會，我們團隊的新人首次提交代碼，被打回更新四五次是很正常的事情。集體對代碼質量的追求，也能提升新人的成就感、榮譽感。

實踐中注意強調以下問題：

• Code Review不能形式化，沒看過PR、沒改進意見不能通過
  
• 被Decline PR不是丟面子的事情，被提改進建議也不是批評，對事不對人
• 將別人提交的代碼視作自己將維護的代碼，個人標準與集體標準對齊

總結

Code Review體現的是團隊對於代碼質量的追求，對於團隊內部協作的重視。對於新人來講，對於日常工作的鑽研與打磨比偶爾一次的技術培訓或分享更有學習價值。