TL如何进行有效的CR

用户90470668357
26 阅读5分钟

作为Team Leader，Code Review（代码审查）是我认为在技术管理和团队建设中性价比最高、收益最显著的实践之一。它远不止是找bug，更是一个知识共享、质量保障和团队建设的综合过程。

我的Code Review理念可以总结为：目标是提升代码，而非批评人；过程是相互讨论，而非单向审判。

以下是我总结的一套具体实践方法：

一、Code Review的核心目标（Why）

首先，我们必须明确CR的终极目标，这决定了我们采取何种态度和方式进行：

  1. 质量保障：发现潜在缺陷、性能问题和安全漏洞。这是最基本的目标。
  2. 知识共享与传播：让代码不再是某个人的“私有财产”。通过CR，其他成员可以了解系统的新改动，避免知识孤岛。新人也能够快速学习业务和架构。
  3. 统一规范与风格：保持代码风格和架构的一致性，提升项目的可维护性，让代码看起来像是一个人写的。
  4. 技术交流与成长： reviewer和作者都能在讨论中接触到不同的思路和解决方案，互相学习，共同进步。
  5. 建立团队责任感：代码是团队的产出，每个人都有责任和义务去维护它的整体质量。

二、Code Review的具体流程（How）

我们团队遵循一个结构化的流程，确保CR高效且有价值：

1. 前置条件：小而精的Pull Request (PR)

  • 【黄金法则】PR必须足够小。我强烈要求每次PR只围绕一个明确的功能点或修复点。
  • 好处：小的PR review起来更快（通常10-15分钟内能看完），更容易发现深层问题，reviewer也更愿意参与。一个动辄上千行的PR只会让人望而生畏，草草了事。
  • 如何做：在任务拆分时，就要有意识地将大功能拆分成多个可以独立提交的小PR。

2. 发起PR：提供清晰的上下文

  • 标题：清晰说明本次改动的目的，如“【用户管理】- 新增用户列表导出Excel功能”。
  • 描述：至关重要！ 必须包含：
    • 需求背景：为什么要有这次改动？（可以附上需求文档或Issue链接）
    • 实现方案：你是如何实现的？用文字简要描述你的设计思路。
    • 测试情况：你如何验证它是有效的？（如：本地测试了哪些场景、测试用例是什么？）
    • 截图/录屏（如适用）：非常直观，能极大提升review效率。
  • 好的描述能让reviewer快速理解你的代码，而不是像猜谜一样从头读代码。

3. Review过程：分层聚焦，有章可循 我建议reviewer按以下顺序和层次进行审查，避免一上来就纠结缩进：

  • 第一层：架构与设计（大局观）

    • 代码放在整个项目的位置是否合适？模块划分是否清晰？
    • 是否有不必要的重复代码？能否复用现有逻辑？
    • 新增的依赖是否必要？会不会引入过重的包？
    • 改动是否会影响现有功能？有没有考虑边缘情况？

  • 第二层：功能与逻辑（正确性）

    • 业务逻辑是否正确？这是核心。
    • 是否有边界条件遗漏？（如：空数据、网络异常、用户非法输入）
    • 是否有潜在的性能问题？（如：不必要的循环、重复计算、内存泄漏风险）
    • 安全考量是否到位？（如：XSS、SQL注入、权限校验）

  • 第三层：代码规范与可读性（细节）

    • 命名是否达意？（变量、函数、文件）这是提升可读性的最关键因素。
    • 代码结构是否清晰？函数是否过于冗长、职责是否单一？
    • 是否遵循了团队的ESLint/Prettier配置？（这部分应尽量靠工具自动化，不应耗费人力）

4. 评论与沟通：艺术性地提出建议

  • 对事不对人：评论的对象是“代码”，而不是“写代码的人”。使用“这块逻辑”而不是“你这里”。
  • 提出问题，也提供解决方案：
    • 不佳：“这个变量名取得不好。”
    • 更佳：“这个变量名 data 可能有点泛，如果改成 userListData 会不会更能表达它的用途？:)"
  • 多提问，少命令：
    • 不佳：“这里不能用for循环，改成用map。”
    • 更佳：“这里考虑过使用map来实现吗？或许看起来会更简洁一些，你觉得呢？”
  • 善用标记：
    • Nit：表示一个微不足道的小建议，可改可不改。
    • IMO (In My Opinion)：表示个人观点，并非强制要求。
    • 阻塞性评论：用于标识必须修改的严重问题。

5. 响应与修改：积极闭环

  • 作者：对每一条评论都必须回应。无论是修改了代码，还是进行了讨论，都要点击“Resolve conversation”。
  • 如果对评论有不同意见，鼓励在线下或评论区内进行积极友好的讨论，目标是寻求最佳方案，而不是“赢”得争论。
  • 所有阻塞性问题解决后，由reviewer或TL点击合并。

三、给Reviewer和新人的特别建议

  • 给Reviewer：

    • 轮值制度：不要总是固定一个人review，安排轮值，让每个人都有机会学习和贡献。
    • 及时响应：收到PR通知后，应尽快抽时间review，避免阻塞开发流程。
    • 敢于承认自己的盲区：如果对某块代码不熟悉，可以拉上更熟悉的同事一起看。

  • 给新人：

    • 把CR当作最好的学习机会：不仅要看别人对你代码的评论，更要积极地去review别人的代码，这是你理解业务和架构的绝佳路径。
    • 不要害怕批评：所有的建议都是针对代码的，目的是帮助你写出更健壮、更专业的代码。
    • 主动求review：写完代码后，可以主动@你的导师或TL，邀请他们进行review。

总结：打造积极的CR文化

有效的Code Review最终会形成一种强大的团队文化：

  • 它是一种协作机制，而不是一个审批关卡。
  • 它是一种 mentorship，资深的经验通过代码建议得以传承。
  • 它是一种质量习惯，将质量保障左移，问题发现得越早，修复成本越低。
avatar
文章
阅读
粉丝