【第3499期】代码评审的理念

正文

请到「今天看啥」查看全文

但总体而言，这种环境促使我们形成了每隔几天就提交一些小而易读的代码审查请求（PR）的节奏。那是我一生中工作效率最高的时期。我坚信我们找到了代码审查的正确方式。

不过，这样的协作氛围其实非常依赖团队结构。当你拥有一个长期稳定、互相了解的小团队时，信任的积累是 “自带的”。但现实中，大多数工程师所在的团队更复杂：可能有远程成员、临时组建的小项目组、不同地区或公司之间的外包协作。

在这种情况下，信任感需要 “主动构建”。如果你是新加入的成员，可以从持续响应 PR、认真写注释、在 Slack 或飞书中主动澄清观点开始，让大家感受到你 “不是来挑战权威，而是来合作”。而对于老成员来说，也需要有意识地引导新同事融入团队文化，而不是默认他们什么都应该懂。

特别是在远程办公或跨时区协作中，沟通的 “同步性” 不再可靠，清晰、结构化的书面表达、及时的异步反馈，变得比语气更重要。学会写好 PR 描述、留言时写出动机和背景，其实是远程评审的核心技能。

直到我们招了一个新成员，信任关系迅速瓦解。我 评审 他的一个 PR 时提出了很多批评，对他来说这些意见和他的修改无关，还带点居高临下；后来他评审我的一个 PR 时，因一个不太重要的文档问题卡住了我。我当时觉得他吹毛求疵。之后我们互相不再标记对方为评审人。直到某天我们决定开个电话聊聊，把心里的话说开了，关系虽然恢复了一点，但再也没回到以前那种默契。

这件事让我意识到，我们当时的评审文化并不是普适方案，只是在一个长期稳定的小团队中自然形成的。我在这之外其实并没有真正掌握建立良好评审文化的方法。

如果你没有一个不变四年的小团队，怎么去建立信任、高效的协作节奏？我目前还没做到，但以下几点是我接下来会坚持的实践方向。

基础工作：自动格式化 & 静态检查

尽可能将一些评审工作自动化，交给 CI 处理。

我曾经浪费了很多时间在 PR 里评论：“请给函数添加类型注解，我才能理解参数含义。” 其实只要花一天时间，就可以在所有新项目里通过 linter 强制执行这个规则。

(1) 为理解而评论

默认情况下，评审人一开始并不理解改动内容。随着你逐渐阅读 diff，你对它的理解也在逐步建立。

当你的工作被一个只是一知半解的人评判时，这真的很让人恼火！我认为正是这种 “被误解地批评” 的感觉，让人产生防御心。

作为评审人，你可以尽量读完整个 diff，再开始评论，但那会很累。而且，可读性本该是作者的责任。你的主要目标应该是帮助作者让代码更容易被他人理解。让代码更易懂，其实和直接找 bug 一样有效。

【早说】评审机制

请到「今天看啥」查看全文