当我从事新工作时,如何在新地方不进行代码审查?


33

我新公司中的团队没有代码审查流程。

我来自必须进行代码审查的公司,因此,如果没有别人审查我提交的代码,我会感到不自在。

我坚信代码审查是一种提高质量并节省时间的方法,因为它可以尽早发现潜在的问题(请注意,我并不是在谈论结对编程)。

  • 如何显示代码审查不是浪费时间,而是节省时间?
  • 如果您有单元测试,可以跳过代码审查吗?

每个帮助中心都明确地建议了场外资源建议。参见meta.programmers.stackexchange.com/questions/6483/…–
gnat

1
考虑在这里提问meta.codereview.stackexchange.com 在我看来,可以在这里提出这个问题,因为他/她只想知道与编程相关的概念。
xqMogvKW 2014年

1
尽管我也是代码审查的坚定信徒,但我也有一些糟糕的经历,其中代码审查变成了永久的战争,代码审查工具(gerrit)变成了一些讨论委员会的化身,导致过分激烈的辩论通过超大的自我。我不确定这是否必然会在任何公司中发生,或者这仅仅是人们的成熟度问题。
乔尔2014年

由于“必须进行代码审查”,因此可以重命名为您要问的内容。这是一个过于宽泛,无法回答的问题,因为它将取决于许多因素-公司规模,#开发人员,收入等,等等。我将仔细考虑如何融合并宣传您对良好编程习惯的期望和热情,以及您的公共站点(简历,linkIn,github,twitter等)上的软件工艺。发布您关心的内容和您寻求的内容,以便您想要与之共处的人们看到它。这当然是“未来”建议,因此请发表评论:)
Michael Durrant

3
我看不到这是“非现场资源推荐”。这听起来似乎不适合我。
nyuszika7h 2014年

Answers:


30

如果您有单元测试,可以跳过代码审查吗?

但为什么?

同行评审的主要作用不是发现错误。

是的,您可能会发现一些潜在的错误以及可疑的,容易出错的代码,这种情况经常发生,但是偶尔发现一些错误并不意味着同行评审是排除错误存在的可靠方法。远非如此。这不是验证实现功能正确性的正确工具。

但是,代码审查可以增强代码的可维护性。我将要求代码在投入生产之前是干净且易于理解的(不仅限于其作者)。

单元测试的存在与之完全正交。您可以拥有100%的代码覆盖率,并且通过所有完全不可理解的代码的测试。

代码审查还可以使其他开发人员熟悉您的工作,以便他们知道什么是什么,并能够从那里接受,或者在您休假期间处理错误报告等。知道您立即完成的工作可能对他们有帮助做好工作-保持代码库一致(在整个应用程序中遵循相似的模式和约定),或避免代码重复。

在更广泛的情况下,人们还可以通过阅读他人的代码来学习并成长为一名开发人员。

单元测试几乎不能替代任何单元测试。是的,如果他们写得很好,他们读起来就像文档一样,我们应该为此努力。但这再次与进行同行评审并不矛盾,相反,同行评审的所有优点仍然成立,而您的同行拥有一些不错的单元测试,这一事实只会使评审过程更加轻松,甚至更加有益。而不是多余。


4
我不相信单元测试也不能替代代码审查。但是,单元测试的主要作用也不是捕获错误。是的,您在编写单元测试时可能会发现一些潜在的错误,但是单元测试是为了确保以后不必更改时不会引入错误。因此,单元测试的目的也是保持代码的可维护性。
Doc Brown

2
@DocBrown确实如此。但是,捕获回归错误也属于捕获错误的类别。显然,这是单元测试相对于同行评审(在此方面)所具有的优势之一,因为它们不是一次性的操作。同行评审甚至没有尝试解决这一重要方面,因为在每次更改后重新评审整个代码库是不可行的。
Konrad Morawski 2014年

1
@DocBrown- Peer review doesn't even attempt to tackle this important aspect确实如此。在一定程度上。我经常发现自己指出例如。“合作伙伴,您实际上在这里重复了同样的逻辑,那是一枚滴答作响的炸弹。有一天,它将在另一个地方发生变化,我们将在这里忘记对其进行更新...”
Konrad Morawski 2014年

24

有没有研究和统计数据表明代码审查不是浪费时间,而是节省时间?

我什么都不知道 进行这样的研究也很困难,因为您需要两个具有相同现实的复杂性任务的团队来完成,其中一个团队使用代码审查,而另一个则没有。您可能需要让他们解决相同的问题,这意味着要往窗外扔很多钱。而且您需要经常重复进行实验,以获得统计上的相关性,这将使投入的资金增加几个数量级。

如果仅使用代码审查来衡量公司的效率,而不是不使用代码审查,则不仅不清楚如何衡量效率,而且还不清楚真正的原因是什么。代码审查是一种较大文化的一部分。它的哪一部分实际上使团队更有效,这很难说(并且很可能取决于团队或项目的性质)。或者,这种文化的存在可能仅仅意味着该公司规模较小或较年轻,每个公司都有许多影响。或者很可能是因为愿意提交代码审查阻止或促进了与您自我的健康距离;)

