对等/代码审查失败

我不会称自己为超级巨星开发者，而是相对经验丰富的开发者。我试图将代码质量保持在较高水平，并且一​​直在寻求对我的编码样式的改进，试图使代码高效，可读性和一致性，并鼓励团队遵循一种模式和方法来确保一致性。我也了解在质量和速度之间取得平衡的必要性。

为了实现这一目标，我向我的团队介绍了同行评审的概念。在github pull-request中两个竖起大拇指以进行合并。很好-但是我认为没有打cc。

我经常看到来自相同同事的同行评论，例如-

• 在之后添加一个空格会很好 <INSERT SOMETHING HERE>
• 方法之间多余的多余线条
• 在文档块中的注释末尾应使用句号。

现在，从我的角度来看-审阅者只是从表面上看待代码美观性-并没有真正执行代码审阅。化妆品规范审查以傲慢/精明的心态传给我。它缺乏实质性内容，但是您不能对此进行过多辩论，因为审阅者在技术上是正确的。我宁愿看到较少的上述评论，而更多评论如下：

• 您可以通过以下方式降低圈复杂度：
• 提早离开，避免如果/其他
• 将数据库查询抽象到存储库
• 这种逻辑并不真正属于这里
• 不要重复自己-抽象和重复使用
• 如果X将其作为方法的参数传递将会怎样Y？
• 单元测试在哪里？

我发现提供修饰类型评论的总是同一类型的人，而我认为给出“基于质量和逻辑”的同行评论总是相同类型的人。

什么是同行评审的正确方法（如果有）。我是否对同一个人感到沮丧，因为他们基本上都是在浏览代码以寻找拼写错误和美学缺陷而不是实际的代码缺陷？

如果我是正确的-我将如何鼓励同事在建议进行外观修饰的同时找到代码中的错误呢？

如果我不正确-请赐教。对于真正构成良好的代码审查，是否有任何经验法则？我是否错过了什么代码审查的要点？

在我看来，代码审查与代码的共同责任有关。如果不解决/检查逻辑，可读性和功能性，我会不愿意给代码竖起大拇指。如果我发现有人在文档块中省略了句号，那么我也不会为可靠的代码块而阻塞合并。

当我检查代码时，每500 Loc可能花费15-45分钟。我无法想象这些简短的评论要花超过10分钟的时间，如果那是他们正在执行的评论的深度。此外，浅薄评论者的赞许是多少？当然，这意味着所有人的拇指都不一样，并且可能需要进行两遍审核。一个拇指要进行深度评价，第二个拇指要进行“抛光”？

评论类型

没有一种真正的方法可以进行同行评审。有很多方法可以判断代码的质量是否足够高。显然存在一个问题，即它是否是越野车，或者它是否具有无法扩展的解决方案或脆弱的解决方案。符合本地标准和准则的问题虽然可能不如其他标准那么重要，但也是促成高质量代码的一部分。

评论者类型

正如我们对软件的评判标准不同，进行评判的人也有所不同。我们都有自己的技能和偏爱。有些人可能认为遵守本地标准非常重要，就像其他人可能更关注内存使用情况或测试的代码覆盖率等一样。您需要所有这些类型的评论，因为它们总体上将帮助您编写更好的代码。

同行评审是协作，而不是标记游戏

我不确定您是否有权告诉他们如何做他们的工作。除非您不确定，否则请假定此人正在尝试以他或她认为合适的方式做出贡献。但是，如果您发现有待改进的地方，或者怀疑他们可能不了解同行评审的期望，请与他们交谈。

A的得分同行审查是涉及您的同行。参与并不是在墙上扔代码，而是在等待响应被扔回去。参与正在共同努力以编写更好的代码。与他们进行对话。

忠告

在问题即将结束时，您写道：

我将如何鼓励同事在明显的美学错误与实际错误之间寻找代码错误？

同样，答案是沟通。也许您可以问他们“嘿，我感谢您发现了这些错误。如果您还可以专注于一些更深层次的问题（例如我是否正确构建代码），这将对我有很大的帮助。我知道这需要时间，但实际上救命。”

更为务实的是，我个人将代码审查注释分为两个阵营，并用适当的措词表述：必须修复的事物和更具修饰性的事物。如果文件末尾的空白行过多，我将永远不会阻止检查可靠，有效的代码。但是，我会指出这一点，但是我会这样做，例如“我们的指导方针说末尾有一个空白行，而您有20个。这不是停顿，但如果有机会，您会可能要修复它”。

这里还有其他要考虑的问题：他们对您的代码进行了如此简短的审查可能是您的小麻烦。很有可能是他们（您或其他获得类似评论的队友）对您自己组织的编码标准草率，这就是他们选择与您进行沟通的方式。

审查后该怎么办

最后，在审阅之后提供一些建议：在审阅之后提交代码时，您可能需要考虑在一次提交中处理所有修饰性的事情，而在另一次提交中进行功能更改。将两者混为一谈，就很难区分重大变化和微不足道的变化。进行所有外观更改，然后提交诸如“化妆品；无功能更改”之类的消息。

