代码审查是否已经落伍？深入解析最新最佳实践！ _代码审查

译者 | 刘汪洋

反馈就像一块牛排 - 如果太生，没有人喜欢；但如果过熟，难以下咽。

(ChatGPT)

文章插图
通过不断审查他人代码，你不仅可以提升自己的技能，对你的职业发展也有很大好处。不仅可以帮助别人成长，也能为你所在的公司创造价值。
在本文中，我们要探讨代码审查的好处，以及一些在审查过程中应遵循的原则，如与同事的互动等。
名词解释代码审查：对作者代码分支的书面反馈过程。
Pull Request：Github 上用于展示新分支与主分支之间差异的术语，你可以在其中发表评论。
代码审查？是否已经过时？
如果你是一名敏捷开发者，你可能会怀疑代码审查的必要性，可能会有这样的观点：

我们如果一直进行结对编程，就没有必要再做正式的代码审查了。因为这样就不会有一个“陌生人”在你已经完成所有工作并花费了大量时间之后，才来评价你的代码，而他对你的代码的上下文可能一无所知。
代码的正确性已通过 TDD （测试驱动开发）方法进行了验证。
语法和风格可以由 linter 自动检查。

这些考虑无疑是有道理的。
但：

代码审查本质上是一种团队成员之间和不同团队之间的知识共享机制。

代码审查的好处一旦你不再把代码审查视为负担或者无聊的任务，你会发现，代码审查能带来很多好处。
为了支持这个观点，我提出了一个用于在同事的 pull request 中提供反馈的框架。
W3H：即“为什么（why）、做什么(what)、何时(when)以及如何做(how)”
尽管我并非缩写词的狂热爱好者，但我还是创建了一个 W3H 的缩写词，旨在概括我们在接触新的代码时所需要考虑的关键问题。
为什么(why)代码审查可能是由于你的组织内部的 CI/CD 流程强制推动的，因此，“为什么”的问题可以简单地回答为“因为我被指示要这样做” 。
然而，有更有价值的问题值得我们思考：“为什么代码审查如此重要？”或者说，“为什么我应该主动去进行代码审查？”
首先，代码审查对审查者和代码作者来说都是一个提升自我技术水平的好机会。代码作者可以得到有效的反馈和建议，有助于其技术水平的提升。审查者则可以从中学习新的编程技巧和习语。
此外，作为开发者，你还可以：

更快地理解新的代码库。
有更多的机会进行团队内交流，尤其在团队成员分布在不同地理位置的情况下。
发现其他团队工作中可能存在的重复问题。
在代码库中推动最佳实践的实行。
提升你在其他工程师和管理者心中的专业形象和知识储备。
提高你的沟通技巧（我们将在“如何”一节中详细讨论）。
结识新朋友！

做什么(what)我们如何定义“优秀的”代码？
【代码审查是否已经落伍？深入解析最新最佳实践！】在对别人的代码发表任何评价之前，你需要明确好代码的基本标准。
以下是一些通用的原则：

代码中不应存在明显的错误，例如变量名的拼写错误，或者不规范的代码缩进。当我审查一个我并不太熟悉的模块的 PR 时，我通常会从这些基础的检查开始。
无论代码完成的任务有多复杂，代码本身都应该是结构清晰和易于理解。
代码中不应存在严重的性能问题，例如，一个可以通过一次循环读取完成的列表被多次读取。这在移动应用开发中尤其重要，因为这可能导致不必要的电池电量消耗。
PR 只应该修改完成任务（新特性，错误修复，重构）所必需的文件。这不仅可以减轻审查者的工作压力，而且如果出现了重大的生产问题，也会更容易找到问题并进行回滚。如果代码涉及多个方面，建议作者将其拆分为两个或更多的审查。
清晰理解更改的目标。PR 的描述应该清晰地说明更改的内容或者链接到包含详细信息的外部文档（例如 Jira 或 Trello 工单）。理解了更改的目标后，再检查更改是否满足了预设的要求。
如果 PR 是用来修复一个错误，修复方案还应该包含一组测试，这样可以针对特定的场景进行测试，并避免相同的错误在未来再次发生。

何时(when)你应该在什么时候进行代码审查？
我通常每周安排两次，每次约 30 分钟的时间，审查其他团队的 PR，这些与我自己团队的工作并无直接关联。如果我团队有紧迫的项目截止日期，可能我会减少审查的时间；如果是工作相对清闲，并且有一些评论引发了大量的讨论，我可能会投入更多的时间。