- 两个概念
- commit:可以单独保存的源代码最小改动单位。不要把很多改动在一个commit中提交。
- PR:代码提交请求,可以包括一个或多个commit
- 代码合并规则
- 所有的PR都必须至少一个人认可,如果改动内容较多,则需要每个项目相关人员都认可,还有一些关键代码,修改要通知所有人。
- 代码合并之前,审核者要给出评论,可以是询问,提交者给出答复;也可以指出代码问题,提交者进行修改。
- 帮助别人成长,而不是帮他写代码
- 提交代码的类型
- Bug修复
- 代码优化,如函数拆分,重构等
- 系统迁移,如代码库拆分,用另一种语言重写等。
- 新功能
- 注意事项
- 代码提交者
- 写明为什么要进行PR,指明是上面4中类型中的哪一种,便于帮助审核者理解这个改动是否合理。
- 除非极明显的单词拼写问题,尽量不要引入不是这个PR目的的改动,这样会增加审核者困难,还会掩盖一些错误,并且会导致回退困难。
- 找谁审核?找一个组,这个组就通知相关的人去审核。
- 提交的所有代码是要经过测试的。
- 代码审核者
- 审核粒度问题。可以只评论一部分,比如『支付部分没有问题』或者『API部分没有问题』等。
- 需要审核的地方:
- 代码格式。
- 代码可读性
- 业务边界和逻辑死角问题
- 错误或异常处理
- 确保测试用例覆盖到了所有功能路径
- 代码质量和规范
- 代码架构是否符合规范
- 代码提交者
- 公司层面的支持
- 提供统一的提交和审核流程和工具,确保大家使用同样的工具,遵循同样的流程。
- 鼓励员工评审逼人代码,设置可以加入绩效评估
- 指定统一的标准和规范,避免有争议的地方。
关于CodeReview
猜你喜欢
转载自www.cnblogs.com/u5f71/p/guan-yuCodeReview.html
今日推荐
周排行