⚡

CodeReviewBestPractices CodeReviewBestPractices

系统化代码审查的专家级框架，旨在提高代码质量，防止错误，并在团队间共享知识。

测试 0 次安装 0 次浏览 更新于 3/5/2026

name: 代码审查最佳实践 description: 专家级框架，用于系统化的代码审查，以提高代码质量，防止错误，并有效地在团队间共享知识。

代码审查最佳实践

概览

代码审查是对源代码的系统性检查，旨在发现错误，提高代码质量，执行标准，并在团队间共享知识。有效的代码审查能够在早期捕捉缺陷，防止技术债务积累，加速新成员入职，并通过对建设性反馈的协作学习来促进。

为什么这很重要

  • 早期捕捉错误：审查在问题进入生产环境之前识别问题，减少事故成本和用户影响
  • 提高代码质量：一致的反馈执行编码标准，可维护性和最佳实践
  • 加速新成员入职：新团队成员通过审查他人的代码学习代码库架构和模式
  • 共享知识：审查分散了关于系统设计，实现细节和架构决策的知识
  • 防止技术债务：早期识别和解决代码问题，防止债务积累
  • 建立团队文化：定期的建设性反馈创造了协作学习环境，并随着时间的推移提高代码质量

核心概念

1. 审查原则

有效审查的基础指导方针：

  • 审查代码，而不是作者：关注代码行为和质量，而不是个人偏好或编码风格
  • 及时性：尽可能在24-48小时内审查拉取请求；较小，频繁的审查比大型，延迟的审查更好
  • 全面但实际：平衡全面审查与开发速度；关注正确性，安全性和关键问题
  • 共享知识：将审查用作教学机会；解释建议背后的“为什么”；从你审查的代码中学习
  • 保持审查小：理想的PR大小是200-400行代码；大型PR应该被分割
  • 建设性：给出具体，可操作的反馈和示例；使用问题而不是陈述；承认好的工作

2. 审查流程

进行审查的系统化工作流程：

  • 审查前准备：作者自检代码，检查清单，准备描述和上下文
  • 审查执行：审查者检查代码，识别问题，使用结构化方法提供反馈
  • 反馈交付：使用评论模板和标记；回应所有评论；跟进行动项目
  • 审查后行动：作者处理反馈，更新PR，获得批准后合并

3. 审查类别

在审查期间识别的代码问题类型：

  • 代码质量：命名约定，代码风格，重复，复杂性，可维护性
  • 安全漏洞：输入验证，身份验证，授权，SQL注入，XSS，敏感数据暴露
  • 性能问题：数据库查询（N+1），算法复杂性，不必要的计算，内存泄漏
  • 测试覆盖：缺少单元测试，边缘情况，不稳定测试，测试质量
  • 文档：缺少API文档，过时的注释，不清晰的代码

4. 查看内容

在审查期间识别的特定模式和问题：

代码质量：

  • 魔术数字和不清晰的值
  • 长函数和方法
  • 糟糕的命名约定
  • 代码重复（DRY违规）
  • 不一致的格式化
  • 缺少错误处理
  • 紧密耦合和缺乏抽象
  • 违反SOLID原则

安全：

  • SQL注入漏洞
  • XSS和CSRF漏洞
  • 缺少身份验证/授权
  • 硬编码的秘密或凭据
  • 敏感数据在日志或错误消息中
  • 不安全的数据存储或传输
  • 缺少输入验证或清理

性能：

  • N+1数据库查询问题
  • 缺少数据库索引
  • 低效算法（O(n²)而不是O(n log n)）
  • 不必要的循环或计算
  • 没有缓存的好处
  • 大型响应负载没有分页或字段选择
  • 异步上下文中的同步I/O操作

测试：

  • 缺少新功能的测试
  • 测试实现而不是行为
  • 脆弱或不稳定的测试
  • 缺少边缘情况覆盖
  • 总是通过的测试（假阳性）
  • 没有API的集成测试
  • 糟糕的测试数据管理（硬编码数据）

5. 反馈指南

提供建设性反馈的原则：

建设性：

  • 使用“考虑…”而不是“你应该…”
  • 提供具体的例子和代码
  • 解释建议背后的“为什么”
  • 在建议更改时提供替代方案
  • 承认好的工作和明智的决策

具体：

  • 指向代码的确切行或部分
  • 引用特定文件或函数
  • 使用精确的术语（例如，“SRP违规”而不是“紧密耦合”）
  • 包括显示问题和解决方案的代码示例

