Code Review
目的
-
提高代码质量
-
提前发现bug
-
统一代码规范
-
提高团队成员代码技能
前期找问题（代码规范、潜在缺陷、BUG，代码设计等等），后期演变成开发者技术交流和员工成长
如何开展
-
代码规范：明确Coding规则
-
检视清单：结合业务特点，check重点
-
总结优化：透明问题，持续优化
-
激励措施：激发主观能动性
开展方式
-
强制&非强制
-
线上交流（小组review）&线下会议（团队review）
-
小片段&大模块
-
发布前&发布后
-
高频率&低频率
阻力因素
-
领导或者团队骨干不认同
-
为了疲于应付
-
以需求多，没时间做为偷懒借口
组织类型
-
小组内review，通常是模块负责人或者项目负责人review，频率比较高，一天至少一次
-
团队review，通常是整个团队review代码，团队负责人牵头，频率可以低一点，鉴于公司情况一周至少1次吧
review内容
统一团队代码风格和编程规范
静态代码检查工具
-
Java类：Checkstyle、FindBugs、PMD、Infer等
-
JavaScript类：JSLint、ESLint等
-
Object-C类：OCLint、Clang Static Analyzer、Infer等
-
C#类：StyleCode等
……
更多可以参考的一些编码规范(Kristories/awesome-guidelines)
发现『bad smell』的代码以及bug
相关书籍：《重构-改善既有代码的设计》《代码整洁之道》
团队成员好的经验
-
什么写法可能导致性能低下？
-
哪个接口要慎用？
-
哪些设计方式需要规避？
-
什么习惯容易引发内存泄漏？
……
开发者由于当初时间紧迫而觉得设计不合理的功能
-
功能不完善
-
设计有欠缺
-
代码有更好实现方案
-
重视项目代码的可读性
总之，代码是否符合团队约定的代码风格规范、代码是否切合它所实现的业务、代码是否安全、代码性能、对后续开发者是否友好，即是否容易维护等
注意事项
-
GitLab可以设置master和develop分支保护，开发者不能向这两个分支push代码，只能通过PR/MR形式。
-
可以通过设置git pre-commit hook来check，从而使不符合规范的代码禁止提交仓库。
-
配合CI检查，作为build的第一步。
-
用户角色有：所有者/主程/开发者/报告者/访客，其中只有所有者和主程才有review代码和合并代码权限。
-
注意小组至少有两个人有权限review并合并代码，避免一个人请假或者不在，导致代码合不上去。
-
主程一定要注意，避免过多模块工作堆积在自己身上，一定要学会合理分配任务，因为你还需要有精力去review代码，这也是一部分额外任务。
-
提交的 feature 分支全部走 gitlab 的 MR ，develop分支不允许提交，只用来合并，并且只合并那些经过review过的代码，master分支不允许提交，也只用来合并，并且只合并来自develop分支的代码。
-
不一定职称越高，就更有可能比别人review代码，code review知识共享更受重视，通过review发现bug是有的，但不是最终目的，增进团队共识，保护团队一致性其实更重要。
-
尽量避免开发经验不足的开发者或者刚进公司对业务不熟悉的人员（哪怕高级工程师）review 代码。
-
如果可以尽可能写单元测试，不一定cover全面，如果时间紧迫可以只对关键模块做。
-
提交PR/MR，记得在IM上通知相关人员review，比如项目负责人或者模块负责人。
-
控制团队review的时间，半个小时到1个小时，最好不要超过1个小时，30-40分钟为宜，项目负责人具体把握。
-
根据公司情况团队review一周在至少一次比较合适。
-
review可能需要多次才被允许合入代码，这也就意味着，可能你的代码需要给多次修改才能改好。
-
避免代码堆积，造成一次review大量代码，一方面急于review，这样容易放水，同时也浪费时间，造成效果不理想。
-
建议由1人做好记录，把每次review的改进点以清单形式汇总列清楚发给所有参会人员。
总结
由于工期紧、需求变更快，如果不想清楚为什么要做 Code Review ，遇到障碍会非常容易妥协，慢慢 Code Review 就会走样，最终流于形式。反之，在我们遇到障碍，review 代码不顺利时就会以积极的心态来解决问题。Code Review会影响开发效率，事实上追求高质量的代码本身就降低了局部的开发效率，但是放眼长远，这样写出来的代码更加健壮，不会或很少出现“诡异”的bug，降低了后期维护的成本。
所以Code Review本身没有问题，其实是人容易出问题。
网友评论