人们对代码格式和拼写错误发表评论，因为它们很容易发现，不需要太多的努力。

该部分易于修复-几乎所有语言都具有linter或样式检查器工具。将其插入构建过程中，这样，如果有冗余空间，它将使构建失败。因此，将不会有任何样式问题需要评论。

让他们发现真正的问题可能是一个很大的挑战。这不仅需要特殊的好奇心和注重细节的思维方式，而且还需要很大的动力。

而这种动力来自经验。尝试使用以前的开发人员编写的糟糕代码的经验。高级工程师有很多。在狗屎海洋中游泳会给您一种强烈的愿望，那就是不要再次到达那里。

如果我需要在代码审查期间选择一件主要的事情检查，那就是代码的可维护性。在任何时候，审查此代码的开发人员都应该理解它，并准备进行增强和修改。如果他不知道这里发生了什么，则需要立即告诉它，并且代码需要重写。

这里是实际的答案：

方案1：您是高级会员，并且可以决定做法

召开会议并制定《代码审查》规则和准则。相信我，明确的指导方针比任何“荣誉”系统或培训都更好。要明确一点，根本不要提出代码格式问题。一些成员会反对。听他们讲，然后请他们按照前几个月的指导进行实验。如果当前的指导方针不起作用，则表明愿意改变。

方案2：您不是决定练习的人，或者您是团队中的初级成员

最好的选择是仅解决代码审查问题，直到您成功达到方案1。

防止“琐碎的”代码审阅注释的简单答案是（出于效率考虑）坚持认为审阅者应该是修复这些问题的人。因此，如果审阅者发现您（恐怖！）错过了句号或错误地写了评论，他们应该将其修复并继续前进。

以我的经验，这意味着：

• 您的评论者将停止发表这些相对毫无意义的评论，并将其传递回固定的位置。
• 只有大多数OCD审阅者会修复它们，这意味着您的大多数审阅将通过。这具有要求开发人员执行更多实质性审查的连锁效应，那些因为实际未审查代码而进行琐事的人最终不得不证明为什么所有审查都无需评论就可以通过。

无论哪种方式，这都是有好处的。在使开发人员停止他正在从事的工作并重新访问其代码以及随后的后续审查方面，失败的审查成本很高。如果审查发现真正的代码质量或体系结构问题，则此成本值得每一分钱，但为琐碎的事情付钱是不值得的。

审核审核过程

除了代码审查，我建议您还定期审查审查流程。人们当然也可以在这里学到很多东西，例如，如何进行适当的代码审查。

通常，一些骑自行车的人没有经验，只是不知道要寻找什么。他们不仅需要有关其代码的指导，而且还需要进行有用的代码审查。提供有关审阅的反馈将导致学习过程（希望满满的），从而产生更好的审阅和更好的代码。

接下来，（宽松地）规范一组价值和标准，组织或团队将什么视为Good Code™以及应避免哪些反模式是一个好主意。这与设置某事无关。具体来说，但要从一开始就代码质量达成共识。

作为一直从事这方面工作的人（查看其他人编写的代码，以及审阅我编写的代码），我想说我可以将反馈归为三类。好吧，四，还有“一切都很好”的令人愉快的案例。

“会很好，但不会阻止您”（如果所有反馈都属于此类，我可能会发出合并请求，并带有“将在XX：XX合并，除非您告诉我要修复它们” ，或“确保继续进行检查，系统将抛出的任何块都已被禁用”）：

• 忘记句末句号（在文档字符串或注释中）。笨拙的语法，不会以任何形式或形式（再次，文档字符串和注释）散发给用户
• 代码具有更优雅的方式，但是其中的内容是可以理解和惯用的（我可能甚至会提出我的建议，因此离开或修复很容易）

“需要解决的问题，但我会信任您的。”（如果所有问题都属于此类别或上一类别，我将回答“修复这些，当您告诉我，重新完成”（到那时，我可能会迅速扫描以查看是否弹出了其他任何内容））：

• 次要问题（“您正在将boolean与进行比较true，这有点偏执...”，...）
• 轻微违反样式的行为（“样式指南说X，您所做的事超出此范围；根据您想走的路，我会做Y或Z”）
• 一些缺少的测试用例，应该很难写

最后，“有问题的问题，一旦您解决了这些问题，我将需要再次审查您的代码”（如果有此类问题，则需要进行另一轮审查，因此请在注释中注明“还有一些小事情，很高兴看到一些固定的东西，如果前两个类别中有任何东西，那么：

• 诸如“不，确实有一种更好的书写方式”，“您没有计算出预期的结果，因为您的单元测试错过了这些极端情况”之类的东西，以及所有其他严重问题。

似乎有些人已经忘记了最重要的问题：您希望通过代码审查实际实现什么？

代码审查的目的是更快地获得无错误且可维护的代码。代码审查通过以下几种方式实现了这一目标：开发人员首先编写了更好的代码，因为他们知道将对其进行审查，知识是审查过程的一部分，并且将发现错误，因为审查者不会视自己为开发人员的错误可。

如果您认为审核过程是放下同事或为同事创建工作的机会，那么您做错了。