目录
前言
你是否曾写过一个很简单的需求或者优化？而且你认为不需要审查，就可以直接合并到主分支。可能过了几天或者几周，你突然意识到你犯了一个明显的或是不应该的错误。如果有其他人来审查代码，那这个问题可能就会被发现并及时处理。
CodeReview（代码评审）是一种用来确认方案设计和代码实现的质量保证机制，通过这个机制我们可以对代码、测试过程和注释进行检查，主要用来在软件工程开发过程中改进代码质量。
可能大家会认为必须是领域内的专家或者资深工程师才能审查别人的代码，但是以笔者的经验来看：其实并不是这样的，评审人并不需要完全理解该项目的业务需求或者有多么丰富的编码经验，只需要为本次代码评审提供新的、合理的、符合规范的视角。
下面笔者以自己的实际经验来和大家分享一下，如何做好项目开发中的代码评审。
一、为什么要做
代码评审首要目的就是为我们带来一双新的眼睛，从新的视角去看待那些潜在的问题。
以笔者目前所在的团队来说，代码审查是开发过程中的关键步骤。通过尽早发现和解决问题，不仅能提高产品的质量，还能确保代码的一致性和可靠性，它还能让开发团队对产品的构建方式与产品所需要的标准达成一致。
因此，尽管代码评审可能在当前会比较费时费力，但随着时间的推移，代码审查发挥的作用会越来越明显。
二、有哪些好处
CodeReview 习惯的保持、积极参加团队的 CodeReview，起码能有以下几点显而易见的好处：
- 提升代码质量：代码评审可以帮助团队成员发现潜在的缺陷、漏洞和性能问题，从而确保代码的稳定性和可维护性。通过评审，团队成员可以互相学习，借鉴他人的优秀实践，提高自己的编码水平。
- 促进团队协作：代码评审是一种提高团队协作的方式，有助于团队成员更好地了解彼此的工作内容和进度。在评审过程中，团队成员可以互相交流、分享经验，从而提高整个团队的技术水平和解决问题的能力。
- 保证项目进度：代码评审可以及时发现和解决问题，避免在项目后期出现严重的技术债务。通过评审可以确保项目按计划推进，提高开发效率。
- 培养团队文化：代码评审有助于培养团队的学习氛围和进取精神。通过互相评审，团队成员可以共同进步，形成积极向上的团队文化。
三、具体怎么做
3.1评审条件
- 前置条件：代码已通过 Alibaba Java Coding Guidelines(idea 插件）的代码检查；
- 大型项目：增加/修改超过 10 个文件或超过 200 行代码的，需组织 CodeReview 会议，邀请相关同事及高级/资深开发同事参与；
- 小型项目：小需求修改如：少于 10 个文件变更或少于 100 行代码的），至少需要 1~2 位同事帮忙 Review 并提出修改建议；
- 重点逻辑：建议邀请负责过该项目的同事共同 Review 一下，或者在开发的时候结对 Review。
3.2评审重点
- 完整性检查：功能点、业务日志、异常日志等
- 一致性检查：代码逻辑是否符合设计文档，代码风格是否统一等
- 正确性检查：技术选型、注释是否准确、变量的定义和使用等
- 可修改性检查：如魔法值 123，使用专门的常量类或枚举等
- 可预测性检查：死循环、无穷递归、数组越界、空指针等
- 可理解性检查：命名规则、注释是否清晰、git 提交记录描述等
- 逻辑性检查：实现不过于复杂、代码拆分、可读性、扩展性等
- 安全性检查：包括防止注入攻击、保护敏感数据、接口鉴权等
3.3评审形式
-
会议评审：将相关评审人员集中在一起，通过会议讨论的方式进行代码评审，如无其它紧急情况，建议每月一次。此方法适用于中小型团队或重要的代码更改。
如：
- 部门负责人组织评审会议，时间可以固定在当月的某一天，大约 15-20 分钟；
- 地点可以选择一个小的会议室，大约能容纳 10-15 个人，需要有投影设备；
- 与会人员可以是部门的整个后端团队，拟定一个主评审人，大家都可以参与讨论
-
随机抽查：随机选择一部分代码进行评审，以验证代码的质量和规范性。这种方法可以作为团队日常工作的一部分。
-
工具支持：使用代码评审工具来自动化一些评审过程，例如代码静态分析工具和代码规范检查工具。这些工具能够提供一些有关代码质量的重要指标，并帮助识别潜在的问题。
四、还可以怎么做
4.1提出亮点
- 不仅要提出需要改进的地方，也要提出本次代码评审的亮点，具体可以从以下几点入手：
- 性能优化：是否有对性能有优化，合理使用数据库连接、时/空间复杂度、内存操作等；
- 设计模式：是否有抽象出通用的设计模式，显著提高模块的复用率、扩展性等；
- 工具/插件：是否有能提高效率的工具类，包括可以发布的插件以及自定义注解等。
4.2轮流评审
- 需要注意的是，主评审人应该是团队里的每一位成员，而不是仅由部门领导或资深工程师来担任，理由如下:
- 集思广益：每次的代码评审最重要的是引入新的视角来看待潜在的问题，每个人都会有自己的视角，这样有助于团队统一认识；
- 机会平等：年轻的工程师们虽然可能经验不足，但干劲儿可能比较足，如果能借此机会得到一些锻炼，那么对团队来说会是一件好事。
4.2文档沉淀
- 有了以上的种种具体做法，那么最终还是要把结果文档化、持久化的，具体可以：
- 评审会议前由主评审基于模板去拟好一篇文档在会上展示，包括给出代码片段、改进建议、提出亮点等，方便会上大家及时讨论补充；
- 会后可以上传到团队的文档空间或者工作集当中，方便团队成员随时学习、回顾。
五、文章小结
关于如何做好项目开发中的 CodeReview（代码评审）就和大家分享到这里，希望能对大家有一些帮助。
写在最后，文章如有不足和错误，还请大家指正。或者你有其它想说的，也欢迎大家在评论区交流！
标签：CodeReview,检查,代码,评审,团队,可以 From： https://www.cnblogs.com/CodeBlogMan/p/18278962