我的同事是否应该互相检查源代码控制系统中的代码？

这就是我的故事：我的一位同事用来查看托管到修订系统的所有代码。我并不是说要对他所属零件的变化进行适当的审查。他逐行观看代码文件。每个新文件和每个修改的文件。我感觉就像被监视！

我的猜测是，如果代码已经托管在控制系统中，则至少应该相信它是可行的。我的问题是，也许我太偏执狂了，检查彼此的代码的做法是否很好？

PS：我们的团队只有三个开发人员，我担心如果会有更多的开发人员，同事将没有时间审查我们将编写的所有代码。

我会说是的！

有两个快速原因：

1）如果代码正在生产中，则不能假定它是正确的。系统中其他位置的任何更改都会引入错误。我认为定期检查代码非常重要。这样，重构便会定期进行，从而使代码保持整洁和“更多”正确（最新可能是更好的选择）。

2）如果要成为一名程序员，能够读取代码是一项非常重要的技能。这是一项技能，您需要继续努力。对于任何在现有代码库上开始工作的程序员来说，如果他不习惯于阅读别人的代码，就会有陡峭的学习曲线，试图了解最新情况。

我认为您不应该被监视。接受别人给您的任何批评（当然，如果它是有效的）。并随时给其他人有效的批评。这是我们学习的方式。一旦我们停止学习（或想停止学习），就会出现大问题。

如果所说的同事提供了很好的建设性反馈，那将是一件很棒的事情，您应该非常感谢。

这将捕获您编写时没有想到的错误。这WILL导致你写出更好的代码，因为你知道其他人会看到它。

如果整个团队而不是一个人进行代码审查，那将是健康的。理想情况下，每个人都可以在完成后邀请某人查看其代码。使它保持非正式状态（使经理远离）是很有帮助的，并让审阅者通过他/她的发现告诉您。理想情况下，审阅者仅提供反馈，而不进行代码更改，当然您可以对其进行一点配对。

拥有编码标准确实有助于避免不断进行有关空白和代码风格的讨论。在构建机器上进行一些静态代码分析也可能有助于避免一些讨论。

关于时间方面，理论上讲它将节省您的时间。发现故障越晚，它们得到的代价就越高，即快速故障原理。同行代码审查可能会遇到很多问题。

您的同事听起来像一个勤奋的开发人员，您应该效法他的榜样。

我以类似的方式观看我们的版本控制系统。我们的代码库太大，无法观看每一行，但是我尝试对大多数更改都具有较高的了解。我还将检查最有可能产生副作用的签到项目，并逐行进行检查。在我花费最少的时间进行此操作后，回报是巨大的。（还请注意：我不是我们团队中唯一拥有这种习惯的开发人员。）

这种审查往往会发现错误或每周进行讨论。这样可以节省进行质量检查的时间。讨论范围从最佳实践到算法设计等等。这方面的关键是每个人都认为它具有建设性。

就个人而言，它还使我对我不经常接触的代码库其他部分中发生的事情有了更深入的了解。当其他人需要帮助时，我可以更快地加入。另外，当出现新想法时，我可以早日利用它们。

您觉得它被监视（！）？但是从您的同事的角度来看，我会说他为自己的职业发展做正确的事情。阅读其他代码，并了解他们如何设计和实现逻辑，这将使您受益匪浅！

恕我直言，如果有人指出您的代码中有错误，您必须接受它并向他们学习如何编写好的代码

在6-7个月中，我一直在做同样的事情。不是监视，而是控制质量。积极开发的应用程序的每一行代码，都致力于中央存储库，2种主要语言，几种其他语言以及4个平台的庞大makefile。

这是非常不好的做法。有一天，我发现由于健壮性，我无法捕获所有内容。反对这一观点的另一个论点是主观性-每个人都可能会犯错。

当开发人员检查彼此的代码并且有经验的人做出最终决定和定义方向时，这会更好。

团队内部的代码审查（使用鱼眼镜头，坩埚或其他工具）非常重要和有用。更好的唯一方法是直接对编程，以确保首次进入系统的代码经过深思熟虑，并且已经超过一个人的大脑。

这一次发生在我的团队中。不幸的是，这导致了一场责备游戏。人们不断地等待着其他人签入代码，并且总是会尝试在代码中查找错误并一直打怪游戏。

希望您的观众更成熟。

这是业界相当标准的做法。我工作过的公司有严格的代码审查准则。除非代码经过审查，否则甚至不会让您提交。

请勿冒犯或监视他人。将其视为安全网和学习经验。

在上一份工作中，高级开发人员观看并检查了所有签到内容，而我经常得到出色的反馈，这使我成为一名更好的开发人员。

在我目前的工作中，我观察了许多签到，三天前我发现了一个错误并通知了开发人员。

如果您愿意，这种做法绝对会发现错误，并使您的整个团队变得更好。