使用问题格式：

  • “你有没有考虑过X？”而不是“不要使用X”
  • “你认为Y怎么样？”开放讨论
  • “Z在这里工作得更好吗？”探索替代方案
  • 在要求不明确时提出澄清问题

分类反馈：

  • 使用前缀或标签对评论进行分类
  • [Blocking] - 必须在合并前修复
  • [Critical] - 安全或正确性问题
  • [Suggestion] - 改进想法
  • [Nitpick] - 次要风格问题
  • [Question] - 需要澄清

回应所有评论：

  • 确认每个审查评论
  • 如果你不同意，提供技术理由
  • 如果你同意，表达支持
  • 回答审查者的问题
  • 根据反馈更新PR

快速开始

  1. 准备审查：本地运行linting和测试；使用清单自检代码；准备清晰的PR描述，包括上下文，要求和屏幕截图
  2. 请求审查：根据专业知识分配审查者；通过通信渠道通知团队；链接相关的问题和文档
  3. 进行审查：系统地使用类别（代码质量，安全性，性能，测试）检查代码更改；提供具体，可操作的反馈和示例
  4. 处理反馈：回应所有审查者评论；实施请求的更改；提出澄清问题；承认好的工作；完成后更新PR
  5. 合并或请求更改：如果获得批准，使用适当的策略合并PR；如果请求更改，进行更新并重新请求审查
## PR描述模板

## 摘要
[这个PR做什么以及其目标的简要描述]

## 变更类型
- [ ] 错误修复（非破坏性变更，修复问题）
- [ ] 新功能（非破坏性变更，添加功能）
- [ ] 破坏性变更（修复或功能导致现有功能变化）
- [ ] 文档更新

## 变更内容
- [ ] 添加了X组件/模块
- [ ] 在Z模块中修复了Y错误
- [ ] 更新了W的API端点
- [ ] 重构X以改进Y

## 测试
- [ ] 为新功能添加/更新了单元测试
- [ ] 集成测试通过
- [ ] 完成手动测试
- [ ] 覆盖边缘情况

## 相关问题
关闭#123，与#456相关

生产检查表

  • [ ] PR描述完整，包括摘要，变更类型和变更列表
  • [ ] 引用了相关问题或工单
  • [ ] 代码已由作者自检
  • [ ] 所有本地测试通过（单元测试，集成测试，lint，类型检查）
  • [ ] 代码遵循项目风格指南
  • [ ] 安全审查完成（无漏洞，适当的认证/授权）
  • [ ] 性能审查完成（无N+1，高效算法，适当的缓存）
  • [ ] 如果更改影响API文档，README或架构，则文档已更新
  • [ ] PR大小适当（200-400行）
  • [ ] 分配并通知审查者
  • [ ] 建立审查时间表（目标24-48小时进行初次审查）

反模式

  1. 个人评论：批评人而不是代码（“你总是写混乱的代码”与“这个函数可以简化”）
  2. 吹毛求疵：过度关注次要的风格问题，而忽略实质性问题（间距，命名偏好）以牺牲重要问题
  3. 模糊反馈：提供无帮助的评论，如“这是错误的”或“我不喜欢这个”，没有具体解释或替代方案
  4. 无明确理由的阻塞：在没有明确解释需要修复什么以及为什么的情况下拒绝或阻塞PR
  5. 跳过审查：由于时间压力或熟悉作者而未经审查就批准PR
  6. 不回应评论：未能确认审查者反馈或回答问题，阻碍合并过程
  7. 过度评论：将文章作为评论而不是简洁，专注的反馈
  8. 匆忙审查：由于时间压力而进行表面审查，错过了重要问题
  9. 有偏见的审查：基于作者而不是代码质量批准或拒绝
  10. 无上下文审查：在不了解更广泛的上下文，架构或要求的情况下审查代码更改

集成点

  • 代码审查平台：GitHub PRs，GitLab MRs，Bitbucket PRs，Azure DevOps用于审查工作流程
  • 代码分析工具：SonarQube，CodeQL，Coverity，Fortify用于自动化质量检查
  • 文档平台：Confluence，Notion，GitHub Wiki用于审查清单和指南
  • CI/CD集成：GitHub Actions，GitLab CI，Azure Pipelines，Jenkins用于自动化检查
  • 通信工具：Slack，Microsoft Teams，Discord用于审查者通知和讨论
  • 项目管理：Jira，Azure DevOps，Linear，Shortcut用于跟踪与审查相关的任务
  • 架构审查：architectural-reviews用于设计相关的代码审查
  • 安全审计：owasp-top-10用于以安全为重点的审查
  • technical-debt-management用于识别和管理审查期间发现的债务

进一步阅读