关于code review

关于code review
背景：我们组是属于技术平台，后端一共就4个研发，主要是给整个部门提供基础库，以及解决方案，所以代码量不多，对代码要求质量比较高，组内成员整体水平也比较高，有行业天花板的大佬。
纯技术团队：
review关注点：
1.架构设计，重点关注是不是最优，而不单纯只是合理
2.代码质量，重点关注有没有可能引发bug之类的
3.是否符合预期，是否考虑到特殊场景
review过程：
1.代码量少，所以我们都是有功能要发布了才review，没有提前做准备之类的。
2.review过程总有碰到意见不一致的时候，一般就单独拉出来，群里大家讨论。讨论之后很少出现意见不一致的情况，因为组内有几个大佬存在，一般意见都能达成统一。并且组内氛围也很好，不会出现互相diss，谁不服谁的情况。

同时我们组也会给业务研发团队做一些code review。
code review要求：
1.在提交给我们组review之前，必须先把sonar上报的问题给解决了。
2.最好是组内核心成员能先review，对于有争议的部分，拉出来给我们组review。
3.一次review的代码不能太多，保持在几百行之内，不要上来就上千行代码。
4.如果真的模块很大功能很多，可以拆分成小功能小模块进行review。
5.review时间点，一定不是上线前，也不是测试验收后，而是在开发过程中，逐步review，不是交付之后才review。
6.reviewer要了解被review代码的业务，可以不是非常深入，但是至少要了解。
7.reviewer可以是同级，也可以是组内专家，也可以是外援

review重点关注的点：
1.保持代码风格一致
2.代码是否与需求保持一致，能否达到产品/业务预期
3.代码是否有优化空间，比如是否需要重构、有更好的设计模式、有更好的写法
4.是否存在隐藏的bug，包括代码本身的bug以及业务逻辑的bug

review过程：
1.研发在提出mr之后，进行review，可以是1v1，或者几个人找个会议室。推荐就在工位上，一起review，一起讨论，有问题的直接写评论。
2.提mr的研发，一定要提前通知reviewer，而不是提个mr，丢给reviewer就不管了(出现过这种情况，丢个mr链接，@reviewer，就忙自己的事儿去了)
3.review的工具使用gitlab，而不是在代码里添加注释/TODO之类的。
4.意见不一致的时候，写个评论标注一下，后续私下再深入研究或者找专家讨论都可以。
5.review结束之后，研发修改完问题，如果是简单的问题，就直接approve进master，如果是比较大的改动，需要reviewer再次确认。
6.一定要针对问题，不要针对人，要保持谦虚和气。review是互相学习的过程。

标签：code,代码,组内,bug,关于,reviewer,review
来源： https://www.cnblogs.com/linjiqin/p/16350873.html