Commandgeneral

/review Command

对以下代码进行全面审查：$ARGUMENTS

View Source

代码审查

对以下代码进行全面审查：$ARGUMENTS

审查维度

1. 功能正确性 ✅

  • [ ] 代码实现了预期功能吗？
  • [ ] 所有边界条件都处理了吗？
  • [ ] 错误处理是否完善？
  • [ ] 业务逻辑是否正确？

2. 代码质量 📝

  • [ ] 代码是否易于理解？
  • [ ] 命名是否清晰表达意图？
  • [ ] 是否有重复代码？
  • [ ] 函数/类是否遵循单一职责？
  • [ ] 抽象层次是否合适？

3. 测试覆盖 🧪

  • [ ] 是否有对应的测试？
  • [ ] 测试是否覆盖主要场景？
  • [ ] 测试是否包含边界条件？
  • [ ] 测试是否易于理解和维护？

4. 性能考虑 ⚡

  • [ ] 是否有明显的性能问题？
  • [ ] 算法复杂度是否合理？
  • [ ] 是否有不必要的数据库查询？
  • [ ] 是否有内存泄漏风险？

5. 安全性 🔒

  • [ ] 是否有 SQL 注入风险？
  • [ ] 是否有 XSS 攻击风险？
  • [ ] 敏感信息是否得到保护？
  • [ ] 权限检查是否完善？

6. 可维护性 🔧

  • [ ] 代码结构是否清晰？
  • [ ] 依赖关系是否合理？
  • [ ] 是否容易扩展？
  • [ ] 文档是否完整？

审查检查清单

代码风格

命名规范:
  - [ ] 变量名描述性且一致
  - [ ] 函数名以动词开头
  - [ ] 类名使用名词
  - [ ] 常量使用大写蛇形

代码组织:
  - [ ] 导入语句有序分组
  - [ ] 相关代码放在一起
  - [ ] 公共方法在前，私有在后
  - [ ] 辅助函数适当提取

最佳实践

DRY (Don't Repeat Yourself):
  - [ ] 无重复代码块
  - [ ] 共同逻辑已提取
  - [ ] 配置集中管理

SOLID 原则:
  - [ ] 单一职责 (S)
  - [ ] 开闭原则 (O)
  - [ ] 里氏替换 (L)
  - [ ] 接口隔离 (I)
  - [ ] 依赖倒置 (D)

防御性编程:
  - [ ] 输入验证
  - [ ] 空值检查
  - [ ] 类型检查
  - [ ] 边界处理

具体审查点

JavaScript/TypeScript

// ❌ 不好的例子
function calc(x, y) {
  return x * 0.1 + y * 0.2;
}

// ✅ 好的例子
const TAX_RATE = 0.1;
const SERVICE_FEE_RATE = 0.2;

function calculateTotalCost(baseCost, serviceCost) {
  const tax = baseCost * TAX_RATE;
  const serviceFee = serviceCost * SERVICE_FEE_RATE;
  return baseCost + tax + serviceCost + serviceFee;
}

错误处理

// ❌ 静默失败
try {
  doSomething();
} catch (e) {
  // 忽略错误
}

// ✅ 正确处理
try {
  doSomething();
} catch (error) {
  logger.error('操作失败', {
    error: error.message,
    stack: error.stack,
    context: { /* 相关上下文 */ }
  });
  
  // 适当的错误恢复或向上传播
  throw new BusinessError('操作失败，请重试', error);
}

异步处理

// ❌ 回调地狱
getData(function(a) {
  getMoreData(a, function(b) {
    getMoreData(b, function(c) {
      console.log(c);
    });
  });
});

// ✅ 使用 async/await
async function fetchAllData() {
  try {
    const a = await getData();
    const b = await getMoreData(a);
    const c = await getMoreData(b);
    return c;
  } catch (error) {
    handleError(error);
  }
}

审查反馈模板

严重问题 🔴

**[严重]** 问题描述

**位置**: `文件名:行号`

**问题**: 
[详细描述问题]

**影响**: 
[说明可能的后果]

**建议方案**:
​```language
// 建议的代码
​```

**参考**: [相关文档或最佳实践链接]

一般问题 🟡

**[建议]** 改进建议

**位置**: `文件名:行号`

**当前代码**:
​```language
// 当前实现
​```

**建议改进**:
​```language
// 改进后的代码
​```

**理由**: [解释为什么这样更好]

优秀实践 🟢

**[赞]** 优秀实践

**位置**: `文件名:行号`

做得很好的地方：
- [具体的优点]

这种做法值得在项目中推广。

审查工具命令

自动化检查

# 运行所有自动化检查
npm run lint
npm run typecheck
npm test
npm run test:coverage

# 检查代码复杂度
npm run complexity

# 安全漏洞扫描
npm audit

Git 相关

# 查看改动的文件
git diff --name-only

# 查看具体改动
git diff [文件名]

# 查看提交历史
git log --oneline -10

审查心态

✅ 正确的审查态度

  1. 建设性 - 提供解决方案，不只是指出问题
  2. 具体 - 给出具体的代码示例
  3. 谦虚 - 可能是你理解有误
  4. 学习 - 从他人的代码中学习
  5. 赞赏 - 认可做得好的地方

❌ 避免的行为

  1. 人身攻击 - 评论代码，不评论人
  2. 吹毛求疵 - 关注重要问题
  3. 个人偏好 - 区分规范和偏好
  4. 延迟回复 - 及时提供反馈
  5. 模糊评论 - 要具体和可操作

审查优先级

P0 - 必须修复

  • 🐛 Bug 和逻辑错误
  • 🔒 安全漏洞
  • 💥 会导致系统崩溃的问题
  • 📊 严重的性能问题

P1 - 强烈建议

  • 📝 违反团队编码规范
  • 🔄 明显的代码重复
  • 🏗️ 架构问题
  • 🧪 缺少关键测试

P2 - 建议改进

  • ✨ 代码可读性改进
  • 📚 文档补充
  • 🎨 代码风格统一
  • ⚡ 性能优化机会

审查后行动

作者响应

  1. 理解所有反馈
  2. 询问不清楚的地方
  3. 解释设计决策（如需要）
  4. 实施必要的修改
  5. 重新请求审查

审查者跟进

  1. 验证修改是否完成
  2. 确认问题是否解决
  3. 批准或继续讨论
  4. 记录学到的经验

持续改进

团队学习

  • 定期分享审查中发现的模式
  • 更新团队编码规范
  • 创建代码示例库
  • 组织技术分享会

个人成长

  • 记录常见问题
  • 学习新的最佳实践
  • 提升审查技能
  • 分享知识和经验

记住

"代码审查的目的不是找茬，而是：

  • 🎯 确保代码质量
  • 📚 知识共享
  • 🤝 团队协作
  • 📈 持续改进"

好的代码审查能让整个团队受益，不仅提升代码质量，更重要的是促进知识传播和团队成长。