很长时间以来，我一直对代码审查问题感兴趣。 很多时候会出现一个或另一个问题，无论是代码质量还是团队中的气候问题。 实际上，代码审查（如果不是唯一的话）是开发团队中发生冲突的最重要场所之一。
最近，在为下一版Zinc Prod播客做准备时，我发现Google已发布了《代码审查》实践准则，其中充斥着宝贵的思想。 所有的材料都非常丰富，无法写成一篇文章，因此我将尝试突出最有趣的想法（对我而言）。
所以走吧
原始文章中使用的术语：
CL-变更清单。 但通常称为合并请求或合并请求，因此在本文中我将使用缩写MR
LGTM-对我看起来不错。 简而言之，当他们按下“批准”按钮时。 我将使用“ aprov”一词，这对人们来说更容易理解。
理想先生
在实践中，考虑MR时可能会遇到各种极端情况。 整个团队中的某人zadalivaet都发表了评论，直到一切都变得微不足道，得到纠正，然后有人再看一下逻辑并按下“ upruv”。
一个有趣的想法写在Google文档中。 MR不应是完美的，但应改善代码库。 也就是说，随着每次引入的更改，代码将变得越来越好。 而且，如果MR增加了很多好处，那么您就不必为小事找错了； 更快地获得改善的利润更高。
没有MR应该会使代码更糟。 唯一的例外是，如果MR是某个问题的紧急解决方案。
自由发表评论
尽管您无法摆脱琐事，但是您可以将这些琐事自由地写到至少每一行。 与上一段的矛盾很容易解决：审阅者在英语中给trifles和nit-picking加上前缀“ nit：”。 nitpick（挑剔）。 不必修正这些注释，但是，MR的作者可能想更正某些内容，或者即使没有，也要考虑到将来的一些观点。
关于个人喜好的事实
几乎总是基于最佳实践的标准软件设计原则胜过棘手的自行车。 因此，应优先考虑它们。
如果您可以应用几种标准方法，则由作者决定。
直接报价以获得更好的理解：
软件设计方面几乎从来都不是纯粹的样式问题，也不是个人喜好。 它们基于基本原则，应该权衡这些原则，而不仅仅是个人意见。 有时有一些有效的选择。 如果作者可以证明（通过数据或基于可靠的工程原理）几种方法同等有效，那么审阅者应接受作者的偏爱。 否则，选择取决于软件设计的标准原理。
如果审稿人和MR的作者不同意
首先是试图在有关MR的评论中达成共识。 如果这不起作用，则进行个人讨论。 如果您仍未达成共识，请吸引团队成员。 但最重要的是，由于两个人的意见分歧，MR不应长时间停留。
在评论中讨论->亲自讨论->在团队中讨论->继续前进
MR检查速度
速度非常重要。 如果您每隔几天发表一次评论，那么MR的作者将抱怨他们发现他有问题，并阻止了他的工作。
如果快速检查了MR，那么任何评论都不会成为大问题-毕竟，这里将检查其修复，然后任务将继续进行。
Google建议您不要专心于自己的任务，但是如果您分心，则请查看是否有需要修改的地方。 例如，他从午餐回来了-他修改了。 上班-修订。 等等
MR查看顺序
首先，您需要从整体上了解MR。 是否有必要，代码是否在正确的位置（或者应该在单独的库中），是否存在全局问题？
即 如果代码不存在或根本不存在，则查看一些实现细节是没有意义的。
通常，查看顺序很重要，以便尽快向作者提供反馈（请参见上一段）。
当您从整体上看待MR时，您需要浏览主要文件，即 检查最重要的事情（如果不清楚最重要的事情，可以询问开发人员）。
同样，任何问题都应立即报告，即使您尚未检查MR并决定以后再进行一般检查。
接下来，您需要选择一个逻辑顺序来查看其余文件。 请勿跳过任何文件。
查看时要寻找什么
- 代码设计合理
- 从此代码的用户角度，无论他们是谁，都可以很好地实现此功能。
- 外观（如果有）应该很好
- 考虑了并行编程的所有细微差别（如果有）。
- 代码未重新设计
- 开发人员不会过度劳累：您不需要编写可能需要或不需要的代码
- 该代码具有测试
- 测试设计合理
- 名称（所有内容）都经过精心挑选
- 对代码的注释是可以理解和必要的。 他们必须解释为什么这样做，而不是如何做到。
- 添加了文档。
- 该代码与样式指南相对应。
MR太大
必须要求太大的MR才能分解。 这几乎总是可能的。
如何在代码审查中写评论
- 您需要有礼貌，而不要变得个性。 讨论代码，而不是编码器。
- 不仅发布更正指令，还解释了为什么需要修复它们。
- 保持平衡：找出问题并推动开发人员，以便他自己了解如何最好地解决该问题； 或立即发布现成的解决方案。 第一个开发开发者（战略利益），第二个改进并加速MR（战术利益）。
- 如果审阅者在某些时候不理解代码，并要求作者解释什么，那么最好的答案就是更改代码。 这样就可以毫无疑问地从代码中清除一切。
如果您不同意您的意见
有必要详细了解。 也许您听不懂，要求更多信息。 也许相反。 无论如何，通常只有在双方进行了两轮解释之后才能理解。
担心作者MR
如果审阅者坚持进行某些更改，则可能会使开发人员感到沮丧。 但是，大多数情况下，开发人员会因为评论的形式而不是内容而感到沮丧。 有礼貌，用论点解释，很可能一切都会好的。
“我待会儿解决。”
如果开发人员同意代码中存在问题，但要求MR，并承诺将再次解决该问题，那么Google的专家认为，这种“后期”通常不会发生。 因此，如果MR不是紧急的错误修正，则需要坚持修正。
结论
我真的很喜欢Google的这份文件。 尤其是带有“ nit”一词的生活黑客，强调代码审查速度，并且认为MR不应是完美的。 这似乎很简单，但是只要不明确地考虑这一点，就不会达到目的。
如果这篇文章对读者来说很有趣，并且有很多优点，那么我将写以下部分：作者MR进行的代码审查过程。
更新：本文的 第二部分
此外，在即将发行的《锌销售》中，我们将从不同角度详细讨论审阅代码。 因此，请务必订阅我们的开发播客 ！