關於Code Review的一些思考總結

Code Review

• 提升代碼質量
• 提早發現bug
• 統一代碼規範
• 提升團隊成員代碼技能

總之，前期找問題（代碼規範、潛在缺陷、BUG，代碼設計等等），後期演變成開發者技術交流和員工成長

如何開展

• 代碼規範：明確Coding規則
• 檢視清單：結合業務特色，check重點
• 總結優化：透明問題，持續優化
• 激勵措施：激發主觀能動性

開展方式

• 強制&非強制
• 線上交流（小組review）&線下會議（團隊review）
• 小片斷&大模塊
• 發佈前&發佈後
• 高頻率&低頻率

阻力因素

1. 領導或者團隊骨幹不認同
2. 爲了疲於應付
3. 以需求多，沒時間作爲偷懶藉口

組織類型

• 小組內review，一般是模塊負責人或者項目負責人review，頻率比較高，一天至少一次
• 團隊review，一般是整個團隊review代碼，團隊負責人牽頭，頻率能夠低一點，鑑於公司狀況一週至少1次吧

review內容

統一團隊代碼風格和編程規範

靜態代碼檢查工具

1. Java類：Checkstyle、FindBugs、PMD、Infer等
2. JavaScript類：JSLint、ESLint等
3. Object-C類：OCLint、Clang Static Analyzer、Infer等
4. **C#**類：StyleCode等

能夠參考的一些編碼規範(github.com/Kristories/…)

發現『bad smell』的代碼以及bug

相關書籍：《重構-改善既有代碼的設計》《代碼整潔之道》

團隊成員好的經驗

• 什麼寫法可能致使性能低下？
• 哪一個接口要慎用？
• 哪些設計方式須要規避？
• 什麼習慣容易引起內存泄漏？ ……

開發者因爲當初時間緊迫而以爲設計不合理的功能

• 功能不完善
• 設計有欠缺
• 代碼有更好實現方案
• 重視項目代碼的可讀性

總之，代碼是否符合團隊約定的代碼風格規範、代碼是否切合它所實現的業務、代碼是否安全、代碼性能、對後續開發者是否友好，便是否容易維護等

注意事項

1. GitLab能夠設置master和develop分支保護，開發者不能向這兩個分支push代碼，只能經過PR/MR形式。
2. 能夠經過設置git pre-commit hook來check，從而使不符合規範的代碼禁止提交倉庫。
3. 配合CI檢查，做爲build的第一步。
4. 用戶角色有：全部者/主程/開發者/報告者/訪客，其中只有全部者和主程纔有review代碼和合並代碼權限。
5. 注意小組至少有兩我的有權限review併合並代碼，避免一我的請假或者不在，致使代碼合不上去。
6. 主程必定要注意，避免過多模塊工做堆積在本身身上，必定要學會合理分配任務，由於你還須要有精力去review代碼，這也是一部分額外任務。
7. 提交的 feature 分支所有走 gitlab 的 MR ，develop分支不容許提交，只用來合併，而且只合並那些通過review過的代碼，master分支不容許提交，也只用來合併，而且只合並來自develop分支的代碼。
8. 不必定職稱越高，就更有可能比別人review代碼，code review知識共享更受重視，經過review發現bug是有的，但不是最終目的，增進團隊共識，保護團隊一致性其實更重要。
9. 儘可能避免開發經驗不足的開發者或者剛進公司對業務不熟悉的人員（哪怕高級工程師）review 代碼。
10. 若是能夠儘量寫單元測試，不必定cover全面，若是時間緊迫能夠只對關鍵模塊作。
11. 提交PR/MR，記得在IM上通知相關人員review，好比項目負責人或者模塊負責人。
12. 控制團隊review的時間，半個小時到1個小時，最好不要超過1個小時，30-40分鐘爲宜，項目負責人具體把握。
13. 根據公司狀況團隊review一週在至少一次比較合適。
14. review可能須要屢次才被容許合入代碼，這也就意味着，可能你的代碼須要給屢次修改才能改好。
15. 避免代碼堆積，形成一次review大量代碼，一方面急於review，這樣容易放水，同時也浪費時間，形成效果不理想。
16. 建議由1人作好記錄，把每次review的改進點以清單形式彙總列清楚發給全部參會人員。

總結

因爲工期緊、需求變動快，若是不想清楚爲何要作 Code Review ，遇到障礙會很是容易妥協，慢慢 Code Review 就會走樣，最終流於形式。反之，在咱們遇到障礙，review 代碼不順利時就會以積極的心態來解決問題。Code Review會影響開發效率，事實上追求高質量的代碼自己就下降了局部的開發效率，可是放眼長遠，這樣寫出來的代碼更加健壯，不會或不多出現「詭異」的bug，下降了後期維護的成本。

因此Code Review自己沒有問題，實際上是人容易出問題。