没有标准的代码设计

每个团队都应采用每个人都同意的代码格式标准（编程标准，样式指南）。它包括命名约定，文件夹结构，代码格式以及一系列最佳实践，例如单元测试，验证等

。缺少明确的标准和约定会迫使每个开发人员随意编写代码，从而导致代码纠纷。 -评论。如果您看到有关格式，命名约定等的大量评论，那么该讨论一个通用标准了。

您的团队可以制定自己的建议集，也可以从其他公司的知名建议开始。这是谷歌的一个例子。

没有使用自动检查

采用代码标准后，请学习工具以验证是否符合这些标准。对于几乎所有语言，都有一些用于格式化代码，lints和其他实用程序的工具，您可以在提交并在CI / CD系统中注册之前将其置于钩子中。

这些工具检查代码是否符合设计标准，并将违规情况通知作者。作者有机会在发送池请求之前解决问题，从而大大降低了噪音。自动通过的检查越多，审阅者就必须花费更多的时间来处理更严重的问题，例如体系结构中的缺陷，实现方面的缺陷等。

程序员不会独立分析其代码。

在联系同事进行代码审查之前，作者必须先审查自己的更改。这就像在将信件发送给收件人之前检查信件的文本是否有错字和错误。

在实践中，验证您自己的代码具有挑战性，因为您倾向于下意识地跳过缺陷。以下是一些提高自我分析质量的方法：

在不指定审阅者的情况下提出合并请求，并在几个小时后返回以重新查看您的修改。
抑制您自然而然地浏览变化的趋势，而是有目的地逐行查看它们。
请遵循清单：代码是否符合设计标准？是否满足所有业务要求？是否针对所有可能的用例进行了测试？等等

大量的池请求

对池请求的注释数量与其中包含的更改数量成反比。即，大PR→很少评论，小PR→许多评论。

事实是，审阅者没有仔细研究大型池请求，而是倾向于滚动浏览大型池请求以更快地完成工作。这与代码审查的目的背道而驰。有时相反的情况发生在作者连续许多天未收到任何评论的情况下，因为审阅者担心开始审阅过多的PR。

将池请求分成彼此分开有意义的小段。因此，您将有助于正确，快速地考虑它们。

模糊池请求

通常会向您提供一个含糊不清的描述或根本没有描述的合并请求。审阅者应了解更改的含义，并尝试回想在会议某个地方或在错误跟踪器中讨论过的任务。因此，最好向PR提供支持信息：

它包含哪些变化
以什么文件开头
链接到错误跟踪器中的任务
屏幕截图（如果这是某种视觉变化）

此信息将为审阅者提供更好的上下文，从而加快代码审阅速度。

缺少代码审查的截止日期

永久延长代码审阅的一种方法是不为审阅者设置任何截止日期。定义合理的期限，例如：

审核代码应在发送池请求后的48小时内完成。
对于修补程序，期限为30分钟。

谢谢阅读！:)

如何加快代码审查