如何在IntelliJ IDEA中进行Java代码审查

在 IntelliJ IDEA 中进行 Java 代码审查的实操指南

一 本地自查流程

• 代码风格统一：在 File → Settings → Editor → Code Style → Java 配置缩进、换行、命名等规范，确保团队一致；提交前执行 Reformat Code（如 Ctrl+Alt+L）统一格式。
• 静态分析总览：使用 Code → Inspect Code 对项目或目录做全量扫描，按问题类别（如未使用代码、潜在空指针、资源未关闭等）逐项修复。
• 按名称运行检查：通过 Analyze → Run Inspection by Name 快速定位特定问题，例如输入 unused declaration、unused import 清理无用声明与导入。
• 变更级差异审查：在提交前用 Git → Show History / Compare with 查看改动，结合 Local Changes 窗口聚焦本次提交内容；必要时使用 Annotate 追溯行级变更历史。
• 运行与覆盖率：用 Ctrl+Shift+F10 运行测试，结合覆盖率工具（如 Ctrl+Alt+F6）确认新增代码被有效测试覆盖。
• 提交规范：在提交面板填写清晰的 Commit Message，只提交与本次改动相关的文件，保持提交粒度小而聚焦。

二 借助插件强化质量门禁

• Alibaba Java Coding Guidelines：基于 Inspection 的实时/批量扫描，按 Blocker/Critical/Major 分级，覆盖并发、OOP、命名、注释等规约，支持一键定位与批量修复。
• CheckStyle-idea：强于编码规范（命名、Javadoc、缩进、import 顺序、方法长度等），可导入团队 checkstyle.xml 统一标准。
• PMD：聚焦潜在缺陷与坏味道（如空 catch、未使用变量、复杂表达式、重复代码等），支持自定义规则集，适合在 IDEA 中按需运行。
• SonarLint：在编码阶段实时提示代码异味、漏洞与坏味道，可与 SonarQube 联动获取项目级规则与质量阈值的反馈。

三 团队协作的 PR 审查

• 在 GitHub/GitLab 创建 Pull Request，利用差异视图、行级评论与讨论区进行评审；可配置分支保护规则，要求指定人员 Approve 后方可合并。
• 安全与质量门禁：在仓库启用 CodeQL Analysis 工作流，提交或推送触发自动扫描，结果在 Security 标签展示 Code scanning alerts，作为合并前的重要参考。
• IDEA 侧配合：本地完成 Inspect Code 与单元测试，再推送分支发起 PR，减少来回迭代。

四 审查清单与常见问题

• 规范与可读性：命名清晰、职责单一、注释充分；无 unused import/declaration；遵循团队 Code Style。
• 空值与异常：对可能为 null 的输入进行防御；避免空的 try/catch/finally/switch；资源（如流、连接）正确关闭。
• 并发与线程安全：共享可变状态的可见性与同步策略合理；避免不正确的锁顺序与数据竞争。
• 性能与复杂度：避免字符串在循环内频繁拼接（优先 StringBuilder）；减少不必要对象创建；方法长度与圈复杂度受控。
• 测试与覆盖：新增/修改逻辑具备对应 JUnit 5/TestNG 测试，关键路径覆盖充分；必要时查看覆盖率报告。
• 工具误报处理：如 Lombok @Data、@Value 等注解可能触发“未赋值/未使用”的误报，结合上下文与工具配置进行甄别。

五 推荐工作流

• 开发前：拉取最新主干，基于功能或修复创建分支；在 Code Style 与团队规范对齐。
• 编码中：开启 Alibaba/CheckStyle/PMD/SonarLint 实时提示；小步提交，每次提交前运行 Inspect Code 与单元测试。
• 提交前：执行 Reformat Code、整理 Commit Message，确保提交仅包含本次变更。
• 提交后：推送分支并发起 PR，在 GitHub/GitLab 进行行级评审与讨论；必要时补充测试或调整实现。
• 合并前：确认 CodeQL 等安全扫描通过，满足审批与状态检查后合并；删除已合并分支，保持仓库整洁。