标签：code 代码 组内 bug 关于 reviewer 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

本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享；
2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关；
3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关；
4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除；
5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。