代码评审与质量门禁

代码评审的常见痛点

在多人协作或自动化代码生成场景中，代码评审常陷入三个困境：

• 维度缺失：仅检查功能正确性，忽视可读性、架构一致性和安全性
• 标准模糊：评审意见依赖个人经验，合并决策缺乏统一依据
• 过度苛责：追求「完美代码」而阻塞实际能改善代码库的变更

五维度系统化评审

该技能通过结构化流程覆盖五个核心维度：

1. 正确性

- 验证代码是否实现声明的功能
- 检查边界条件（null/空值/边界值）和错误处理路径
- 确认测试覆盖关键场景而非仅 happy path

1. 可读性与简洁性

- 命名是否符合项目规范（避免 temp/data 等无上下文名称）
- 控制流是否直白（拒绝嵌套三元表达式和深层回调）
- 是否存在冗余代码（1000 行能简化为 100 行即为失败）

1. 架构一致性

- 变更是否符合系统当前设计模式
- 依赖管理是否避免隐式耦合或循环依赖
- 模块边界是否清晰且可测试

1. 安全性

- 输入验证是否防御注入攻击（SQL/XSS/命令注入）
- 敏感数据是否避免日志泄露
- 错误信息是否安全（无堆栈跟踪或内部细节）

1. 性能

- 是否存在 N+1 查询或资源泄漏
- 缓存机会是否被识别和利用
- 阻塞操作是否可异步化

质量门禁与审批原则

评审结果通过严格门禁决定合并：

• 所有五个维度均通过评审
• 无关键缺陷或安全漏洞
• 变更提升整体代码健康度
• 遵循项目约定和测试规范

审批核心逻辑：只要变更明确改善代码库且符合规范，即使不完美也应批准。避免因「不是自己写的」而阻塞改进——完美代码不存在，持续优化才是目标。