关于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自己没有问题，实际上是人容易出问题。