什么是常见的代码审查过程，什么被认为是不好的？

我的公司最近开始进行正式的代码审查。流程是这样的：您提交到github中，请求拉取请求，代码将由大约三个人审阅，然后，如果全部通过，则代码会进入。

这个过程看起来很公平，但是进行代码审查的三个人似乎并不公平。我注意到，当我将代码放入代码中进行审查时，我得到的注释介于100-200之间。对我来说，最高的一次是300条评论。当然，您会认为这是很大的更改，但是对于少于50行的代码（包括单元测试），这也可能是非常小的更改。所有评论都被认为是“必须做的”，并且没有争议。

考虑到这一点，我的主要问题是，这似乎有点过头了。我与该小组进行了交谈，他们基本上告诉我，仅仅因为我在php中拥有多年的开发经验并不意味着我是“开发人员”。当然，这似乎比没有伤害更大。我还注意到，在小组中，他们似乎没有产生太多评论，大多数时候，他们忽略或以其他方式忽略了其他评论或建议，即使有什么问题也很少接受它为有效。

所以我的问题是，这是否公平？还是普通的？

所有评论都被认为是“必须做的”，并且没有争议。

恕我直言，这是真正的问题，因为其中没有优先级。当您收到100-300条评论时，必须有一些优先级为A（实际错误），其中一些优先级为B（可能会在以后导致错误），而某些优先级为C（其他所有功能）。告诉您的同事您愿意尊重他们的所有意愿，但是要使更改有效并且您的时间有限，请坚持优先考虑。然后，首先修复prio A，然后，如果您确实有更多时间，可以从B开始。（如果幸运的话，您的老板将了解修复prio B和C并不那么重要，并给您一些更重要的任务，而不是浪费时间。

代码审查可能是一个分裂过程。

但是，您处在重要的交汇处。对他们的评论进行周到的分析。他们是在确定挑剔的问题，还是突出您的风格和逻辑上的严重缺陷？

如果是前者，我建议您努力解决（新工作或新代码审查流程）。

如果是后者，我建议您进行大量的代码阅读和学习，以尝试使您的代码达到专业水平。

从您的评论看来，您的同事正在使用代码审查过程来同意一种方法或完善代码。我刚刚开始像您一样进行代码审查，并且我注意到有时我们讨论的仅仅是实现方法或改进方面的事情。就其合理程度而言，这一点也不差（300条评论对我来说太多了，必须看起来像是reddit线程）

在开始执行代码之前，您可能需要同意一些关于代码的体系结构决策，或者只是在命名约定，模式和良好实践方面都同意，所以大家都知道它被认为是“好的代码”。

如果您遵循您所说的代码标准并且代码按预期工作，则应该没有太多注释，因此它们要么将您的代码用作论坛，要么就好像在指向您一样在诱骗您。

我会尝试自己成为批评家，尝试参加对话并查看所有评论的原因，并可能以建设性的方式与他们讨论，以了解他们为什么对您的代码如此不满意，以及是否可以以使每个人都开心的方式编写代码，而工作不会陷入代码审查中。

我只是读了您的最后评论，有时当您不同意该代码时，您可以遍历一百次，并在所有地方提出不满意的更改，因为真正的原因是您会做出不同的体系结构决策而且，无论您重构它多少次，您都不喜欢该代码。就像我在上面说的那样，也许您需要事先同意代码的方法，以便在编写代码时知道他们的期望，因此您的代码对他们而言将更加合理。

用您的话来说，在我看来，他们可能会对php开发人员存有偏见，因此，他们正试图找出与您的代码不符的每件事，以证明他们的观点。¹

关于代码审查本身，我相信，正如您已经说过的那样，如此大量的次要评论比一些好的和有效的批评没有多大用处。而且，尽管我在代码审查方面的经验有限，但是以下技术对于我过去工作过的团队非常有效。

• 首先，在进行代码审查之前，应使用静态代码分析器来识别大多数问题。例如：通过Sonar，Lint或任何其他好的代码分析器运行代码应该可以帮助您摆脱大多数次要问题。特别是因为您的审阅者可以定义自定义配置文件，以确保从方括号放置，空格，注释，适当的变量命名等所有方面，确保一切……
• 第二，如果您将评论分为不同的类别，我似乎工作得很好。例如，在两个类别中，一组包含一些小东西，您应该注意并在将来应用。第二组是针对那些需要立即修改您的代码的注释，这些注释需要再次提交和随后的审核。当然，后面一组中的评论数应该更少。

此外，我不得不说，我的第一个实际代码审查还包含了比我最初预期的更多的注释。但是我从来没有认为这是一件坏事。如果您继续从他们的注释中学习²，并愿意在以后的代码提交中应用那些新近学习的技术/最佳实践，那么注释应该会减少。我肯定是这种情况;-)

