意义

• 团队知识共享

  代码审查，就是一个很好的知识共享的方式。通过代码审查，高手可以直接指出新手代码中的问题，新手可以马上从高手的反馈中学习到好的实践，得到更快的成长

• 代码质量

  对于代码质量来说，很多问题通过测试是测试不出来的，只能通过代码审查。比如说代码的可读性可维护性，比如代码的结构，比如一些特定条件才触发的死循环、逻辑算法错误，还有一些安全上的漏洞也更容易通过代码审查发现和预防。

• 团队规范

​ 每个团队都有自己的代码规范，有自己的基于架构设计的开发规范，然而时间一长，就会发现代码中出现很多不遵 守代码规范的情况，有很多绕过架构设计的代码。比如难以理解和不规范的命名，比如三层架构里面UI层绕过业务逻 辑层直接调用数据访问层代码。

方式

工具扫描　＋　人工审查

工具扫描适合的方面

1. 代码风格与格式: 自动化工具非常适合检查代码风格一致性，包括缩进、空格、命名规范等，确保代码遵循固定的风格指南。
2. 错误模式检测: 静态分析工具如 SonarQube, FindBugs, 或 PMD 可以识别常见的编程错误，如空指针访问、未关闭的资源、潜在的线程安全问题等。
3. 复杂度计算: 工具可以计算函数或类的复杂度，帮助识别过于复杂难以维护的代码区域。
4. 安全漏洞扫描: 专门的安全扫描工具能够检测到潜在的安全漏洞，例如 SQL 注入、跨站脚本攻击(XSS)、不安全的数据加密等。
5. 代码重复检查: 工具可以有效识别代码中的重复部分，帮助开发者避免不必要的代码重复，提升代码的可维护性。

人工审查适合的方面

1. 逻辑正确性与业务逻辑: 人工审查更适合评估代码是否正确实现了业务逻辑，以及逻辑的健壮性和效率。自动化工具难以完全理解业务需求的复杂性。
2. 代码可读性与维护性: 虽然工具可以检测一些可读性问题，但对代码整洁度、代码组织结构及未来可维护性的评估，通常需要经验丰富的开发者通过人工审查来完成。
3. 架构和设计: 评估代码是否遵循项目的架构原则，组件间的依赖关系是否合理，以及是否正确使用了设计模式。
4. 性能优化: 高级的性能问题，如内存使用优化、算法选择、多线程竞争等问题，通常需要开发者的直接介入和理解。
5. 团队标准与最佳实践: 确保代码实现符合团队的特定最佳实践，这些往往包括但不限于代码简洁、解决方案的创新性或特定的项目标准。

评审条件

1、大型项目，增加/修改超过10个文件或超过500行代码的，需组织CodeReview会议，邀请相关同事及高阶同事参与代码Review
2、小型项目，小需求修改（少于10个文件变更或少于500行代码的），至少需要1~2位同事帮忙进行代码Review并提出点评建议
3、重点逻辑，建议找相关同事共同Review一下

代码评审的先决条件：代码已通过Alibaba Java Coding Guidelines(idea 插件）进行代码检查。

评审时间

Code Review由项目负责人发起，一个项目过程中至少2-3次，主要集中在项目中后期，如果项目规模较大，功能较多，时间比较宽裕，也可适当增加。

PS：代码评审不需要太正式，时间不宜太长，建议控制在30分钟以内。

注意：代码评审必须在在项目提测时间前后一两天完成，万不可等到测试之后再来评审。

CheckList

1. 代码正确性和功能性

• 确认代码实现的功能与需求或任务描述相符。
• 检查逻辑错误或潜在的运行时错误。
• 验证边界条件和异常处理是否充分。

2. 代码可读性

• 确保代码命名清晰（变量名、函数名、类名等）。
• 检查函数和类是否单一职责。
• 代码是否有适当的注释，特别是对复杂逻辑的解释。

3. 代码健壮性

• 判空处理
• 越界是否有做判断
• 错误是否正常捕获，报错是否被忽略

3. 代码效率

• 检查是否存在不必要的计算或重复的代码块。
• 评估循环和递归的效率。
• 确认使用的数据结构和算法是否最适合问题。

4. 代码安全性

• 检查是否有安全漏洞，如SQL注入、XSS攻击等。
• 验证数据输入是否进行了适当的清洗和验证。
• 确认敏感数据是否被正确处理和加密。

5. 代码一致性和风格

• 确认代码遵守了项目的编码标准和风格指南。
• 检查代码中的格式是否一致（如括号使用、缩进等）。

6. 单元测试和覆盖率

• 确认是否为新加的代码编写了单元测试。
• 检查现有测试是否因修改而需更新。
• 评估测试覆盖率是否足够。

7. 性能优化

• 检查关键路径或核心功能的性能指标。
• 评估可能的性能瓶颈。
• 推荐可能的优化方法。

8. 依赖管理

• 检查代码中新引入的外部库或框架是否得到了充分的评估（比如安全性、维护性、许可证兼容性）。
• 确认项目依赖是否保持最新，及时替换或升级过时的库。
• 验证依赖关系是否清晰，避免不必要的复杂性。

9. 国际化和本地化

• 确认代码是否考虑了国际化（i18n）的需求。
• 检查字符串是否被正确地外部化，易于翻译。

10. 并发和多线程

• 对于涉及并发或多线程的代码，检查是否有竞争条件或死锁的风险。
• 验证同步机制是否得当，确保数据完整性和一致性。

11. 代码重构和技术债务

• 评估代码中是否存在需要重构的部分，以改善可读性或性能。
• 讨论和标记技术债务，计划合适的时机进行解决。
• 鼓励不断的小幅优化，以避免大规模难以管理的重构。

12. 代码的可配置性

• 确认系统的关键行为是否可以通过配置而非代码更改来调整。
• 检查配置文件是否清晰，且有适当的注释。

13. 监控

• 确保有监控和警告机制，以便及时
• 异常时是否可以追溯

开发者需注意事项

• 做好提交，即将提交做小做好。写小提交就是将问题解耦：“Do one thing and do it well”。每个提交控制在只修改一个到几个文件，每次只修改几行到几十行。每个提交应该是一个完整的功能，可能是修改某个bug 或完成某个小需求的开发。
• 充分描述，对于代码评审描述应介绍本次改动的需求背景，改动范围及影响点。一段清晰的评审描述能让reviewer充分理解需求背景，快速开始评审，降低沟通成本。
• 数字化度量，通过数据洞察获得团队质量情况，有策略的提升团队技术能力。