如何以专业人士的身份进行评论

关于是否值得在开发流程中引入代码审查这一步骤存在一些争议，采用这种做法是否弊大于利？
我个人认为，良好的代码审查可以极大地提升我们的工作效率，无论是从团队角度，还是从职业发展和个人发展的角度。本文将向您展示如何从这一流程中获得最大收益。

哪些内容不宜评论

不仅要了解良好的实践，还要了解哪些事情需要避免。有时候，与其在流程中加入一些会破坏团队关系的步骤，不如干脆不做代码审查，而是用其他实践来代替，比如架构审查、结对编程或极限编程。

代码风格

许多人在代码审查过程中，总是纠结于尽可能多地找出“拼写”错误，争论缩进、换行符和其他语法糖的空格数。
这不是正确的做法。特定的代码风格至关重要，但无需手动完成。你需要做的（以及其他一些事情）是将这个例行且枯燥的过程自动化。正如 Rob Pike 在GopherConAU 大会闭幕演讲中所说：每种值得使用的语言都有一个标准的格式化程序。市面上
有很多针对不同编程语言的 Linter：

• Java（IntelliJ 或 Eclipse 中的内置工具）
• Python（ruff、black、pyllint、flake8）
• Go（Gofmt - 默认代码格式化程序）

您不仅可以检查代码是否遵循特定规则，还可以添加自动格式化选项。这样，大多数不一致之处都会自动修复，从而节省时间。Linter
可以自动化启动，例如，使用Python 的预提交工具，并将此逻辑集成到 GitHub PR 或新提交的工作流程中。
因此，在新的 Pull 请求被审核之前，所有代码样式问题都由作者解决。

态度

本段并非讨论“什么”，而是讨论“如何”，或者更确切地说，讨论“如何避免”代码审查。有些人将代码审查视为一项挑战，试图发现尽可能多的错误和瑕疵。即使出于良好的意图，这种做法也可能使审查过程变得过于个人化。如果工作过于贴近内心，就有可能产生负面和强烈的情绪，这可能会损害我们对同事的态度，并导致仓促或错误的决策。PR
审查不是竞争的场所，你不需要赢得一场纠错战。它是一个澄清实现中存在疑问的方面、更好地理解正在发生的事情、学习新知识或帮助代码作者发现新事物的地方。

回顾什么

可以做哪些有用的事情？在将任何损害降至最低之后，是时候专注于高效的代码审查方法了。
我下面写的所有内容将来都会对我们有用。这些做法将使你以后更容易理解和维护代码库，即使所有接触过代码库的人都遭遇了事故。

逻辑

代码审查的主要目标之一是了解这段代码到底在做什么，以及它是否符合初始任务的目标。如果你无法理解到底发生了什么，可能意味着以下几种情况：

• 代码逻辑过于复杂，或者抽象层数过多。这将导致未来添加更多逻辑或理解代码原本用途变得更加困难，从而增加修复相关问题所需的时间。
• 如果现在这段代码让您感到恐惧，想象一下，当更改此块的责任突然落在您身上时，您会有何感受，因为原作者不再可用。
• 当我们不知道代码更改的目标或原因时，如何判断代码实现是否正确？因此，在审查之前，我们需要了解代码作者的确切意图。诚然，这会增加花在别人任务上的时间，从而占用你更感兴趣的工作的时间。但软件开发关乎集体努力和沟通。随着 AI Coding Co-pilot 的发展，我们需要更频繁地阅读和审查代码。

语言使用

语言检查器 (linter) 无法解决所有关于语言结构使用不当或非惯用性的问题。有一些支持工具可以解决此问题，例如Python 的refurb。然而，这些工具通常只适用于简单的概念。
遵循良好的实践并指导你的同事也这样做很重要。例如，不要在代码中存储密码和凭证。
在人工智能工具快速发展的时代，肯定会有更好的工具来帮助我们完成这些任务。目前，我们仍然需要检查建议选项的正确性，不能盲目相信 LLM 工具提供的任何信息。我​​们当然可以向 ChatGPT 询问一些问题，但有时你只需要在编写问题之前知道要问什么。因此，知识共享仍然很有必要。