但是请不要忘记:您有自己的经验可以借鉴。这就是他们聘用您的原因。因此,如果您真的相信自己可以提高效率(而您的团队实际上却缺乏效率),那么请清楚地进行沟通。

如果您有单元测试,可以跳过代码审查吗?

不。如果您相信测试的重要性,那么实际上您的测试应该是首先要检查的东西。如果他们胡说八道怎么办?还是覆盖不好?还是如果他们测试实施而非行为?


2
我认为您在测试用例的代码审查方面确实很不错。谢谢!
jparkcool 2014年

4
+1代表“您有自己的经验可借鉴”-实际上,如果一个人确实从事代码审查已有一段时间,那么他必须已经知道在一次典型的代码审查中通常解决了多少质量问题,以及有多少知识转移已实现。从这种经验来看,应该不难为代码审查提供少量支持或反对意见。
布朗

2
关于您的第一段:这不仅需要两个团队执行相同的任务,而且需要两个功能相同的团队,个人经验将与研究此问题的任何尝试混为一谈。
David Wilkins

“如果他们胡说八道?或者覆盖范围太差怎么办?” 或只是说return true;
Burhan Ali 2014年

1
阅读Code Complete的第20章,以彻底了解代码审查以及支持其使用的研究和统计数据。以下是一些不错的摘要:Jeff Atwood的博客另一个人
Mike Partridge

5

摘自我发现的一些随机幻灯片,但硬数据来自史蒂夫·麦康奈尔(Steve McConnell)的《代码完成》(Code Complete)书:

代码审查有用吗?

“我相信对等代码审查是改善代码的唯一最大举措”

http://www.codinghorror.com/blog/2006/01/code-reviews-just-do-it.html的Coding Horror的Jeff Atwood


“单独检查通常会发现大约60%的缺陷,这比其他技术要高,除了原型设计和大量beta测试之外。”

史蒂夫·麦康奈尔(Steve McConnell),《代码完成第二版》,第485页

这60%的数字来自Shull等人在2002年发表的IEEE论文中,我们对打击缺陷的了解,其中包含标题为:

“同行评审发现了60%的缺陷”


1
我认为与此有关的问题是在2006年,我们还没有完全接受结对编程,我觉得这已经成为一种替代对等代码审查的方式。我意识到在某些方面它们是不可比的。
JP Silvashy 2014年

3

免责声明:此答案是我的个人经验:)

在我们维护的代码中,我在代码审查方面经历了非常糟糕的经历。因为我们通常只有一个左右班轮,所以没有太多要回顾的内容。

但是在实际项目中,我取得了很好的经验,在我的考试期间,我的教练定期检查了我的代码,这对我发现很多我经常犯的错误有所帮助,这些错误使我不再这样做。

所以我要说这很大程度上取决于您在做什么,您有多少人等。

同样,您的代码审查在战争中结束的风险也不容小rate。


3

您可能会要求您的团队负责人和/或同事对您的代码进行同行审查,即使代码审查未正常完成,也可能是您培训的一部分。

在检查之前,请确保您的代码编写正确并经过测试。

当我是团队负责人时,我经常对新员工进行代码审查,直到(一段时间之后)我将不再在他们的代码中发现错误或任何其他需要批评的地方,而在这一点上,我将停止与他们进行代码审查。在以下情况下会发生这种情况:

  • 他们了解了与其连接的系统,不需要我对此进行解释
  • 他们学会了设计和/或测试他们的代码,直到我看到之前没有错误为止。
  • 他们对我的编码风格指南了解得足够多,我认为他们的代码可维护

代码审查具有以下目的:

  • 查找代码中的缺陷
  • 团队成员之间的知识转移

我认为,即使团队选择跳过有经验的团队成员之间的代码审查,也可以对新员工进行代码审查。


2

在任何开发的软件上进行代码审查都没有经验法则……这完全取决于应用程序的范围,客户规模和公司规模。例如,如果您正在构建一个应用程序,而该应用程序是一个将来可能没有进一步版本的简单应用程序,那么在那里进行单元测试就足够了。但是,当您谈论应用程序的性能时,代码审查又一次到位了,您需要在代码审查中检查代码的任何短时下降,而这本可以通过更好的方式完成以促进更快的性能。

通常在由两个以上开发人员组成的团队和一名技术负责人组成的团队中进行代码审查,其中技术负责人希望确保应用程序的质量并确保遵循代码标准以扩展应用程序以进行将来的增强并针对不同的版本进行升级即将发布的版本。

例如,我们现在确实有许多CMS开源平台,并且这些平台会不时发布升级以增强平台功能,想象一个开发人员正在使用其中一个平台并且没有遵循诸如在核心文件中进行硬编码,编写应用程序之类的代码标准。模板文件中的代码,并且如果此代码投入生产,并且稍后客户希望将平台升级到新版本时,它将永远不会升级,除非按照该平台的代码标准重新进行编码。在不进行代码审查的情况下将代码发布到生产环境就成为一个严重的问题。

