如何与不喜欢代码审查想法的人打交道？

显然，如果管理层愿意花时间进行代码审查，那么每个人都必须这样做。

但是总会有一些人（或女孩）对自己的每一分都抵抗。

当您作为同行审阅者处理此方案时，您如何有效管理该方案？

他因为恐惧而抗拒。造成这种状况的原因可能是以前在小时候，在学校，在工作甚至在您目前的团队中接受复习的不良经验造成的。在我们的现代社会中，将某人的工作成果与他作为人的价值相混淆是很常见的。这就是为什么不能很好地进行工作审查的原因。这就是为什么在公开恐惧心理（恐惧恐惧症）之一中公开演讲的原因。

为了避免这种行为，您将需要一些心理学。您必须通过使他对代码审查不敏感来向他的蜥蜴大脑证明这不会发生（不会被审判，侮辱，杀害……）。

我发现解除阻止某人的最有效方法之一是，在要求查看他的代码之前，请他查看您的代码。

一段时间后，建议他阅读其代码以从中学习，以及为什么不建议改进。当您发现需要更改的内容时，请注意所写内容。他将了解没有什么可害怕的，并且他将只参与审阅过程的积极部分：学习并增加自己的知识。

我会尝试成对工作-与讨厌这个想法的人和一个喜欢这个想法的人组成团队，让他们互相检查几个星期的代码。显然，这可能有所帮助，也可能无济于事，但在评审的两端，至少将使该过程更为全面。在一起工作可以使他们熟悉彼此的风格和常见的错误，并让他们有时间实际帮助彼此变得更好，而不是橡皮戳。这也可以帮助您在工作环境中促进结对编程，因为我认为您可能会看到越来越多的趋势，不仅要进行审查，而且要从头开始重新编码甚至计划和编码。

只要无私的政党愿意尝试，这可能会有所帮助。如果他们拒绝考虑，只要他们在团队中，您将无能为力。

对于担心进行代码审查的人，@ Pierre的答案是正确的。我可以想象另一种情况。感到代码审查的明星程序员会浪费时间，因为那里的代码达到了可接受的质量和正确性标准。在这种情况下，他们可能会觉得代码审查既浪费时间又是猎巫。（这是在不存在问题的情况下进行的搜索。）

在这种情况下，我将重新定位审查的目标。代码审查不是要在代码中查找“问题”，而应将其视为对重构目标或潜在的未来增强功能或其他设计功能的搜索。这样，编码人员和审阅者都参与了该过程，希望这个有能力的编码人员会觉得有时间可以利用。

坦白说，如果您拥有一家经营得当的商店，那么这个问题毫无意义：

1）如果这是工作的一部分，则必须这样做，否则您将处于下属地位。坚决拒绝做他们被要求做的部分工作的人应该被罐头。编程是一种技巧，也是一种职业-审阅者和经理在那里帮助完成工作，而不是与（任何年龄的）变坏的孩子打交道。

2）如果您拥有一个管理良好的源代码控制系统（在任何专业软件商店中都是必须的），则可以检查他们的代码，无论是否喜欢。因此，请查看他们的代码：

• 如果情况良好，请通知他们并拍打他们的背部-这会鼓励他们参与。

• 如果不好，也请告知他们。这应具有激励他们参与进来以捍卫自己的作用。如果不是这样，则可以使用惩罚措施：罚款，降级等。如果尽管这名员工努力工作，但IMO仍然不行，您的员工状况不佳，应向他们展示。

他们在代码审查未正确完成的地方是否有负面经历？他们可能有合理的顾虑。

如果他们绝对不认为这样做有什么好处，请让他们耐心等待，看看他们的代码，特别是其他代码（如果他们认为是完美的）会发生什么。

代码审查“应该”改善开发，但是在您拥有一个切实可行的系统之前，为什么有人要这么做？

我个人认为，有些战斗是100％人口无法赢得的。

我可以看到足够的原因，当有人被迫做配对编程时，配对编程不起作用。

但是代码审查是不同的-它们会改变您的工作效率，不一定会改变您的工作习惯。

管理层可以采取以下几项措施来降低由于生产力引起的阻力：1）接受所有开发人员的速度降低。2）提供适当的工具来处理由于审阅周期而导致的多个版本的管理和合并（例如，允许开发人员拥有本地git存储库）3）施加某种社交或其他形式的压力，以确保负载分配，质量和及时性的评论。

如果他们这样做，请允许所有人，恕我直言，这是合法的。我现在工作的公司在全球范围内发挥着作用-未经所有者批准，您根本无法提交。虽然这使事情变慢，但可以防止很多事故。

我们使用了技术措施来强制进行代码审查。

我们引入代码审查的方式是，在源代码控制中，不可能合并未被其他人（然后是推入者）签署的代码。

解雇他们

就是这么简单-他们要么获得一个孤独的项目，要么必须离开。让他们离开您的团队。他们不仅没有发挥自己的作用，而且削弱了团队的士气和实践。

现在，如果您似乎必须解雇50％的团队，那么...

了解

为什么有些拒绝？他们没有时间吗？他们被烧死了吗？是否评论了他们没有经验的东西？他们是否认为这是浪费时间？

敏捷方法将在这里有所帮助-我假设您一直在反对孤岛（即减少总线系数），并且您团队中的每个人都在参与其他人的工作。

确保单个合并请求很小。如果更改屏幕不止1个，则需要站起来或闪电般的谈话来说明正在执行的操作。如果是10页，则需要一个带有幻灯片和体系结构图的演示文稿。

有问题的每个人都在同一个项目上吗？

该项目是否已经被技术债务掩盖了？

他们相信这个项目并不断改进吗？