代码审查的艺术：不仅仅是找 Bug

Source: Dev.to

代码审查是健康工程团队的心跳。它们是我们确保质量、共享知识和保持一致性的主要机制。然而，如果我们仅把它们视为一次捕捉 bug 的探险或风格强制执行手段，就会偏离本质——甚至会让同事感到沮丧。
让我们一起探讨如何将代码审查从例行公事提升为促进团队成长和产品稳定的强大工具。

“为什么”背后的“什么”

在查看任何代码之前，你必须了解上下文。没有描述的 PR 就像没有图例的地图。

作为作者

• 此更改的作用是什么？ – 概要
• 我们为什么要这么做？ – [链接到工单/问题]
• 我们应该如何测试？ – 截图、终端输出或测试步骤

作为审阅者

黄金法则：审查代码，而不是人

这是书中最古老的规则，却也是最难掌握的。很容易读到一行代码就想，“这很乱”。
区别细微却关键：

• “这很乱。” → 攻击作者的身份。
• “这很难理解。” → 对代码本身的中性观察。

如何表达反馈

自动化挑剔细节

这是代码审查中最大的效率提升技巧。如果你在评论缺少分号、缩进不正确或变量命名不佳，而这些本可以被 linter 捕获，你就在浪费大家的时间。

现代开发环境功能强大。使用 ESLint、Prettier、RuboCop 或 GitHub Actions 等工具自动强制代码风格。

为什么？
如果你的 CI 流水线通过，说明代码已正确格式化。不要在审查中提及它。

平衡之道：细节指正 vs. 阻塞

并非所有评论都具有相同的重要性。作为审阅者，你必须明确反馈的权重。

• 阻塞（请求更改）： 会导致生产环境崩溃、引入安全漏洞或未满足业务需求的关键问题。未解决此问题，PR 不能合并。
• 询问（问题）： “我对这种做法很好奇。你选择在这里使用 for 循环而不是 map 有什么原因吗？”——旨在邀请讨论和学习。
• 挑剔（细节指正）： “这件事非常细微，但……”或“考虑为清晰起见重命名此项”。挑剔绝不应阻止合并。如果作者有其他优先事项，可以忽略细节指正并继续。

公共表扬

代码审查评论是永久记录。如果你看到精彩的内容——对复杂问题的巧妙解决方案、写得很好的测试、出色的设计模式使用——请表达出来。积极的强化不仅仅是“友好”。它树立了标准。

• “哇，我不知道可以这样使用新的 CSS :has() 选择器。学到了！”
• “这个工具函数非常简洁且可复用。干得好。”

时效性 > 完美

我们都曾因为要完成“重要”工作而让 PR 搁置两天。与此同时，作者被卡住，上下文丢失，合并冲突也开始堆积。

• 目标是以异步为先的协作。
• 小 PR 更好：10 行的改动易于审查；2000 行的改动让人望而生畏，往往只会被略读或忽略。
• 在 24 小时内作出回应。哪怕是一句简短的 “我来处理，今天结束前审查” 也能在心理上解除作者的阻塞。

The Final Verdict

目标并不是拥有史上最干净的代码。目标是可靠地向用户交付价值，同时保持团队的快乐与协作。让我们成为那种能够解除阻碍、教导并合作的审查者，而不仅仅是批评。