# 前言
之前有一篇文章讨论了做CodeReview的目的和优点。今天再来讨论在CR具体实践过程中可能遇到的常见问题及应对方法。
![image.png](https://developer.qcloudimg.com/http-save/yehe-1367556/2013e6146099fa9d302853627b3a4ddb.png)
# 反对者的理由
有人可能会说：“CR太耗时间，手头事多忙不过来”，或者“我们以前不做CR，也没出过什么大问题”。

实际上，在CR推行的初期，确实会增加团队的时间投入。但随着CR机制逐渐成熟，其带来的长期收益将日益显著——包括团队技术能力的快速提升、协作氛围的增强、Bug数量的下降，以及需求交付效率的提高。

此外，开发人员常有两种心理顾虑：一是将代码视为私密资产，不愿轻易展示；二是在收到大量修改意见时，容易产生被否定的感受。

理解并化解这些心理障碍，是建立健康CR文化的关键。要明确，我们必须明确，CR的最终目标是共同提升代码质量和个人能力，而不是为了批评某个人。当CR成为开放、信任、积极的团队习惯时，这样的心理负担自然会减轻。

# 提交者应遵循的准则
1. **清晰说明修改背景**：代码提交时要说清楚本次修改的目的和方式,要帮助评审的人了解代码的背景和解决的问题。
2. **控制每次提交的代码量**：尽量每个CR都包含较少的代码,可以分步有序提交，先整体后细节。原则是不要让评审者花太多的时间在一个CR上。这样Reviewer也不会因为代码行太多,有压力,不能尽快的review完成。长时间在review，其实脑子也容易晕乎乎的，效率会下降。
3. **一次只解决一个问题**：一个CR提交尽量只解决一个功能问题,不要把多个功能点用一个CR解决,这样其实会大幅增加reviewer的工作量。比如解决一个用户登录的需求,最后把微信,QQ登录,手机绑定等流程分别实现,分别提交CR,不然众多逻辑的代码交织在一起,reviewer需要付出比较大的认知成本。
4. **提交前自我审查**：提交CR前自己要再检查一遍代码,自我review一次,避免低级错误。这既体现专业性，也表达对评审者的尊重。
5. **重大变更提前沟通**：如涉及架构或设计层面的重大调整,最好提前和reviewer沟通,避免因为设计问题而做了很多无用功。因为这时候代码已经写了，如果设计上有缺陷，进退两难，改吧，成本太高，不改吧，设计上有缺陷是很严重的事情，可能造成需求实现不了或者线上事故。
6. **保持开放心态**：对于评审意见，应尽量采纳，即使认为细节无关紧要，也应尊重对方建议。
7. **遵守代码规范**：不随意破坏既定规范，保持代码风格一致。
# Reviewer的职责与方法
1. **关注两类问题**：一是代码规范问题；二是业务逻辑问题。代码风格其实一般都有开源的规范，照着这个稍微因地制宜下就行。业务逻辑则要求你站在提交者的角度，想象如果是自己会如何实现这个需求，方案有什么区别，为什么这样做而不是那样做，理由是什么。其实也是一次提升自己设计能力的机会。
2. **问题分优先级**：任何时候先提重要的问题,问题很多时,那么先提最重要的忽略次要的。等重要的问题都解决了再提次要的。另外大多数人是无法接受对方一次给提出好几十个问题的,这会让人觉得自己的代码太糟糕,俗称破防了，不利于后续双方理智探讨。
3. **区分问题重要性**：那么什么是重要的问题呢,业务边界,逻辑流程,设计接口,代码架构,性能这些都是。逻辑死角,错误处理,可读性问题,测试用例,代码风格,注释,命名等问题,相对次要。另外不要提重复的问题，同类问题点出一两个就好，没必要都点出来。
4. **尊重不同设计观点**：至于什么是好的设计,好的架构,一般有一些共同的准则,实际上并没有什么强制硬性的规定,仁者见仁智者见智,大家达成一致就好。如果道理说不通,达不成一致,一般默认尊重developer的意见，毕竟从某些方面上来讲，他对这个系统/模块有信息上的优势，某些点是你可能不了解的。。
5. **意见具体明确**：反馈应清晰具体，避免含糊。如能通过示例代码或伪代码说明，更利于理解。
6. **对事不对人**：Reviewer提的意见需要对事不对人,绝对要避免对个人的评平价,比如“你这个设计效率太低”改为“这个设计在效率上可能还有优化空间，原因是……”
7. **不主观臆断**：如果代码符合代码规范,逻辑也正确,那么reviewer应避免根据自己已的编程习惯来评判别人的代码,"难得糊涂"。当然违反了代码规范那是另一回事了。
8. **不为了评论而评论**：不要为了提意见而提意见,不能为了review而review。
9. **及时完成评审**：在合理时间内完成CR，既不耽误开发进度，也不因匆忙影响质量。毕竟那边还在等着你`LGTM`点通过然后上线呢。
10. **不吝赞美**：对代码中的优秀实现，应给予肯定和鼓励，谁不想被人叫一声“大牛”呢，是吧。
# 团队如何有效推进CR？
1. **明确代码规范**：参考公司或行业现有规范，制定适合团队的代码标准
2. **设立代码负责人**：各个业务模块找出各自的代码owner,负责本模块的代码审核该,拥有对代码审核的最终决定权。如果一个模块只有一个人在维护开发,那么也要给它配一个资深reviewer
3. **建立CR制度**：规定代码提交必须经过评审（紧急Bug修复等特殊情况除外），未通过CR的代码不得入库。真的，很多技术债就是开口子造成的。
4. **骨干带头示范**：CR做好并不是一件容易的事情,不是一开始就能轻松做好的。技术骨干和leader要首先站出来,积极参与,作为reviewer认真负责的做好每一次CR,逐渐熟悉,逐渐磨炼,为其它同学树立榜样。
5. **设置正向激励**：通过CR统计看板等方式，对表现优秀的成员给予认可，并在绩效考核中予以体现

之前有一篇文章讨论了做CodeReview的目的和优点。今天再来讨论在CR具体实践过程中可能遇到的常见问题及应对方法。

代码评审实践指南

十倍工程师

职业发展

后端

编程语言

CodeReview实践指南：提升代码质量与团队协作的关键方法。详解CR常见问题应对策略，包括提交者准则、评审者职责及团队推进方法。掌握控制代码量、分优先级评审、保持开放心态等核心技巧，有效解决"耗时"、"心理负担"等顾虑，建立健康CR文化，实现技术能力提升与交付效率双赢。

腾讯云BI新客户首次购买9.9元起！


文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

代码评审实践指南-腾讯云开发者社区-腾讯云

代码评审实践指南

代码评审实践指南

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