我应该坚持要求我们在合并回主干之前执行代码审查吗？

从StackOverflow请求重新发布：

我的工作时间很短，开发时间非常有限。我们开发了一种对我们的工作成果很重要的工具，但每天都不使用。我是团队中唯一拥有程序员背景的人。

我的问题是，在合并回主干一年多之前，我一直在推动代码审查。每个人都对此表示同意，但是仍然只有我的代码被审查过。从长假回来后，我回到了代码注释的主干，因为“这是一个丑陋的解决方案-尽快删除”和“快速修复”。另一个新功能是任命了一个人负责该工具。（最初提供给我一个职位，但由于与工作无关的原因而拒绝了我。）他认为这是一种可行的工作方式：由于我们的开发时间有限，因此我们应该走捷径。

我担心的是其他开发人员编写的代码很丑陋：经常破坏封装，编写巨大的类，在陌生的地方添加内部类，几乎没有单元测试等等。最终将不可能进一步开发该工具。

我应该坚持要求我们在合并到主干之前执行代码审查，还是我只是一个代码质量卑鄙的人？

我以前也遇到过类似的情况，恕我直言，这取决于“我必须维护代码”。

如果我必须维护代码，而不是想要高质量的代码，那么我个人不需要每次提交都进行代码审查（即，程序员可以自行决定是否需要审查某些代码），但是可读性/可维护性是否会受到影响？可能是有秩序的。

在阅读本文时：

我担心的是其他开发人员编写的代码很丑陋：经常破坏封装，编写巨大的类，在陌生的地方添加内部类，几乎没有单元测试等等。最终将不可能进一步开发该工具。

我确实认为您的问题不仅限于代码审查。您似乎缺少一些指导方针和/或未实施。没有/很少进行单元测试可能不是一个好主意，但要视具体情况而定。但是，breaking encapsulation, writing huge classes, ...确实要编写容易产生错误的代码，因此应绝对修复该错误。

我认为代码审查和维护一些编码准则是一个好主意，但我认为每次检查都这样做是浪费时间。建立团队并与年轻的程序员合作时，这是一个好主意，但是经验丰富的程序员可以自己考虑，最终您将不得不信任他们。就是说-您可以进行定期的代码审查以了解新内容，但是查看进入VCS的每一行代码确实都过分了。

关于您的同事的修补程序的一小段评论-有时做一个难看的修补程序是正确的解决方案。可能是因为此特定代码不够重要，无法投入大量时间，也可能是简单的解决方案足够好，而将时间花费在其他方面则更好。作为程序员，您的主要目标不是使代码“漂亮”。您的主要目标是交付并沉迷于每行代码，根本无法解决您的问题。

我想说的是-您需要选择战斗。输掉一些无关紧要的实用程序类以赢得交付大战（或就此而言，这是真正重要的子系统大战）是可以的。

如果所讨论的程序不是一次性的原型，我认为每次检查都必须进行代码审查。

一旦高级开发人员被公认为足够认真，可以在适当的时候请求进行审查，则他们可以享有未经审查的签入特权。

在有人开始执行更好的编码标准之前，不确定代码审查是否是答案。有人编写糟糕的代码，对其进行注释/接受并以任何方式对其进行检查。如果有人想拒绝该代码，那么复查有什么好处，但是会使您落后于进度？

您将需要：制定标准，更密切地监督主要罪魁祸首，并且动脑筋，好的代码并不总是需要花费更多时间来编写。他们需要停止使用时间表，以此作为拒绝改变不良习惯的借口。