¹ 以我的经验来看，这种情况经常发生，因为许多程序员声称php是最邪恶的编程语言，拥有最没有经验的程序员使用它。我不相信这种说法，因为我相信优秀的软件可以用任何语言编写！

² 假设尽管评论过多，但其中有些价值

任何人在例行代码审查中获得100条以上的注释是否很普遍？我不会说。对于那些对代码质量“有很多期望”的人们，获得很多评论是很普遍的。

但是，这也取决于代码审查过程的“规则”。每个人对于应该如何做都有自己的想法。如果您的代码审查过程允许注释采用“您应该以这种方式而不是那样的方式”的形式，那么即使有足够的代码，您也可能会得到很多注释。如果您的过程旨在查找“缺陷”，则注释的数量应该少得多。

以我的经验，允许“建议”替代方法的评论会浪费时间。这些“建议”应在审核过程之外一对一地处理。缺陷评论更有用，因为它们使人们将注意力集中在错误上，而不是“为什么不像我那样去做？”。它也更有用，因为如果有人发现了一个错误，就无法否认。因此，没有伤害的感觉，而是感激之情。

更新：综上所述，即使没有缺陷，某些代码也很糟糕。在那种情况下，评论评论应该是一个类似的评论。“此代码需要清理。请推迟审查，直到与[您的名字在这里]讨论该代码为止。” 在这种情况下，应停止对代码的进一步检查，直到纠正注释为止。

UPDATE2：@User：您在开发代码/设计时是否与他们之一讨论您的代码/设计，以便您可以按照自己的方式实现他们正在寻找的东西？您是否正在根据他们的建议来更改有关如何开发代码的方式，或者一直认为自己的方式是正确的？您从他们的评论中学到了什么吗？

当我是一个项目的负责人时，负责所有工作产品是我的工作。如果我批准工作产品，那么我声称该产品是可以接受的。我想以制造优质产品而享有声誉。因此，我有期望，不会接受不尽如人意的。同时，我尝试教授和解释我偏爱的原因。这些偏爱可能并不总是理想的（特别是在其他人的眼中），但是这些偏爱中的大多数都来自经验。通常是为了避免重蹈覆辙。因此，无论回推如何，我都有一些个人“贴纸”需要获得我的批准。

另一方面，您需要学习使工作产品获得批准所必需的期望。您可以不同意，但由于您似乎无权统治，因此请了解预期。我怀疑团队正在努力使您失败。因为这也使它们看起来不好。在这方面，只要证明您渴望学习（即使不是），按照他们的话说，并尽最大的努力适应他们的喜好，您可能会发现他们退缩了很多。也许找到一个您至少可以容忍的人，然后看看他们是否会做些努力来教您如何做。谁知道，在这个过程中，您可能会学到一些可以真正将您的技能提高到新水平的东西。

我们的团队检查流程有一些重要差异：

• 检查的基础是整个团队编制的清单。
• 焦点是缺陷（现在和将来），而不是风格。
• 3名检查员（包括提交人）坐在一起浏览这些评论。仅保留多数票的评论。

对于50 LOC，300条评论似乎有点过分，而且-哇-每个拉动请求有3个审阅者？您的公司必须有很多资源。

根据我的经验，一个有用的代码审查过程必须有一些规则和/或准则：

• 评论优先
• 注释的分类（错误，代码样式等）
• 同意的架构/设计
• 商定的代码风格

如果您没有从审稿人那里得到优先考虑，请询问您负责的项目经理/团队负责人；费用负责人应该对优先级有意见。

如果您具有定义的体系结构，对项目中使用的设计模式和一致的代码风格有共同的了解，那么审阅注释应仅涉及“实际问题”，例如安全性问题，意外错误，指定情况未涵盖的极端情况。建筑等

如果您的开发团队尚未就“口味问题”达成共识（例如，成员变量应以“ m_”开头），那么每个审阅者都会强迫您遵循他的风格，这只是浪费时间/金钱。

在我看来，这确实像是沟通问题。您期望您的代码还不错，不足以容纳300条注释。评论者似乎认为您需要很多反馈。以异步方式来回争论将浪费大量时间。哎呀，写300条评论真是浪费时间。如果这些还不是全部缺陷，那么作为新的团队成员，您可能还不知道团队的风格。这是正常现象，应该学习一些知识以加速整个团队的发展。

我的建议是节省时间。加快反馈速度。我会：

• 进行更多中期审核，以避免犯同样的错误并产生相同的评论50次
• 与审阅者一起坐在审阅代码的位置，这样您就可以在出现问题时进行讨论，从而避免记录300个“问题”，这些问题将在下一次提交中消除
• 在编写代码时，与其中一位“真正的”开发人员配对一段时间，以了解他们会做些什么

人们可能会反对配对，因为“这将花费更长的时间”，但这显然不是问题。