我们应该尝试审查所有代码吗？

18

我们目前正在修改开发流程，我想知道我们是否应该尝试对100％的提交同行进行审查。

您在代码审查方面有什么经验？

您倾向于在它们上花费“大量”时间（例如每天1/2小时），还是只浏览最大5/10分钟？
您每天/每周/每个冲刺/项目是否有固定的时间花费？
最重要的是，您认为目标应该是对100％的代码进行同行评审还是不需要100％？

code-reviews

— 西缅
source

尝试花费20％的精力接触80％的代码。投资钱可以买到的最好的自动化工具。

— 工作

2

自动化工具很棒，但是除非您有时间和资源来将所有测试保持最新状态，否则自动化工具就毫无用处。

— Kieren Johnstone

19

每个故事中都有一个“代码审查”任务。理想情况下，不参与该故事开发的人员将审查与该故事相关的所有代码更改。它运作良好。

很多时间？不是很多，取决于多少代码-我们正在寻找明显的错误，错别字，基本逻辑健全性检查，未捕获的异常等。

这是发现错误的质量步骤，因此具有一定的价值。分配时间可能不是最好的方法-如果某件事相当复杂，应该对其进行代码审查呢？

顺便说一句，其他人进行代码检查很重要。

— 凯伦·约翰斯通（Kieren Johnstone）
source

3

“顺便说一句，请他人进行代码审查很重要..”，这个问题是否暗示着编写该代码的同一个人应该进行审查？如果在哪里呢？我想解决这个问题：)

— Simeon，

4

不，不是，我很全面，说这很重要

— Kieren Johnstone

5

@Simeon实际上是一个非常普遍的误解，即所有者可以查看自己的代码。它破坏了整个行动

— Tom Squire

5

@TomSquires：是的。当您长时间使用一段代码时，您可能对其他明显的缺陷“视而不见”，因为您将其视为应有的功能而不是应有的功能。对于以前从未看过代码的人，这些问题将更容易发现。作家也有同样的问题，就像书籍未经校对不会发行一样，代码也不应未经审查就发行。进行代码审查还有其他好处，例如，这对于在团队成员之间传递知识非常有用。

— hammar 2011年

@hammar-当然，要找到一个没有写代码的人，他们有时间变得非常熟悉它，以至于他们可以有帮助地对其进行审查，这是一个挑战

— Peter Ajtai 2011年

12

复审覆盖代码的全部内容更重要的问题是复审的有效性。如果您的评论发现很少或没有问题，那么完全覆盖将毫无用处。

首先要使您的评论更具效果，然后再决定覆盖范围。

审查不仅应在代码上进行，而且还应在设计上进行。

此外，评论不能替代测试和工具：

评论可以空运行代码
评论可以包括代码分析
审查审查重用性和可读性
评论可以检查效率的某些方面，但是，这不能代替运行时间的实际测量和瓶颈的发现
有用于静态代码分析的工具
有用于测试编码约定的工具，请不要在此浪费审核时间
单元，系统和集成测试湿运行代码
单元，系统和集成测试的测试可以自动重复，代码审查通常是一次性的
单元测试应该具有较高的代码覆盖率，并且可以测试主要的成功方案和最终条件，而代码审查只能部分地做到这一点
集成测试测试单元或系统协同工作的能力，代码审查不能替代此功能
系统测试测试整个系统的功能，代码审查不能替代此功能

尝试将每月（或每个冲刺）的预设时间专用于评论。使用试探法在下一个专用插槽中选择要查看的代码：

可能包含未报告的错误的代码
最近带有该代码的代码中发现了错误
出现性能问题的代码（瓶颈）
新开发者编写的代码
以前不熟悉的人最近更新的旧版代码
新领域代码
您希望新开发人员了解的现有代码
解决复杂问题的代码
被分析工具识别为复杂的代码

请记住，您正在查看代码（或设计或测试），而不是作者。

我推荐以下阅读材料：

选择性家庭作业评论同行代码评论的
 最佳秘密

— 丹尼·瓦罗德（Danny Varod）
source

5

这取决于。

这取决于您的软件在做什么：

如果它控制着电子起搏器或航天飞机，那么肯定可以。
如果这是一个可丢弃的原型，那么可能不会。

它还取决于您的资源丰富程度，开发人员的经验水平以及在代码审查中寻找的内容。（请记住，审查其他人的代码的普通开发人员可能会注意到样式问题，并错过了细微的算法错误……尤其是考虑到代码审查是一件繁琐的事情。）

我的建议是为正确性至关重要且未发现错误的成本很高的代码省去代码审查工作。

— 斯蒂芬·C
source

5

首先，您需要回答以下问题： 为什么要查看代码？

有了这个答案，您可以找出需要检查的代码。

一些代码检查可以准确地完成测试已经完成或将要完成的工作。如果这是您审查的目标，那么如果您几乎没有进行测试，那么接近100％是个好主意。但是，让测试工具执行此操作将减少检查所有代码的需求。

大多数好的评论似乎都集中在共享知识和提高开发人员在评论中的能力（编写代码的人或评论代码的人）。以此作为进行审查的主要原因，确保对100％的代码进行审查可能是过大的。

— 约翰·费希尔
source

3

在一个理想的世界中，作者的所有内容都将由作者明确阅读，并由至少另一个人进行同行评审，从需求规范到用户手册再到测试用例。但是评论甚至是简单的桌面检查都需要花费时间和金钱。这意味着您需要选择应该查看的内容以及何时查看。