因此,我想说的是,任何专业软件公司都必须在发布之前完成代码审查,并且例外情况仅适用于个人/非常小规模的应用程序,在这些应用程序中,开发人员是非常有经验的程序员并且具有丰富的经验。


1

代码检查具有的优点并非来自检查过程本身:获取高质量但在短时间内创建的代码始终存在难题。没有代码审查,您就一个人,所以您可能会在短时间内牺牲代码质量。使用代码审阅时,有一位审阅者不会让您摆脱低劣的代码质量-这正是您想要的,被迫花费时间来获取质量代码,而这正是您想要的,以及您知道这将最终节省时间,因为编写更好的代码所花费的每个小时都节省了两个小时(或更多)的调试时间。

没有代码审查,您就自己一个人,因此取决于您要保持高质量的代码。一个简单的解决方案是检查您自己所做的每项更改,并修复不符合质量标准的问题。

这也避免了可怕的情况,即代码审查导致自负冲突–程序员A将使用方法X,而B将使用方法Y的情况,因此,如果A编写他使用方法X的代码,则审查者B坚持使用方法Y,因此,A使用方法Y重写了代码,而如果B编写了代码并且A审查了代码,则完全相反。


0

如果您是代码审查的倡导者,恐怕没有真正的替代品。不幸和陈规定型的案例是一个不进行代码审查的工作场所,因为(A)他们不熟悉实践,和/或(B)他们不想花费时间和精力进行代码审查。系统到位。

基本上,要在这里获得想要的东西,就需要改变工作场所的文化-这绝非易事。不要忘记,即使您的工作场所百分百地说服代码审查出色并且他们希望采用代码审查,但实际上,要转变为新的工作方式仍然需要大量的时间,精力和生产力投资。这项投资应该可以自己偿还-但是您需要获得投资的支持,而不仅仅是回报。参见Roy Osherove的视频“单元测试和 TDD- 如何实现” -采用代码审查的挑战与采用单元测试的挑战非常相似。

在此期间,请尽力获得最大的收益:

  • 如果还有其他开发人员看到了代码评审的价值,请尝试互相评审,甚至非正式地进行评审。
  • 如果您有一位导师或某位开发人员负责您的培训,请向他解释您在代码审查中看到的价值,并询问他们是否愿意(至少有时)愿意审查您的代码。
  • 告诉您的经理您想查看其他人的代码,因为它可以帮助您更好地了解系统。
  • 如果您在某个时候成为团队负责人,则可以只为您的团队在本地设置代码审查。

这些中的任何一个主要好处是,如果您能够随着时间的推移对其进行维护,那么您周围的开发人员将开始注意到代码审查。您将有效地说明如何将代码审查集成到现有的文化中,这将为文化的改变开辟道路。代码审查会有所帮助,因此,如果您能够在小范围内证明这一点,则将为其他人(以及整个文化)效仿您的榜样铺平道路。


-2

不用再担心了-您的新雇主根本不在乎代码审查。学会对自己的能力充满信心,而无需别人告诉您可以检查所编写的代码。您将很快学会生活,而无需花费大量精力去审查其他人的代码。

遵循其他所有人使用的样式准则(或仅遵循样式)。根据您的经验来决定需要注释的内容,要使用的命名约定等。

然后在签入之前测试所有内容。最重要的是,它可以正常运行。


2
-1:OP的新团队不进行代码审查的事实并不意味着这样做。这是一个好的工程师的标志,可以帮助改善开发过程的质量。
约根·福

1
@JørgenFogh我也支持代码审查,但是您似乎假设代码审查将有助于此特定的开发过程。除了这个答案,我想问一下为什么他们不进行代码审查-他们可能有充分的理由。就像这个答案所暗示的那样,也许这家公司雇用了不需要查看其代码的人员,或者至少这样做所带来的好处不值得多花钱。如果OP尝试但没有任何运气改变任何东西,这将是重新依靠的答案。
DoubleDouble 2014年

1
收益可能不值得付出代价。但是,团队不执行代码审查这一事实并没有告诉我们他们是否应该这样做。
约尔根·福格·

4
-1:“最重要的是它可以正常工作。” 这是在生产代码方面重要的短视视图。读取代码比编写代码更频繁。(执行良好)代码审查的价值远不止于检查正确性。在众多优点中,代码审查可确保代码对未编写代码的人有意义。
2014年

-2

如果您的新雇主不喜欢代码审查的想法,那可能是因为他们与老式的命令和控制类型方法有着消极的联系,并且他们的目标是一套更加现代,敏捷的类型的实践。在这种情况下,它们可能对结对编程的想法更为开放,结对编程提供了许多相同的好处,并且被广泛认为是一种更具活力的现代实践。

By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.