浅谈代码评审

引言

最近轮到我技术分享了，把分享内容发到博客吧

对于开发同学而言，如何保证高质量代码，代码评审和重构是不可缺少的一环，通过代码评审，可以尽早的发现项目中存在的问题，也可以帮助同事之间的沟通与交流。

目录

• 代码评审的好处
• code review 流程
• code review 的内容
• 如何高效 code review
• 总结
  

代码评审的好处

• 提高代码质量

1. 对于同一段业务代码，由于看待问题的角度不同，评审者可能会比开发者更容易发现其中的问题，或是找到更有效的解决方案，共同维护团队的代码质量。
2. 提高代码质量和可维护性, 可读性等。
3. 查漏补缺, 发现一些潜在的问题点等。
4. 最佳实践, 能够更好更快的完成任务的方法。
5. 知识分享, Review 他人代码时, 其实也是一个学习的过程, 自己也会反思&总结。

• 开发者收获

1. 对需求的理解得到加深。
2. 表达能力得到加强。
3. 逻辑能力得到训练。
4. 心理承受能力得到提高。

• 评审者收获

通过有效的代码 Review，Owner 和 Reviewer 都将获得成长，在 Review 过程中参与人就具体的问题展开深入的讨论，无论是怎么写出整洁的代码、怎么更好地更全面地思考问题、怎么最佳地解决问题，参与人都可以互相取长补短，互相提高。通过具体代码实现进行的讨论往往是最深入和有效的，代码 Review 是开发者提高代码能力最重要的途径之一。

• 快速了解业务

理想状态下，团队中的每个人都需要对整个项目的各个部分都很熟悉，当然，在项目很大时这是不现实的。通过代码审查至少可以让每个人了解更多的业务模块，同时也能达到人员互备的目的。
通过相互 CR，评审者也相当于参与了这次开发，相当于一种人力“备份”，当你休假或正在忙别的需求的时候，这时“备份”或许就能帮上忙了。

code review 流程说明

code review 内容

业务逻辑

这个是最基本的要求，如果连逻辑都无法实现功能，那也没有继续看的必要了。 首先我们看下需求文档，自己上手去系统熟悉下业务，然后看下设计文档，设计文档里头就会有数据库设计，接口罗列等，然后再开始看代码逻辑是不是对的上。

技术上

1. 可读性

• 代码格式

整体代码风格保持一致，可以让阅读者比较好的阅读环境

• 字段、变量、参数、方法、类的命名是否真实反映它们所代表的事物。
• 注释

恰到好处的注释，能够帮助评审者更好地理解函数体和类。

• 方法逻辑简洁

方法要尽可能的简洁明了，这样后期维护可以通过方法名，或者方法上的备注，一眼看出这个方法是干嘛用的

• 提交记录清晰。
  

2. 设计上

• 代码的位置是否正确？比如涉及订单的新代码是否在订单服务相关的位置？
• 新代码是否重用了现存的代码？新代码是否可以被现有代码重用？新代码是否有重复代码？如果是的话，是否应该重构成一个更可被重用的模式，还是当前还可以接受？
• 表

数据表是很源头的地方，如果设计不好，后面会经常变动。表设计满足第三原则，尽量剥离各个表的依赖，然后主表跟附属表隔开。

• 接口设计

是否根据业务需求考虑接口设计保留一定扩展性

3. 性能相关

• 这段代码是否有硬性性能需求，是否满足？
• 调用数据库

如在循环中逐个调用数据库，一种情况就是加载ID列表之后，再在数据库中逐个查询ID对应的每条数据。

• 不必要的网络调用

就像数据库一样，远程服务有时也会被过度使用，原来只要一个远程调用就可实现的，或者可以使用批量或缓存防止昂贵网络调用的，却使用多个远程调用来实现。

• 是否存在内存泄露 & 无限增长问题？

Java 中一些常见的原因会是：可变的静态字段，使用 ThreadLocal 变量和使用类加载器。 如果你看见新的变量不断被加到list或map中，你就要问下，这个list或map什么时候失效或清除无用数据。

• 资源池是否配置正确？