我建议优先考虑要检查的事情，选择要如何检查它们，并尝试使用适当的详细程度进行尽可能多的检查。可以根据工件的类型来确定优先级，例如指出必须审查需求，应该审查设计和生产代码以及可以审查测试用例。在此范围内，您还可以指定高风险或高价值组件应优先接受审核，或者可能是更正式的审核。

就时间而言，一切都可以追溯到组件的优先级。有时候，我花了10到15分钟进行审核，有时又有多个人分别阅读代码，然后进入一个房间进行更正式的检查过程，该过程持续30-45分钟（取决于检查的大小）模块）。

最后，它是时间，成本，范围和质量之间的平衡。您不可能全部拥有它们，因此您需要优化自己可以使用的位置。

— 托马斯·欧文斯
source

3

作为建议，如果您打算进行任何审核，请对审核范围和目标有一些共同的指导原则，以确保审核不会引起团队成员之间不必要的摩擦。

连贯的团队可以建立更好的项目。人们可能会因为胡扯或追求完美而失去关系。总是有一个人会抱怨这个或那个而仅仅因为他是那样就烦扰别人...

— 没有机会
source

2

我每天预留一个小时进行同行评审，但并不总是需要它。我们的代码库在几十个产品中共享。我们的政策是，无需检查即可签入一种产品的唯一代码的小改动。更复杂的单产品更改需要进行审核，但可能非正式地打电话给同事到您的办公桌再进行一次。共享代码的更改需要更正式的审核，包括其他产品的开发人员。我认为与我工作过的其他公司相比，我们的政策取得了相当不错的平衡。

我每天花在审查上的时间要多于一些中心角色较少的同事，但我认为这不是不合理的时间，因为在执行审查策略之前，我可以轻松地花费比查找开发人员错误更多的时间在介绍的另一种产品上。

— 卡尔·比勒费尔特
source

那是平均值吗？将一个复杂的评论限制为一个小时似乎很奇怪，并且如果没有太多要回顾的话。那么我看不出每天有一个小时是可行的吗？

— 基恩·约翰斯通

那不是限制。我根据花费的时间设置时间，而不是相反。我通常可以在一个小时内完成2条评论。如果花费的时间超过此时间，则说明签入太大，您没有事先获得足够的设计审查，或者您的代码审查工具太繁琐。代码审查只是检查，而不是重新设计。

— Karl Bielefeldt

2

我们已经完成了100％的代码审查。它比测试便宜得多，尤其是100％代码覆盖率测试。我们不会花太多时间在它们上面，每天复查一个小时以上会降低工作效率。（30分钟不是很多）。

在调零过程中，请注意。你发现了什么？质量检查后来发现了什么？您的客户发现了什么？为什么这些虫子逃脱了您？

— 杂项
source

7

与自动测试相比，如何评价便宜？假设您一次编写一个测试，一次审查一个测试，并且拥有一个稳定的测试套件，那么执行测试的时间和金钱应该比进行任何类型的审查（在项目的整个生命周期内）花费的时间少得多。而且，争取100％的代码覆盖率是对资源的浪费，这可能是测试时间/成本较高的原因。我还对30分钟的审核提出了质疑-我们可能会对模块进行30分钟的审核，但是还有准备时间来开始阅读代码，了解其在系统中的作用并对其进行评论。

— Thomas Owens

@MSalters的说法并不是闻所未闻的，尽管我也只用了30分钟就对此表示怀疑。我只读过一个地方的情况，即检查比自动单元测试更具成本效益，那就是NASA。在那种情况下，他们最终完全放弃了单元测试，因为手动检查代码更便宜。当然，NASA的测试人员与开发人员的比例仍然是12：1，因此他们也进行了许多其他测试……

— Michael

2

@Thomas Owens：单元测试发现简单的错误。昂贵的错误是多个单元以意外方式组合的错误。另一种错误是缺少极端情况。错过案例的开发人员也不会为其编写单元测试，但是第二眼会发现它。

— MSalters 2011年

@MSalters这就是为什么您编写自动化集成和系统测试以及单元测试的原因。实际上，唯一可能需要手动执行的测试是验收测试。通过在创建时检查测试，将有助于确保测试最关键的案例。

— Thomas Owens

2

定期进行代码审查，主要用于团队建设和共享实施思想。您可以通过这种方式从同事那里学到很多东西。

— 编码器
source

这仅表明一些好处。您认为发现错误很重要吗？如果是这样，多少钱？

— JeffO 2011年

当然，发现错误很重要，但是更大的好处是从代码审查中获得的长期知识。可能是由于错误的方法所导致的错误，这种错误可以在日后避免

— 编码器

2

我们要求每次签到都进行同行代码审查。如果没有同龄人，我们将安排入住后审查。在源代码管理签到注释中会注明审阅者。

这些不需要花费很多时间，而且由于它们是在同伴之间完成的，因此对他们没有成年子女的毒害。

— 吉姆在得克萨斯州
source

2

IMO需要进行代码审查。您有99.999 ...％的时间并不总是正确，因此您需要确保它是正确的。我有设定的时间吗？不。但是我确实花时间检查我的代码。通常我有一个同事也这样做。

— 动态
source

1

代码审查看似令人生畏，但如果进行适当的话，它们是一种有价值的工具。它们将是您防范设计和实现错误的第一道防线。如果您不对已部署的每个功能进行代码审查，则应尽快开始。

至于花在同行评审上的时间是一个好习惯，最好将估计的总开发时间的5-10％留给代码评审进行和响应。

我们有一份白皮书进行有效的代码审查，可帮助您从正确的角度入手。这是一个循序渐进的指南，讨论了您可能会遇到的常见陷阱以及如何解决这些陷阱。您可以从我们的网站下载。

— 凯蒂B.
source