代码评审

代码评审的对象

需要多人评审：

• 修改原有业务逻辑
• 引入新的软件组件
• 新建数据表

只需要 Double Check：

• 删除下线的代码块
• 修改配置文件

代码评审的目的

最大化维护团队利益

代码评审的重点

• 逻辑错误
• 代码规范
• 代码的可读性和可维护性
• 设计模式理念

代码评审不应该关注

• 能否正常运行
• 是否满足也无需求
• 能否覆盖业务场景

*这几点应交给开发和测试来负责

代码评审流程

1. 制定排期 -> 评审需要的时间，需求的提测时间、上线时间
2. 补充资料 -> 需求背景，编码内容，功能影响范围
3. 代码评审 -> 发现并处理问题
4. 完善必备元素 -> 避免重复出现相同问题
5. 完善代码规范约束 -> 形成知识沉淀

常见共性问题

1. 缺少注释和变更说明
2. 过度相信第三方 -> 限制和校验请求参数

1. 变量的作用域过大
2. 缺少阶段性的结果
3. 日志问题 ->
   1. 记录参数、中间结果，返回信息，异常信息
   2. 避免空对象序列号，避免无界的异步队列