发布于 2026-01-05 9 阅读
0

有效代码审查指南

有效代码审查指南

有时,代码审查会让作者和审查者都感到非常沮丧。但情况并非一定要如此。

在这篇博客中,我将分享我多年来作为开发人员在代码审查过程中学到的一些经验。虽然我也会谈到一些影响代码作者的因素,但我主要还是从代码审查者的角度来撰写。

但在我开始之前,让我先讲个故事……
在我之前的团队里,我是一名开发人员,经常审查同事提交的代码请求。后来我被安排指导一个实习生团队,其中有一位实习生,无论我何时对他提交的代码请求提出意见,他都无法接受建设性的批评……至少我是这么认为的。

事实证明,我不太擅长提出建设性批评。我原以为只要冷冰冰、直截了当地指出问题就行了。这种方法对有些人有效,但对另一些人则不然。

必须采取一些措施,这让我开始思考如何进行有效的代码审查。

要批判,不要批评。

我经常听到开发者说:“我不想批评别人的代码。” “criticize”(批评)一词与“critical”(批判的)和“critique”(评论)同源。批评并非坏事。所以,下次进行代码审查时,不要把它想成是在批评,而是把它看作是对他人工作的一种真诚且有益的评价。

cri·tique /kriˈtēk/

an analysis or assessment of something, typically art, literature, or music
Enter fullscreen mode Exit fullscreen mode

请善待他人

谨慎选择措辞。使用鼓励性、合作性和启发性的语言,而不是命令式的语言。

例如,不要评论:

“Change this to use a temporary variable.”
Enter fullscreen mode Exit fullscreen mode

你或许应该这样说:

“This might be more readable if we changed this to use a temporary variable like `let`.”
Enter fullscreen mode Exit fullscreen mode

你看,这样一来讨论的气氛就变了。它让作者也参与到了对话中。谁知道呢,这简单的提问或许还能启发出更好的解决方案。

这是所有人的代码

在团队中工作时,防止不规范代码进入代码库的责任是每个人的共同责任。我给新开发者的最有价值的建议之一就是,不要把源代码看作是你的代码或他们的代码,而要看作是“我们”的代码。

在未来的某个时候,你可能会发现自己正在编写的代码,而另一位开发人员今天正在提交修改。确保代码质量达到最高标准,不仅是你的权利,更是你的义务。

让你的工具成为“坏人”

作为代码审查员,你最不想做的就是指出作者漏掉了分号或括号前的空格。这纯粹是浪费时间。你很可能在审查过程中提出更多有帮助、更有实质内容、更令人鼓舞的意见。其余的事情就交给自动化服务吧。

现代软件开发领域拥有许多工具,可以自动化以往需要人工进行的代码审查流程。许多商业和免费服务(例如 Travis CI 和 CircleCI)可以在人工干预之前执行单元测试。

如果你的组织对代码风格有规定,那就让自动化代码检查工具来帮你检查(例如,JS 项目可以使用 ESLint)。大多数这类服务对个人或开源用户都是免费的。赶紧用起来吧!

不要害怕犯错。

如果你在代码中发现任何看起来不对劲的地方,但又不太确定,请尽管提问。犯错没关系,只需留言提问即可。

“Are you sure that this shouldn’t return a PENDING status instead?”
Enter fullscreen mode Exit fullscreen mode

这促使作者重新检查自己的作品。毕竟,他们是公关稿件方面的专家。你可能会收到这样的回复:

“Yes, I’m sure. LOADED is the correct return value here.”
Enter fullscreen mode Exit fullscreen mode

这样也挺好。事实上,你刚刚学到了一些东西。但谁知道呢——你可能会收到这样的回复:

“You’re right. This should return PENDING. Good catch!”
Enter fullscreen mode Exit fullscreen mode

恭喜!在这种情况下,您刚刚发现了一个可能存在于生产环境中的漏洞!

千万不要只是草率盖章!

设想一下这样的场景:你被要求审查团队中一位备受尊敬的高级开发人员的代码。你经常向他寻求帮助和建议。“他的代码不可能出错,”你心想,“我应该直接批准它。”

还有另一种情况。上周,一位实习生或同事帮了你一个忙。现在他们急需发布最新的功能,于是来找你说:“这个拉取请求很小,我重构了一些代码,添加了一些文件,没什么大不了的。你帮我批准一下就好,可以吗?”

以上两种情况的答案都是:否!作者的技能水平和情况的紧迫性都无关紧要。你应该以同样的认真态度对待每一次代码审查。

提出有益建议

如果您要提出修改建议,请不要仅仅描述问题,或者说“这全错了”。请尽量提供实际的代码示例或相关文档的链接(如适用)。

团队合作才能让代码正常运行

开发者常常忘记,编码是一种合作。你应该给予代码作者充分的机会去实现它。不要让他们猜测你的想法。你应该始终像尊重代码一样尊重开发者,反之亦然。在组织中编写代码是一项团队运动。

记住……“CODE”中没有“I”。

==== 关注我的社交媒体账号( )@mrinasugosh ====
Dev.to:@mrinasugosh Github:@mrinasugosh Twitter:@mrinasugosh LinkedIn:@mrinasugosh


文章来源:https://dev.to/mrinasugosh/guide-to-an- effective-code-review-p15