从零开始掌握Skill代码Review：新手工程师的避坑指南与实践手册

15次阅读

共计 1804 个字符，预计需要花费 5 分钟才能阅读完成。

作为刚接触代码 Review 的新手，你是不是经常遇到这些情况：花了半小时讨论缩进空格，却漏掉了 SQL 注入漏洞；或者面对同事的代码时，只能含糊地说 ” 看起来没问题 ”？根据团队调研，新手在代码 Review 中普遍存在三类典型问题：

形式大于内容 ：过度纠结于代码风格（如大括号换行），而忽视架构设计和业务逻辑的合理性
视角单一 ：只检查自己熟悉的模块，对安全性、性能边界等关键缺陷选择性失明
反馈失效 ：用 ” 这里可能需要优化 ” 等模糊表述，导致问题反复出现

变更动机优先原则 ：首先确认代码变更是否解决了正确的问题。比如修复 Bug 时，要验证：
是否准确复现了原始缺陷
测试用例是否覆盖边界条件
防御性阅读 ：假设所有代码都可能出错。重点关注：
输入验证和异常处理（特别是第三方 API 调用）
资源管理（数据库连接、文件句柄是否及时释放）
正向反馈闭环 ：对良好的代码实践要具体表扬。例如：
“ 这个使用 MapReduce 分解计算任务的设计，有效控制了单个节点的内存压力 ”

# 设置 PR 模板（.github/pull_request_template.md）## 变更类型
- [ ] Bug 修复
- [ ] 功能新增
- [ ] 重构优化

## 自检清单
- 已添加单元测试
- 文档已更新
- 通过 SonarQube 扫描

在质量配置文件中启用：
“Avoid SQL injection”（安全）
“Cognitive Complexity > 15″（可维护性）
与 CI 集成示例：

# GitLab CI 配置示例
sonarqube-check:
  image: sonarsource/sonar-scanner-cli
  script:
    - sonar-scanner
      -Dsonar.projectKey=my_project
      -Dsonar.login=${SONAR_TOKEN}
  rules:
    - if: $CI_PIPELINE_SOURCE == "merge_request_event"

[] 所有用户输入都经过验证或转义
[] 敏感信息未硬编码（检查.properties 文件）
[] API 权限校验遵循最小权限原则

[] 循环体内无重复计算（时间复杂度优化）
[] 批量操作使用连接池
[] 缓存策略考虑失效场景

// 用户积分处理服务
public class PointsService {public void addPoints(long userId, int points) {
        String sql = "UPDATE user SET points = points +" + points 
                     + "WHERE id =" + userId;
        jdbcTemplate.update(sql); // 高危 SQL 注入

        if(points > 1000) {sendSMS(userId); // 未处理异常
        }
    }
}