代码审查有什么好处？[关闭]

在我的团队中，我们不进行正式的代码审查。我们倾向于认为使用结对编程和经常旋转结对就足够了。

我们应该考虑进行正式的代码审查吗？有什么好处？

我们进行的代码审查有些不同（也许）。

我们召集所有程序员（每个星期五），看看我们在几周内的工作。然后，我们选择要审查的项目，以便每个已完成/进行中的项目至少有一个或几个人。然后在大约一个小时内，我们查看所做的更改，查找错误，其他项目的工作方式等。之后，我们讨论，告诉错误，应该如何做（我们不修正错误，我们只是指出它们并使用FIXME垃圾邮件代码）。对于我们（10位程序员）而言，通常总共花费大约2个小时。

优点：

• 每个成员都知道公司发生了什么
• 发现错误的速度更快
• 它迫使我们编写可读的代码（无需解释或介绍即可阅读的代码！）
• 优化方法/技巧/生产程序的传播速度更快
• 作为专家的程序员“进化”得更快
• 很有趣

如上所述，我反对结对编程（确保这只是我个人的看法）是，团队合作的时间越长，获得的速度就越快。

我希望它能带来一些思考。祝好运。

您可能想通读这本免费书：

http://smartbear.com/best-kept-secrets-of-peer-code-review/

当然，他们有一个要推销的产品，但是那里仍然有很多有用的信息。

他们还讨论了结对编程如何提供一些相同的优点，因此，如果您要结对编程，则可能根本不需要进行代码审查。

在您的环境中进行审核时，我没有很多经验。我们在这里没有做太多的配对编程，我们进行代码审查来传播团队中软件的知识，另外还有两只眼睛可以找出错误，并可以正式地检查软件是否符合我们的编码准则。

结对编程涵盖了前2点，相当不错，第3点非常依赖于结对，可以通过正式的代码审查获得更好的结果。

您应该进行正式的代码审查吗？

绝对

正如边注，我也非常有配对编程经验不多，但我不相信，审查将这些方法相冲突。

我将介绍两种形式的代码审查：

对等代码评论

即使配对编程为你的作品，它永远不会伤害得到另一套眼睛上的代码。这样做的好处是：

1. 它使您对代码有了新的了解，可能是一些对您（和/或您的合作伙伴）可能不熟悉的代码库领域有更深入了解的人。这可能会暴露出连锁问题。
2. 它使您（一对）在提交之前重新验证您的解决方案。由于审阅者对您所写的内容一无所知，因此您必须对其进行完整的解释。这可能会暴露出您未曾想到的极端情况或无效逻辑。

在每次提交之前都要进行同行代码审查（在我的世界中）。我不确定这在结对编程世界中如何延续。

组代码评论

这些事件的发生频率低于对等代码审查。通常，我会把我的小组（或小组的一个子小组）拉到一间会议室进行非正式的代码审查。通常，我会选择一些由团队中随机的人编写的代码，最好是从头开始编写的代码-重构的代码不会暴露诸如新代码之类的问题。

确保每个人都知道这些评论不是故意的，也不是用来反映绩效的。它们只是为了确保遵循您的团队编码标准，并帮助每个人成为更好的工程师，从而对团队变得更加有用（以及进一步的职业发展等），并确保这是审查的真实意图。 。如果有人怀疑有什么不同，这些将变得令人恐惧并且生产效率降低。

我会稍微非正式地审阅代码，让会议室中的每个人指出他们可能有的不同解决方案或遇到的逻辑缺陷。这意味着更多的是小组讨论，而不是坐在那里的领导者告诉所有人他们应该如何编码。

我发现采用这两种方法可以提高工程师的进步速度，并大大减少错误计数:)

我从未在实践中完成结对编程（只是希望如此），因此我无法直接比较这两种实践。但是，我可以说说我对正式代码审查的经验。

我曾经在早期项目中负责遗留代码的正式代码审查。该项目陷入一片混乱，管理层欢迎任何主动行动，希望能使秩序混乱。当时我认为正式的代码审查是一个好主意。我们确实发现了错误，并且确实看到新鲜编写的代码的质量明显优于旧代码。我收集了统计数据，错误计数等来证明这一点。

我们平均每周进行一堂课，涉及3-5人。每个会话每人大约花费3-4个小时的时间（包括准备时间），并检查了200-300行代码（LOC）*。以这种速度，在超过6个月的时间内，我们设法审核了大约5万个LOC中的大约5000个LOC。

回想起来，我觉得这是非常昂贵的。以这种速度，我们将需要5年的时间来审查整个旧版代码库。OTOH每周举行一届以上会议，可能会从开发中夺走资源。当然，这是遗留代码的典型难题。但是，即使正式地审查所有新编写的代码也将花费大量时间，从而极大地减慢了开发速度。

我的结论是，正式代码审查最好在新编写的代码上进行，重点放在代码的最关键部分。其余的最好以更非正式的方式处理，可能是通过结对编程。不过，这只是我目前的看法，可能会改变。我不声称自己是代码审查专家或其他任何人。

*这是正式代码审查的正常步伐。

典型的代码审查速度约为每小时150行代码。每小时检查和检查关键软件（例如安全关键嵌入式软件）的几百行代码可能太快了，无法发现错误。

引自维基百科（我强调）。

之所以存在代码审查的根本原因是因为孤立的程序员需要见面并讨论他们的代码，并检查其是否符合他们的标准。

您没有提到任何质量问题，因此看来您的团队已经在通过配对编程进行了足够的代码审查。太棒了！

正确完成的结对编程可避免进行正式的代码审查。但是尝试几个星期，看看效果如何，但是我怀疑您不会注意到任何改进。

请记住，代码审查是一个累人的，昂贵的过程，不要掉以轻心。从本质上讲，这会在您的项目中引入切换，这不仅代价高昂，而且会拖慢一切。最好首先确保代码正确无误，而不要稍后再查找问题。

也许。代码审查需要时间。只有在检查的时间节省了过程中的其他时间时，它们才是值得的。您希望从代码审查中节省多少钱？您是否遇到了可以通过代码审查来避免的困难？

如果您正在进行结对编程，则代码审查的需求会大大减少，但是您肯定会从同行审查中受益。为了使它变得有益，必须由比一对成员更高级和更有经验的人来完成。

有什么好处？好吧，如果您考虑不这样做的风险，那就更好了。

• 这对可能做错了什么，或者可能以次佳的方式做
• 也许您未遵循编码标准或未正确记录代码。同行评审真的很擅长找到这些
• 除了这对以外，没有人能理解一段特定的代码。那么，如果两个成员都已离开并且代码记录不当怎么办？其他人会浪费时间试图解决问题。让第三方知道您的工作可以降低风险。

我很高兴人们说代码审查是浪费时间。是的，确实需要时间。也许它不会在代码中产生任何变化，但这并不意味着它是浪费的。那就是说您不需要定期检查消防系统，因为这是浪费时间。

对我来说，代码审查的主要优点是它使人们可以编写更好的代码。

知道您的代码将被阅读和检查会使您更加意识到代码的可读性和“正确性”。如果您知道代码将直接进入存储库，除非修复缺陷，否则没人会读它，除非您更改其用途，否则您往往会放任其走，就像在其用法更改时不重新解析字段名称一样，并留下未使用的方法，以防它们可能被归还等。