上线前不做 Code Review？你可能正在给团队埋雷！

一位前端同事花一周时间重构了一个核心组件，自测通过、性能优化、UI 完美。

上线 2 小时后，用户反馈"页面白屏"------原来漏掉了空状态处理。

紧急回滚、加班修复、产品信任受损......

而这一切，本可以在一次 15 分钟的 Code Review 中避免。

Code Review（代码审查）从来不是"找茬"，而是给前端团队上了一个最高效的质量保险。它不仅能提前拦截 Bug，更是知识共享、规范落地、新人成长的加速器。

一、什么是 Code Review

1.1 Code Review 的核心价值和目标

Code Review 翻译成中文，就是代码审查 。在前端开发过程中，它不仅是保证代码质量 的关键环节，更是团队知识共享 、技术统一 和工程规范落地 的重要机制。团队成员通过规划化的代码审查流程，能够提前发现潜在问题 ，提升代码的可以维护性。

1.2 Code Review 发生在什么时候

通常发生在：

开发者完成一个功能、修复一个 bug 或进行重构后
将代码推送到远程仓库并发起 Pull Request（PR） 或 Merge Request（MR）
在代码合并到主干分支（如 master / main）之前

二、为什么要 Code Review

代码审查真的不是为了找茬，而是为了让团队能走得更远、更稳的关键一环。想一想，如果花了一周时间，优化了各种性能，写了一大堆代码，结果上线后发现了一个严重 bug，需要紧急修复。这不仅浪费了时间，还可能影响用户对产品团队和开发团队的信任。

下面列举几个 Code Review 的作用：

提前发现缺陷
在 Code Review 阶段发现的逻辑错误、业务理解偏差、性能隐患等时有发生，可以提前发现问题
提高代码质量
主要体现在代码健壮性、设计合理性、代码优雅性等方面，持续 Code Review 可以提升团队整体代码质量
统一规范和风格
集团编码规范自不必说，对于代码风格要不要统一，可能会有不同的看法，个人观点对于风格也不强求。不过代码风格的统一更有助于提升代码的可读性及让继任者快速上手
团队共识
通过多次讨论与交流，逐步达成团队共识，特别是对架构理解和设计原则的认知，在共识的基础上团队也会更有凝聚力，特别是在较多新人加入时尤为重要

三、怎么做 Code Review

3.1 代码提交者

3.1.1 使用自动化工具

ESLint + Prettier

下面是 VS Code 关于 Prettier 的配置示例：

json 复制代码

{
    "editor.formatOnSave": true,
    "editor.defaultFormatter": "esbenp.prettier-vscode",
    "[vue]": {
        "editor.defaultFormatter": "esbenp.prettier-vscode"
    },
    "[javascript]": {
        "editor.defaultFormatter": "esbenp.prettier-vscode"
    },
    "[html]": {
        "editor.defaultFormatter": "esbenp.prettier-vscode"
    },
    "[jsonc]": {
        "editor.defaultFormatter": "esbenp.prettier-vscode"
    },
    "[json]": {
        "editor.defaultFormatter": "esbenp.prettier-vscode"
    },
    "[javascriptreact]": {
        "editor.defaultFormatter": "esbenp.prettier-vscode"
    },
    "eslint.codeActionsOnSave.mode": "problems",
    "eslint.validate": [
        "typescript",
        "javascript",
        "javascriptreact",
        "typescriptreact"
    ],
    "editor.codeActionsOnSave": {
        // 指定是否在保存文件时自动整理导入
        "source.organizeImports": "always"
    },
}

利用 Ctrl + S 自动格式化代码

Husky + Lint-staged

安装依赖

csharp 复制代码

yarn add -D husky
yarn add -D lint-staged

husky

一个为 git 客户端增加 hook 的工具。安装后，它会自动在仓库中的 .husky/ 目录下增加相应的钩子；比如 pre-commit 钩子就会在你执行 git commit 的触发。我们可以在 pre-commit 中实现一些比如 lint 检查、单元测试、代码美化等操作。

package.json 需要添加 prepare 脚本

json 复制代码

{
  "scripts": {
    "prepare": "husky install"
  }
}

做完以上工作，就可以使用 husky 创建一个 hook 了

sql 复制代码

npx husky add .husky/pre-commit "npx lint-staged"

lint-staged

一个仅仅过滤出 Git 代码暂存区文件(被 git add 的文件)的工具；这个很实用，因为我们如果对整个项目的代码做一个检查，可能耗时很长，如果是老项目，要对之前的代码做一个代码规范检查并修改的话，这可能就麻烦了，可能导致项目改动很大。所以这个 lint-staged，对团队项目和开源项目来说，是一个很好的工具，它是对个人要提交的代码的一个规范和约束。

