code-review

name	code-review
description	代码自审技能，开发者自查代码质量、安全性、架构一致性和规范合规

代码审查技能

何时使用

• 开发完成后，Developer 进行代码自审
• 变更开发时，审查变更代码是否超出设计的影响范围

输出格式

按 process_templates/code_review.md 模板输出。

输出规范

代码审查报告必须包含以下字段：

字段	必填	说明
Result	是	approved / changes_required / rejected
Date	是	审查日期
Reviewer	是	Developer(自审)
审查范围	是	审查的文件列表和代码行数
Checklist	是	各检查项的通过状态
Findings	是	发现的问题列表（可为空）

审查步骤

1. 架构一致性检查

• 代码结构是否与 architecture.md 中的模块划分一致
• 模块间依赖方向是否与架构图方向一致
• 是否有跨层调用或违反分层原则的代码
• （变更模式）变更是否超出 requirements.md 影响分析的范围

2. 功能正确性

• 是否实现了 requirements.md 中的功能需求
• 是否处理了边界条件
• 是否有逻辑错误

3. 代码质量

3a. 命名与可读性

• 命名是否清晰（变量、函数、类、文件）
• 函数/方法是否简短（建议不超过 50 行）
• 注释是否充分（公共接口必须有注释）

3b. 冗余性检查

• 是否存在未使用的变量、函数、导入、参数
• 是否存在永远不会执行的死代码（unreachable code）
• 是否存在无意义的空异常捕获或空条件分支
• 是否存在已被注释掉但未删除的旧代码

3c. 重复性检查（DRY 原则）

• 是否存在逻辑相同或高度相似的代码段（≥10 行相似视为重复）
• 重复的业务逻辑是否可抽取为共享函数或基类方法
• 多处硬编码的相同值是否可提取为常量或配置项
• 不同模块中的相似数据转换/校验逻辑是否可统一

3d. 可复用性检查

• 通用工具函数是否放置在 utils/helpers 层而非业务模块内
• 公共逻辑是否通过参数化实现通用，而非为每个调用方复制一份
• 跨模块共享的数据模型/类型是否定义在公共位置
• 接口/抽象类是否合理使用，以支持多态替换和扩展

4. 安全审查

• 是否有 SQL 注入风险（参数化查询）
• 是否有 XSS 风险（输出转义）
• 敏感信息是否硬编码（密码、密钥、Token）
• 输入是否校验（类型、长度、格式）
• 文件操作是否有路径遍历风险

5. 测试就绪检查

• 是否为关键功能编写了单元测试
• 代码是否可测试（依赖是否可注入/可 mock）
• 注意：深度测试覆盖由 Tester 负责，此处仅检查可测试性

6. 性能与资源安全

职责边界：本节关注影响正确性和稳定性的性能问题（资源泄漏、阻塞、OOM）， §7 则关注可维护性和效率的优化建议。

• 是否有 N+1 查询问题
• 是否有不必要的循环或递归
• 资源是否正确释放（连接、文件句柄、锁）
• 大数据量场景是否有分页或流式处理

7. 代码优化与简化

职责边界：本节关注代码的可维护性和效率改进（逻辑简化、算法优化、语言特性利用）， §6 则关注影响正确性的性能缺陷。

对已实现的代码进行优化审查，按严重程度标记：

• MUST：必须修改，影响正确性或可维护性
• SHOULD：建议修改，明显改善代码质量
• NICE：可选优化，锦上添花

7a. 逻辑简化

• 多层嵌套的 if/else 是否可用 guard clause（提前返回）简化
• 复杂的布尔表达式是否可提取为命名变量或函数
• 冗长的 switch/match 是否可用映射表（dict/map）替代
• 可用三元表达式或短路求值简化的简单条件赋值

7b. 数据结构与算法优化

• 频繁查找的列表是否应改用 Set/Map 提高查找效率
• 多次遍历同一集合是否可合并为单次遍历
• 字符串频繁拼接是否应使用 StringBuilder/join
• 是否有 O(n²) 或更高复杂度可降为 O(n log n) 或 O(n)

7c. 语言特性利用

• 是否可用列表推导式/Stream API/LINQ 等替代手动循环
• 是否可用解构赋值简化多变量提取
• 是否可用可选链（?.）/ 空合并（??）简化空值检查
• 是否可用 async/await 替代回调嵌套

7d. 代码结构优化

• 过长的函数（>50 行）是否可拆分为职责单一的子函数
• 参数过多的函数（>5 个）是否可用参数对象/Builder 模式
• 深层嵌套的回调/Promise 是否可用 async/await 扁平化
• 重复的 try-catch 模式是否可抽取为装饰器/中间件

8. 编码风格一致性检查

检查基线选择：

1. 项目已有风格配置文件（.editorconfig / .eslintrc / pyproject.toml 等）→ 以配置为准
2. 变更模式下，逆向设计书已识别风格基线 → 以基线为准
3. 无明确风格时 → 按 Google Style Guide 检查（参考 copilot-instructions.md 中的「Google Style Guide 语言对照表」）

检查项：

• 新增代码的命名风格是否与项目基线一致
• 缩进、括号、空格等格式是否与项目基线一致
• 导入顺序是否符合基线规范
• 文件组织、成员排列顺序是否与项目基线一致

9. 静态检查验证

执行要求：

• 对新增/变更的代码文件执行 Linter 和静态分析工具
• Linter 结果不允许有 Error 级别问题
• 静态分析工具不允许引入新的高严重度（High/Critical）问题

工具参考：详见 copilot-instructions.md 中的「Linter / 静态分析工具对照表」。

检查项：

• Linter 执行通过，无 Error 级别问题
• 静态分析无新增 High/Critical 问题
• 若项目已有 CI 中的静态检查步骤，确认本次变更不会导致 CI 失败

审查结论

• approved：全部 9 项检查通过，代码质量达标，可提交测试
• changes_required：存在需修改的问题
  • 必须列出所有问题及修改建议
  • Developer 修改后重新自审，直到通过
• rejected：存在严重设计问题，需回退给 Architect

异常处理

• 审查结论为 changes_required 时：Developer 修改代码后重新执行自审流程
• 审查结论为 rejected 时：设置 workflow_state.json 的 status: rollback，说明原因