如何审查

反对代码审查的一个常见论点是，它会减慢开发进度。但修复错误并将热修复发布到生产环境也会减慢功能开发速度。我们有责任创建一个流程，将损害降至最低。虽然这取决于公司和团队结构，但该流程可以灵活调整。

• 在所有团队成员同意的情况下，就代码审查的时间范围达成一致，并建立在某些情况下跳过审查的惯例。
• 设置固定的时间段来审查他人的代码，而不是自己编写代码。这有助于管理冗长的审查队列，并让工作流程更加规范。此外，你还可以设置一些时间节点来暂停审查流程并稍事休息。
• 将你的审查分解成几个部分：从代码的高层逻辑开始，然后再到具体的函数。按提交而不是按文件进行审查也会更有效。

但如果你强烈反对代码审查实践，我又有什么资格告诉你该怎么办呢？代码审查可以用架构审查、结对编程或极限编程来代替。

就我个人而言，我的评论有一些问题。它们可能被认为非常严厉和情绪化，尽管我不是那个意思。我的评论通常都是用命令式的语气写的，缺乏礼貌和暗示性的语言。一种有助于改变这种情况的技巧是采用传统的评论方法。评论用诸如、、、或任何其他看似合适的
关键字标记。这样，代码作者就可以了解你注释的严重性，并决定哪些肯定需要更改，哪些可以保持不变。 对我来说，这个标签也像魔法一样改变了叙述。当我写下时，我会鼓励自己在文本中进一步扩展最初的想法。 你写的评论越明确、越中立，你从代码创建者那里得到的回应就越好。questionissueremarksuggestion
question

另外，如果您看到经验不足的同事实现了便捷或有效的代码，请不要犹豫，指出来。在如此狭小的反馈环路中，积极的反馈很少见。没错，人与人之间存在差异，但大多数人都希望自己的工作得到认可。

如何帮助审稿人

众所周知，很多人不喜欢审查别人的代码。我个人认为，这种期待源于这样的想法：“哦不，我得去整理别人乱七八糟的代码了”。
我们可以采取一些简单的步骤，让代码审查不再那么令人沮丧。

• 为 PR 写一个描述，这样很容易理解主要目标或内部发生的事情。
• 如果有的话，请在跟踪器中添加任务问题的链接，以便审阅者可以更深入地了解初始任务。
• 尝试将拉取请求分成逻辑提交，以便可以单独检查每个提交。
• 避免提交大型 PR。有时，可以将任务拆分成多个较小的 PR，以便于审核。其他时候，定期召开架构或代码审核会议，有助于了解当前任务并讨论后续的实施步骤。

前两点也有助于留下数字纸质记录。最后两点则为工作增添了更多结构。你甚至可以在代码编写完成后单独提交。这样，我们可以从上层抽象层进行查看，确保没有遗漏初始计划中的任何重要部分。

有时，创建拉取请求后稍作停顿，以局外人的角度快速检查一下会很有帮助。这样可以发现一些明显的错误，并快速修复。

结束

我参与代码审查的目的是为了获取知识——关于产品、新功能或编程语言。这也是一个帮助同事避免犯一些棘手错误的机会。审查过程中提出的问题可以帮助我们更好地理解代码库，或者突出需要重写和简化的地方。
随着时间的推移，当你需要重构那部分代码时，彻底的审查将非常有益。最近，我一直在重构一些相当丑陋的解决方案，这些解决方案我本来可以在半年前的代码审查阶段（合并到主分支之前的最后一道防线）坚持重新修改。但事后看来，我的预见性不够强，所以现在我付出了代价。

附言：我要感谢这篇文章的审阅者。如果没有他们的帮助，帮助文本会更糟糕，我也不会对英语有新的认识❤️