针对一个环境的最佳配置取决于很多因素，所以作为审查者你很难马上知道像数据库连接池大小是否正确等这些问题。但是有一些是你一眼就可以看出来的，像资源池是否太小（比如大小设置为1）或太大（如数百万线程）。

• 代码是否使用了正确的适合多线程的数据结构
• 代码是否正确使用锁？作为审查者你应该检查被审代码是否允许多个线程修改变量导致程序崩溃。代码可能需要同步、锁、原子变量来对代码块进行控制。
  

4. 其他

提交代码尽量保证为单一业务，代码不过多

代码级优化

对大部分并不是要构建低延时应用的机构来说，代码级优化往往是过早优化，所以首先要知道代码级优化是否必要。

• 代码是否在不需要的地方使用同步或锁操作？如果代码始终运行在单线程中，锁往往是不必要的。
• 代码是否可以使用原子变量替代锁或同步操作？
• 代码是否使用了不必要的线程安全的数据结构？比如是否可以使用ArrayList替代Vector？
• 代码是否在通用的操作中使用了低性能的数据结构？如在经常需要查找某个特定元素的地方使用链表。
• 代码是否可以使用懒加载并从中获得性能提升？
• 条件判断语句或其他逻辑是否可以将最高效的求值语句放在前面来使其他语句短路？
• 代码是否存在许多字符串格式化？是否有方法可以使之更高效？
  

引用第三方类库

第三方类库是侵蚀系统安全并引起漏洞的一个途径。当审查代码时至少你要检查是否引入了新的依赖。

代码的运行是否应该被日志记录或监控？是否正确地使用？

日志和监控需求因各个项目而不同，一般会关注这些：

• 代码是否改变了数据（如增删改操作）？是否应该记录由谁何时改变了什么？
• 代码是否涉及关键性能的部分？是否应该在性能监控系统中记录开始时间和结束时间？
  

如何高效 code review

• 明确 code review 中事项的优先级

从上面也能看出来 code review 要关心的事项还是很多的，所以安排事项优先级可以帮助处理主要问题。

• 尽可能及时的进行 code review

当你收到别人的 code review 邀请时，尽量第一时间就开始。因为这时我们的记忆是最清晰的，并且通常会 对你的及时反馈心怀感激，这种正面情绪对于 code review 是非常有帮助的。

• 可以在 ide 开发环境中去 reivew

一般我们 code review 是在 gitlab 中自己用眼睛去看，更好的方式是用 IDE 各种自动提示功能，各种强大的 IDE 完全可以成为我们的一大助力。

• 不要吝啬你的赞扬

每个人的内心深处都是期待被别人称赞的，因此在 code review 开始的时候不要老是揪着变量命名、代码重 复之类的问题。code review 中发现好代码，可以给作者一些赞美，这样他们也就会乐于接受你对于代码风格等方面的建议了——它能培养出强大而积极进取的团队 : )

• 把程序跑起来

把程序运行起来，亲自试一试，或许你会有一些和他们测试时不同的操作，发现一些他们遗漏的问题。

• 明确 Coding 规则标准

没错，和公司 kpi 一样，只有量化的指标，才能高效的执行。比如一个方法多少行算过长？如果总是参考上下文去判断，后面所有人就不会考虑这个问题了，因为太难判断，强制规定为一个方法最多不超过 80 行，code review 该事项则会事半功倍。

• 善用各种自动化工具

可以搭建好各种完善的自动化流程，如 CI/CD，代码质量测试工具：SonarQube等，把一些工作交给机器总是比人更高效的。

结束语

代码审查是针对代码，不是针对人。代码审查是一种学习，是表扬，是获得反馈，是一种十分社交性的活动。代码审查应该是有趣的，不要让它变的无聊。

• 适当的激励机制更好的激发团队主动性。
• 按照经验，code review 启动前期建议采用强制要求，否则很难有效开展起来。坚持一段时间待习惯养成后再考虑放开。
• code review 的方式有多种方式：强制&非强制、线上交流&线下会议、小片段&大模块、事前&事后、高频率&低频率，建议根据团队水平因地制宜。