我新公司中的团队没有代码审查流程。
我来自必须进行代码审查的公司,因此,如果没有别人审查我提交的代码,我会感到不自在。
我坚信代码审查是一种提高质量并节省时间的方法,因为它可以尽早发现潜在的问题(请注意,我并不是在谈论结对编程)。
- 如何显示代码审查不是浪费时间,而是节省时间?
- 如果您有单元测试,可以跳过代码审查吗?
我新公司中的团队没有代码审查流程。
我来自必须进行代码审查的公司,因此,如果没有别人审查我提交的代码,我会感到不自在。
我坚信代码审查是一种提高质量并节省时间的方法,因为它可以尽早发现潜在的问题(请注意,我并不是在谈论结对编程)。
Answers:
如果您有单元测试,可以跳过代码审查吗?
但为什么?
同行评审的主要作用不是发现错误。
是的,您可能会发现一些潜在的错误以及可疑的,容易出错的代码,这种情况经常发生,但是偶尔发现一些错误并不意味着同行评审是排除错误存在的可靠方法。远非如此。这不是验证实现功能正确性的正确工具。
但是,代码审查可以增强代码的可维护性。我将要求代码在投入生产之前是干净且易于理解的(不仅限于其作者)。
单元测试的存在与之完全正交。您可以拥有100%的代码覆盖率,并且通过所有完全不可理解的代码的测试。
代码审查还可以使其他开发人员熟悉您的工作,以便他们知道什么是什么,并能够从那里接受,或者在您休假期间处理错误报告等。知道您立即完成的工作可能对他们有帮助做好工作-保持代码库一致(在整个应用程序中遵循相似的模式和约定),或避免代码重复。
在更广泛的情况下,人们还可以通过阅读他人的代码来学习并成长为一名开发人员。
单元测试几乎不能替代任何单元测试。是的,如果他们写得很好,他们读起来就像文档一样,我们应该为此努力。但这再次与进行同行评审并不矛盾,相反,同行评审的所有优点仍然成立,而您的同行拥有一些不错的单元测试,这一事实只会使评审过程更加轻松,甚至更加有益。而不是多余。
Peer review doesn't even attempt to tackle this important aspect
确实如此。在一定程度上。我经常发现自己指出例如。“合作伙伴,您实际上在这里重复了同样的逻辑,那是一枚滴答作响的炸弹。有一天,它将在另一个地方发生变化,我们将在这里忘记对其进行更新...”
有没有研究和统计数据表明代码审查不是浪费时间,而是节省时间?
我什么都不知道 进行这样的研究也很困难,因为您需要两个具有相同且现实的复杂性任务的团队来完成,其中一个团队使用代码审查,而另一个则没有。您可能需要让他们解决相同的问题,这意味着要往窗外扔很多钱。而且您需要经常重复进行实验,以获得统计上的相关性,这将使投入的资金增加几个数量级。
如果仅使用代码审查来衡量公司的效率,而不是不使用代码审查,则不仅不清楚如何衡量效率,而且还不清楚真正的原因是什么。代码审查是一种较大文化的一部分。它的哪一部分实际上使团队更有效,这很难说(并且很可能取决于团队或项目的性质)。或者,这种文化的存在可能仅仅意味着该公司规模较小或较年轻,每个公司都有许多影响。或者很可能是因为愿意提交代码审查阻止或促进了与您自我的健康距离;)
但是请不要忘记:您有自己的经验可以借鉴。这就是他们聘用您的原因。因此,如果您真的相信自己可以提高效率(而您的团队实际上却缺乏效率),那么请清楚地进行沟通。
如果您有单元测试,可以跳过代码审查吗?
不。如果您相信测试的重要性,那么实际上您的测试应该是首先要检查的东西。如果他们胡说八道怎么办?还是覆盖不好?还是如果他们测试实施而非行为?
return true;
。
摘自我发现的一些随机幻灯片,但硬数据来自史蒂夫·麦康奈尔(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%的缺陷”
您可能会要求您的团队负责人和/或同事对您的代码进行同行审查,即使代码审查未正常完成,也可能是您培训的一部分。
在检查之前,请确保您的代码编写正确并经过测试。
当我是团队负责人时,我经常对新员工进行代码审查,直到(一段时间之后)我将不再在他们的代码中发现错误或任何其他需要批评的地方,而在这一点上,我将停止与他们进行代码审查。在以下情况下会发生这种情况:
代码审查具有以下目的:
我认为,即使团队选择跳过有经验的团队成员之间的代码审查,也可以对新员工进行代码审查。
在任何开发的软件上进行代码审查都没有经验法则……这完全取决于应用程序的范围,客户规模和公司规模。例如,如果您正在构建一个应用程序,而该应用程序是一个将来可能没有进一步版本的简单应用程序,那么在那里进行单元测试就足够了。但是,当您谈论应用程序的性能时,代码审查又一次到位了,您需要在代码审查中检查代码的任何短时下降,而这本可以通过更好的方式完成以促进更快的性能。
通常在由两个以上开发人员组成的团队和一名技术负责人组成的团队中进行代码审查,其中技术负责人希望确保应用程序的质量并确保遵循代码标准以扩展应用程序以进行将来的增强并针对不同的版本进行升级即将发布的版本。
例如,我们现在确实有许多CMS开源平台,并且这些平台会不时发布升级以增强平台功能,想象一个开发人员正在使用其中一个平台并且没有遵循诸如在核心文件中进行硬编码,编写应用程序之类的代码标准。模板文件中的代码,并且如果此代码投入生产,并且稍后客户希望将平台升级到新版本时,它将永远不会升级,除非按照该平台的代码标准重新进行编码。在不进行代码审查的情况下将代码发布到生产环境就成为一个严重的问题。
因此,我想说的是,任何专业软件公司都必须在发布之前完成代码审查,并且例外情况仅适用于个人/非常小规模的应用程序,在这些应用程序中,开发人员是非常有经验的程序员并且具有丰富的经验。
代码检查具有的优点并非来自检查过程本身:获取高质量但在短时间内创建的代码始终存在难题。没有代码审查,您就一个人,所以您可能会在短时间内牺牲代码质量。使用代码审阅时,有一位审阅者不会让您摆脱低劣的代码质量-这正是您想要的,被迫花费时间来获取质量代码,而这正是您想要的,以及您知道这将最终节省时间,因为编写更好的代码所花费的每个小时都节省了两个小时(或更多)的调试时间。
没有代码审查,您就自己一个人,因此取决于您要保持高质量的代码。一个简单的解决方案是检查您自己所做的每项更改,并修复不符合质量标准的问题。
这也避免了可怕的情况,即代码审查导致自负冲突–程序员A将使用方法X,而B将使用方法Y的情况,因此,如果A编写他使用方法X的代码,则审查者B坚持使用方法Y,因此,A使用方法Y重写了代码,而如果B编写了代码并且A审查了代码,则完全相反。
如果您是代码审查的倡导者,恐怕没有真正的替代品。不幸和陈规定型的案例是一个不进行代码审查的工作场所,因为(A)他们不熟悉实践,和/或(B)他们不想花费时间和精力进行代码审查。系统到位。
基本上,要在这里获得想要的东西,就需要改变工作场所的文化-这绝非易事。不要忘记,即使您的工作场所百分百地说服代码审查出色并且他们希望采用代码审查,但实际上,要转变为新的工作方式仍然需要大量的时间,精力和生产力投资。这项投资应该可以自己偿还-但是您需要获得投资的支持,而不仅仅是回报。参见Roy Osherove的视频“单元测试和 TDD- 如何实现” -采用代码审查的挑战与采用单元测试的挑战非常相似。
在此期间,请尽力获得最大的收益:
这些中的任何一个主要好处是,如果您能够随着时间的推移对其进行维护,那么您周围的开发人员将开始注意到代码审查。您将有效地说明如何将代码审查集成到现有的文化中,这将为文化的改变开辟道路。代码审查会有所帮助,因此,如果您能够在小范围内证明这一点,则将为其他人(以及整个文化)效仿您的榜样铺平道路。
不用再担心了-您的新雇主根本不在乎代码审查。学会对自己的能力充满信心,而无需别人告诉您可以检查所编写的代码。您将很快学会生活,而无需花费大量精力去审查其他人的代码。
遵循其他所有人使用的样式准则(或仅遵循样式)。根据您的经验来决定需要注释的内容,要使用的命名约定等。
然后在签入之前测试所有内容。最重要的是,它可以正常运行。