如何做好 Code Review

职责

Code review 不应该承担发现代码错误的职责。Code Review主要是审核代码的质量，如可读性，可维护性，以及程序的逻辑和对需求和设计的实现。

如何审查代码

1.关注代码风格规范：包括但不限于：命名规范、代码缩进、注释和文档等等
2.关注代码调用是否破坏了当前代码架构
3.代码逻辑中的异常处理、资源处理、线程、安全
4.关注业务实现逻辑
5.是否有优化空间：重复代码、过长函数等等

Code Review时该关注的

1.体系结构和代码设计

代码复用: 根据“三振法”, 如果代码被复制一次，虽然不喜欢这种方式，但通常没什么问题。但如果再一次被复制，就应该通过提取公共的部分来重构它。
用更好的代码: 如果在一块混乱的代码做修改，添加几行代码也许更容易，但建议更进一步，用比原来更好的代码。
潜在的bugs: 是否会引起的其他错误？循环是否以我们期望的方式终止？
错误处理: 错误确定被优雅的修改？会导致其他错误？如果这样，修改是否有用？
效率: 如果代码中包含算法，这种算法是否是高效？例如，在字典中使用迭代，遍历一个期望的值，这是一种低效的方式。
新代码与全局的架构是否保持一致？
基础代码是否有结合使用了一些标准或设计样式，新的代码是否遵循当前的规范？代码是否正确迁移，或参照了因不规范而淘汰的旧代码？
代码的位置是否正确？比如涉及订单的新代码是否在订单服务相关的位置？
新代码是否重用了现存的代码？新代码是否可以被现有代码重用？新代码是否有重复代码？如果是的话，是否应该重构成一个更可被重用的模式，还是当前还可以接受？
新代码是否被过度设计了？是否引入现在还不需要的重用设计？
2、可读性和可维护性
字段、变量、参数、方法、类的命名是否真实反映它们所代表的事物, 是否能够望文生义?
是否可以通过读代码理解它做了什么？
是否理解测试用例测了什么？
测试是否很好地覆盖了用例的各种情况？它们是否覆盖了正常和异常用例？是否有忽略的情况？
错误信息是否可被理解？ log打的是否正确和足够?
不清晰的代码是否被文档、注释或容易理解的测试用例所覆盖？具体可以根据团队自身的喜好决定使用哪种方式。

3.功能

代码是否真的达到了预期的目标？如果有自动化测试来确保代码的正确性，测试的代码是否真的可以验证代码达到了协定的需求？
代码看上去是否包含不明显的bug，比如使用错误的变量进行检查，或误把and写成or？
作者是否需要创建公共文档或修改现存的帮助文档？
是否检查了面向用户的信息的正确性？
是否有会在生产环境中导致应用停止运行的明显错误？代码是否会错误地指向测试数据库，是否存在应在真实服务中移除的硬编码的stub代码？
你对性能的需求是什么，你是否考虑了安全问题？
这个新增或修复的功能是否会反向影响到现存的性能测试结果
外部调用很昂贵(a. 数据库调用. b. 不必要的远程调用. c. 移动或穿戴设备过频繁地调用后端程序)

4.其他方面

是否合理地释放了资源
是否存在内存泄漏?
是否存在内存无限增长? 例如, 如果审查者看到不断有变量被追加到list或map中, 那么就要考虑下这个list或map什么时候失效, 或清除无用数据
代码是否及时关闭了连接或数据流?
资源池配置是否是否正确? 有没有过大或者过小?
异常情况是否能够正确处理?
超时是否能够正确处理?
调用接口出错的时候, 是否有出错处理逻辑, 并且处理正确?
进程意外重启后, 是否能够恢复到崩溃前的环境?

如何提高 Code Review 的效率

1.合并信息规范：[序号]. [类型]: [内容] [禅道号]
2.每次只 review 少量代码，即发起的 MR 代码量要少，也就是说要小步提交
问题：怎么设计分支管理与开发阶段的合并请求?

参考

https://blog.csdn.net/zhang_yin_liang/article/details/113876208