每次代码审查的 5 条规则

代码审查是任何高效软件工程团队的粘合剂。代码审查是工程师请求将其更改合并到主开发分支的阶段。在代码审查期间，其他团队成员和高层领导可以通过 Git 和 GitLab 等版本控制系统对您的代码进行评论和建议修改。

代码审查是从单个工程师的更改到整个团队对中央代码库的贡献的转折点。

代码审查最重要的部分就在于这一转变。代码审查从一到两名开发人员的个人责任开始，最终由团队负责。一旦代码被合并，任何未来的错误或问题都不再是个人的问题，而是团队的问题。

在完全远程技术团队的时代，代码审查比以往任何时候都更加重要。花适当的时间（额外提示）审查队友的代码至关重要。拥有有效代码审查的团队能够获得诸多优势，例如遵守行业标准、更快地引导新开发人员、创建持久的软件等等。

综上所述，精通代码审查对于成为一名熟练的软件工程师至关重要。如果你像我一样，经常只是点击“批准”，那么是时候让我们一起行动起来，学习每次代码审查的五条规则了！

1. 始终分享你的想法

显而易见，参与代码审查时，你必须批判性地思考自己的想法。如果你是新手，不理解代码的功能，你需要表达你的困惑。在这种情况下，你可能需要先通过消息系统联系你的队友，然后再评论合并请求。

然而，我也见过无数高级开发人员反复寻求澄清。解决方案可能很简单，比如为某个字节操作添加注释，也可能涉及整个算法的重构。这需要团队能够理解。

想象一下，如果公司里所有的高级开发人员都决定，如果他们不理解合并请求中的代码，就什么也不说。那将是一场彻头彻尾的噩梦！这就是为什么表达自己的想法很重要——尤其是对于初级开发人员来说。如果你从不问，你就永远学不到东西！

不管结果如何，表现出你的困惑并不是一件坏事。让你的困惑得不到解答才是坏事。

2. 了解验收标准（AC）

这条规则有两个方面。首先，你显然需要了解合并请求的目的和目标。其次，你需要理解这些目标是如何通过所做的更改来实现的。理解合并请求的关键在于深入研究每一层抽象。

要了解 AC，第一步是查看与合并请求相关的工单。工单应该能够描述总体目标和实现细节。

如果您是 MR 的作者，您可以在合并请求的描述中提供更多详细信息以及任何可能遇到的问题。您甚至可以在 MR 中针对任何令人困惑的代码片段留下自己的评论，从而简化您的团队成员的工作！

相反，如果您正在审查 MR，那么理解 AC 也同样重要。您想知道哪些内容对您理解代码没有帮助吗？那就仔细查看 GitLab 上的变更列表吧。相反，您应该拉取分支本身，并根据新的变更进行修改。您可以进行实验、运行测试用例，或者检查代码库的构建或执行时间是否异常长。如果您发现任何错误或感到困惑，请务必在代码审查中留下评论，并遵循规则 1。

3. 尽量减少更改

就我个人而言，提交一个包含 1000 多行代码的合并请求真的让人很郁闷。你的团队里根本没人会去翻看这么多代码——就是这样。理想情况下，你的合并请求应该在 10 到 100 行代码之间。

虽然乍一看可能令人望而生畏，但有一些实用的步骤可以促进简洁的代码审查。第一步是确保你的 .gitignore 文件井然有序。此文件会提醒 Git 的版本控制系统注意任何应该忽略的文件。这些文件可能与你的 IDE 相关，也可能基于来自 Angular 等 Web 框架的依赖项。

另一个可以立即使用的技巧是推广每日代码审查。如果您使用 GitLab，您可以将 MR 的标题更改为以“WIP”（进行中）或“草稿”开头。这样，您的团队就可以开始检查和评论您的代码更改，但有一个限制，即您无法合并到所需的分支。

每日代码审查可让您的团队更清晰地了解每天的变更。这不仅能避免团队进行冗长的代码审查，避免无人知晓具体情况，还能提升团队对代码库的归属感和理解力。

4.明确团队标准

你知道你的团队在 Angular 中使用驼峰命名法 (camelCase) 还是下划线命名法 (underscore_case) 吗？你知道为了方便测试，函数行数是否有限制吗？你的代码覆盖率最低阈值是多少？有没有地方可以共享功能和代码？

假设您是团队的一员，您应该知道这些问题以及更多问题的答案。如果您的团队有专门的地方来记录开发最佳实践的标准，那么最佳实践就是如此。如果您没有这样的文档，请主动提出自己制作一份。

如果您花时间记录团队的标准，您将通过一份具体的文件使您的队友受益，并且您将直接了解团队的最佳实践！

5.找到你的平衡点

代码审查是一个棘手的问题。你需要在回复中做到详细，但不要像垃圾邮件一样骚扰你的队友。你需要尊重对方，但也要诚实。更重要的是，你需要积极主动，而不是被动应对。代码审查需要平衡，有些队友喜欢这种对话，而有些队友则讨厌这种对话。

但归根结底，代码审查最终还是要归结于所有权。一旦代码合并，它就属于整个团队，不应将任何责任或表扬归咎于任何个人。如何才能最好地为代码审查流程做出贡献取决于你，但如果你遵循上述任何一条规则，那么始终分享你的想法应该是你的首要任务。

所以下次你参与代码审查的时候，一定要问问题。如果你没有问题要问，那就提出建议，甚至对别人的代码提出赞美。我知道，每当有人在我的合并请求上留下反馈（好的或坏的）时，我都会比完全没有反馈感觉好得多。