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

代码审查是从单个工程师的变更变为整个团队范围内对中央代码库的贡献的转折点。

最重要的一段代码审查就在此过渡之内。代码审查从一两个开发人员的个人所有权开始，以团队所有权为结束。合并该代码后，任何将来的错误或问题都不是个人的问题，而是团队的问题。

在完全远程的技术团队时代，代码审查现在比以往任何时候都更加重要。花费适当的时间（小费提示）来检查队友的代码是非常重要的。进行有效代码审查的团队将获得遵守行业标准，更快地入职新开发人员以及创建持久软件的优势，仅举几例。

综上所述，在代码审查中胜任的能力对于成为一名熟练的软件工程师至关重要。如果您像我一样经常点击“批准”，那么现在是时候让我们共同行动了，为每次代码审查学习五个规则！

1.总是分享您的想法

听起来很明显，当您参与代码审查时，您必须认真地意识到自己的想法。如果您是新手并且不了解代码在做什么，则需要表达您的困惑。在这种情况下，您可能需要先通过邮件系统与队友联系，然后再对合并请求发表评论。

但是，我也看到无数高级开发人员反复要求澄清。该解决方案可能很简单，例如为某些字节操作添加注释，或者可能涉及算法的整个重构。这对团队来说很有意义。

想象一下，如果贵公司的所有高级开发人员都决定，如果他们不理解合并请求中的代码，他们什么也不会说。那将是一场完整的噩梦！这就是说出自己的想法很重要的原因，尤其是对于初级开发人员而言。如果您不问，您将永远学不会！

不管结果如何，显示您的困惑并不是一件坏事。这是一件坏事，离开你的困惑回答。

2.了解验收标准（AC）

该规则有两种方式。首先，您显然需要了解合并请求的目的和目标。其次，您需要了解所做的更改如何满足这些目标。在理解AC时，所有的工作都涉及对抽象的每一层进行深入研究。

了解AC的第一步是查看与合并请求关联的票证。从那里，票证应该能够描述高级目标和实施细节。

如果您是MR的作者，则可以在合并请求的描述中留下更多详细信息以及所有陷阱。也许您甚至会在MR上留下您自己的注释，以查看任何令人困惑的代码片段，从而使您的队友的生活更轻松！

相反，如果您正在查看MR，那么了解AC也同样重要。您是否想知道什么对您理解代码没有帮助？在GitLab上浏览变更列表。取而代之的是，拉下分支本身，并修改新的更改。试验，运行测试用例，或检查并查看代码库是否花费了异常长的时间来构建或执行。如果发现任何错误或感到困惑，请确保在代码检查中保留注释，并遵循规则1。

3.尽量减少更改

就个人而言，我发现打开一个合并请求，其中包含1,000多个代码行，这实在令人沮丧。您的团队中没有人会仔细检查这段代码。理想情况下，您的MR应该在10到100行代码之间。

虽然乍一看似乎令人生畏，但仍有一些实际步骤可鼓励进行简洁的代码审查。第一步是确保您的.gitignore文件正确无误。该文件向Git的版本控制系统发出应忽略的所有文件的警报。它们可能与您的IDE相关，也可能基于Angular之类的Web框架产生的依赖关系。

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

每日代码审查增加了您团队每天进行的更改的可见性。这样，您的团队就可以避免没有人真正知道正在发生什么的巨大代码审查，并且可以提高团队范围的所有权和对您的代码库的了解。

4.明确团队标准

您是否知道您的团队是对Angular使用camelCase还是underscore_case？您知道是否存在功能线限制以便于测试？您的代码覆盖率最低阈值是多少？有共享功能和代码的地方吗？

假设您是团队的一员，那么您应该知道这些问题的答案以及更多其他答案。如果您的团队在开发最佳实践方面有专门的位置来记录标准，那么这是最佳实践。如果您没有这样的文档，请主动提出。

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

5.找到你的平衡

代码审查是一个棘手的主题。您需要在回复中提供详细信息，但不要向队友发送垃圾邮件。您需要保持尊重，但要诚实。更重要的是，您需要积极主动-不能被动反应。代码审查是一种平衡的行为，一些队友喜欢对话而其他人则讨厌对话。

但归根结底，代码审查归结为所有权。 一旦合并了该代码，便是团队的代码，不应将任何责备或赞扬钉在一个人身上。由您自己决定如何才能最好地为代码审查过程做出贡献，但是如果您遵循上述任何规则，则始终将您的想法始终作为第一要务。

因此，下次您进行代码审查时，请提出问题。如果您没有问题要问，请提出建议，甚至是对某人代码的称赞。我知道，只要有人对我的合并请求留下反馈（好的或不好的），那我总比看不到任何反馈要好得多。