此时我们已经实现了监听 Git hooks，接下来我们需要在 pre-commit 这个 hook 使用 Lint-staged 对代码进行 prettier 的自动化修复和 ESLint 的检查，如果发现不符合代码规范的文件则直接退出 commit。

并且 Lint-staged 只会对 Git 暂存区(git add 的代码)内的代码进行检查而不是全量代码，且会自动将 prettier 格式化后的代码添加到此次 commit 中。

在 package.json 中配置

json 复制代码

{
 "husky": {
    "hooks": {
      "pre-commit": "lint-staged"
    }
  },
  "lint-staged": {
    "*.{ts,tsx,js}": [
      "eslint --fix",
      "prettier --write",
      "git add"
    ]
  },
}

AI-Codereview-Gitlab

合并代码的时候自动触发执行基于大模型的自动化代码审查工具。可以先根据 AI 提示选择性的整改一波，然后再找评审的人 CR。感兴趣的可以点击链接了解一下。

功能如下：

🚀 多模型支持
- 兼容DeepSeek、ZhipuAI、OpenAI、Anthropic、通义千问和Ollama，想用哪个就用哪个。
📢消息即时主动
- 结果审查一键直达钉钉、企业微信或飞书，代码问题无处可藏！
📅自动化日报生成
- 基于 GitLab & GitHub & Gitea Commit 记录，自动整理每日开发进度，谁在摸鱼、谁在卷，一目了然 😼。
📊可视化仪表板
- 集中展示所有代码审查记录，项目统计、开发者统计，数据说话，甩锅无门！
🎭 评论风格任你选
- 专业型🤵：严谨严谨，正式专业。
- 论型😈：毒舌吐槽，专治不服（"这代码是用脚写的吗？"）
- 绅士型😍：温柔建议，如沐春风（"也许这里可以再优化一下呢~"）
- 幽默型🤪：搞笑点评，快乐改码（"be if-else比我的相亲经历还曲折！"）

3.1.2 发起 Code Review 时间和代码量

时间：尽量上线前一天发起评审
代码量：最好在 400 行以下。根据数据分析发现，从代码行数来看，超过 400 行的 CR，缺陷发现率会急剧下降；从 CR 速度来看，超过500 行/小时后，Review 质量也会大大降低，一个高质量的 CR 最好控制在一个小时以内。

3.2 代码评审者

3.2.1 评审时重点关注内容

作为前端评审者，可以检查以下维度：

维度	检查点示例
功能正确性	逻辑是否覆盖所有场景？边界条件（空值、错误状态）是否处理？
可读性 & 可维护性	变量/函数命名是否清晰？组件职责是否单一？重复代码是否可复用？
TypeScript 安全	是否滥用 `any` / `@ts-ignore`？类型定义是否准确？
框架规范	React：`key` 是否合理？`useEffect` 依赖是否完整？Vue：响应式使用是否正确？
样式 & UI	是否避免全局 CSS 污染？是否适配移动端？是否符合设计系统？
性能	是否有不必要的重渲染？图片/资源是否优化？第三方库是否按需引入？
可访问性 (a11y)	是否使用语义化标签？表单是否有 label？键盘导航是否支持？
安全性	用户输入是否转义？是否避免 XSS（如 `dangerouslySetInnerHTML`）？
测试覆盖	关键逻辑是否有单元测试？用户路径是否有 E2E 测试？

3.2.2 怎么写 Review 评论

首先，不要吝啬你的赞美。代码写的好的地方要表扬！！

区分优先级：

🔴 必须改：Bug、安全漏洞、破坏性变更
🟡 建议改：可读性、性能优化、最佳实践
🟢 可讨论：风格偏好（应由 Lint 工具统一）

用好 "What-Why-How" 法则

✅ 正确示范：

makefile 复制代码

What: 这里直接操作 DOM (`document.getElementById`)  
Why: 在 React 中绕过虚拟 DOM 会导致状态不一致，且难以测试  
How: 建议改用 `useRef` 获取元素引用，或通过状态驱动 UI 更新

❌ 避免：

复制代码

"这里写得不好" → 太模糊
"你应该用 Hooks 重写" → 没说明原因
"我以前都这么写的" → 主观经验，缺乏依据

总结

好的 Code Review 是团队进步的放大器，它可以：

让新人成长得更快
让系统变得更稳定
让"技术债"更少
让协作更高效

参考文章

一文梳理Code Review方法论与实践总结

感谢

文中如有错误，欢迎在评论区批评指正。
如果本文对你有帮助，就点赞、收藏支持下吧！感谢阅读。