FE Team - 如何做好前端代码审查

要做好前端代码审查(Code Review),核心在于建立一套既保证代码质量,又不挫伤团队士气的流程。它不仅仅是找Bug,更是知识共享和统一规范的过程。

下面从审查的维度、流程、沟通技巧和自动化辅助四个方面来具体说明。

一、审查什么?—— 六大核心维度

审查时按优先级从高到低检查:

  1. 功能与逻辑正确性

    • 代码是否真的解决了需求?边界条件(空数据、极端值)处理了吗?
    • 异步操作(Promise、async/await)的错误捕获是否完善?
    • 是否存在常见的逻辑错误,如 == vs ===,变量提升问题?
  2. 性能与体验

    • 渲染效率:是否存在不必要的重复渲染(React的useCallbackuseMemo,Vue的computed使用是否恰当)?
    • 资源加载:图片是否懒加载?组件是否按需导入(动态import)?Bundle体积是否过大?
    • 交互流畅度:高频事件(滚动、输入)是否有防抖/节流?
  3. 可维护性与可读性

    • 命名:变量、函数、组件名是否准确表达意图(如 getUserData 优于 getData)?
    • 复杂度:函数是否过长(建议<50行)?嵌套层级是否过深?是否有违反“单一职责”原则的代码?
    • 注释:业务逻辑复杂处是否有注释?不要注释“做了什么”,要注释“为什么这么做”。
  4. 安全性(前端特有)

    • 是否存在XSS漏洞(直接使用innerHTMLdangerouslySetInnerHTML)?
    • 敏感信息(API密钥、Token)是否硬编码在前端?
    • 用户输入是否经过验证和转义?
  5. 可访问性(A11y)

    • 语义化HTML是否使用得当(button vs div模拟按钮)?
    • 图片是否有alt属性?键盘是否可操作焦点?
  6. 规范与风格

    • 缩进、引号、分号等风格问题应完全交由Prettier等工具自动处理,人工只关注工具无法判断的逻辑。

二、怎么审查?—— 高效的五步流程

  1. 审查者准备

    • 先理解PR的背景(需求链接、设计图),再读代码,不要只看代码改动。
    • 建议从整体架构开始看(文件结构、组件拆分),再深入到具体实现
  2. 小步快跑

    • 单个PR最好控制在200-400行以内。超过1000行的PR,审查效果会急剧下降,应要求作者拆分提交。
  3. 区分“必须改”与“建议改”

    • 必须改:逻辑错误、安全漏洞、严重性能问题。
    • 建议改:更好的命名方式、更优雅的实现、可选的性能优化。给建议时用“你觉得...怎么样?”。
  4. 本地验证(关键步骤)

    • 对于复杂逻辑或UI改动,一定要拉分支到本地运行测试。只看diff很难发现样式错位或交互bug。
  5. 最终确认

    • 所有“必须改”的问题解决后,再批准合并。不要累积“技术债”。

三、沟通原则—— 对代码不对人

不良的评审很容易引发对立。注意以下表达方式:

  • :“你这里写错了。” “你怎么不用XXX设计模式?”
  • :“这个变量名data有点模糊,改成 userProfile 会不会更清晰?” “考虑到后续可能需要扩展,这里用策略模式是不是更好?可以一起讨论下。”

核心建议:对于可读性、风格类问题,优先通过ESLint/Prettier等规则固化,不要让人工反复争论。

四、善用工具—— 自动化做脏活累活

在人工审查前,先用自动化工具过滤掉低级问题:

工具 作用
ESLint + Prettier 自动化检查语法错误、风格统一
TypeScript 强类型系统能在编译时避免大量错误
Husky + lint-staged Git提交前自动检查和格式化代码
SonarJS 扫描代码坏味道、重复代码、潜在Bug
Chrome Lighthouse 审查可访问性、性能、SEO建议

五、建立团队共识

  1. 制定并文档化规范:以项目根目录的.eslintrc.prettierrc和一份 CONTRIBUTING.md 文档为准。
  2. 定期复盘:每月拿出半小时,回顾过去一个月CR中反复出现的问题,更新规范。
  3. 新手正向引导:对刚入职同事的PR,多给鼓励式建议,少用“必须改”。

一个高效的审查清单(可直接用于团队)

最后,记住一个好公式:

好的代码审查 = 自动化工具(守底线) + 合理的流程(保效率) + 共情的沟通(促协作)

posted @ 2026-05-10 15:20  箫笛  阅读(14)  评论(0)    收藏  举报