如何有效地执行代码审查_不执行代码审查？你的借口是什么

最新推荐文章于 2022-09-05 07:25:36 发布

danpu0978

最新推荐文章于 2022-09-05 07:25:36 发布

阅读量426

点赞数

文章标签： java python 人工智能编程语言大数据

原文链接：https://www.javacodegeeks.com/2011/06/not-doing-code-reviews-whats-your.html

版权

如何有效地执行代码审查

我们所有人都已经很长时间知道代码审查会发现缺陷，而且审查比大多数类型的测试更便宜并且更有效。史蒂夫·麦康奈尔（Steve McConnell）在Code Complete中建立了代码审查的压倒性案例：严格的代码检查可以发现代码中所有缺陷的45％-70％，而即使是快速的非正式审查也可以发现20％-30％。在IBM，HP，Microsoft和其他地方的研究表明，在代码审查中发现错误的成本要比通过测试便宜几倍。并且不断有证据支持该代码审查工作。

“无论产品的领域，组织的成熟程度或应用它们的生命周期阶段如何，评论都能涵盖产品一半以上的缺陷。” 我们了解到的与缺陷作斗争的知识

最近对代码审查实践的研究和工具的进步使审查更有效，更便宜，并且可以改变我们对代码审查的看法以及我们进行代码审查的方式。

轻量级代码审查工作

使用1970年代IBM的Michael Fagan定义的模型，许多关于代码审查的文献，包括Code Complete，都集中于基于团队的正式代码检查。繁重而繁重的Fagan检查通常至少需要4个人：程序员，读者，主持人和一个或多个审阅者。每次审核会议都需要大量准备工作，大量文档，并且可能需要持续几个小时。

现在，越来越多的人通过轻量级但仍然严格的代码审查获得成功；在非正式的“嘿朋友，您可以看一下”肩上的代码演练与昂贵的Fagan全面检查之间的中间立场。在制作软件的《现代代码审查》一章中，杰森·科恩（Jason Cohen）解释说，轻量级审查几乎可以像正式检查一样有效，而且成本也要便宜得多。在Fagan检查中进行的正式审查会议耗时费力且难以安排，主要是浪费时间-在会议之前发现了95％的缺陷。会议的真正目的是传达调查结果，并确保程序员理解它们。如果是这样，会议可以以不那么正式的方式举行，或者根本不举行。

工具协助的评论

今天的审阅者可以依靠工具来帮助他们提高工作效率。诸如Findbugs之类的Static Analysis错误检查器， Coverity和Klocwork中的工具，甚至诸如IntelliJ Idea之类的IDE内置的检查器，都使代码检查器的工作变得更加轻松和有价值。这些工具捕获了过去的编译器并可能使以前的审阅者感到困惑的编码中的细微错误和常见错误，它们突出了糟糕的或可疑的代码，并且可以在编码中实施样式约定和最佳实践。这意味着审阅者可以专注于更基本的问题，例如正确性和错误处理以及安全性和安全性问题（这些工具以及Fortify 360等其他工具也可以帮助发现安全漏洞）。

正式的审核会议非常昂贵且难以建立。许多较小的团队通过电子邮件离线进行审阅，而有时在程序员或审阅者认为有必要时进行一对一的会谈。规模更大的分散团队可以使用同行评审协作工具，例如Crucible或Review Board或SmartBear的CodeCollaborator或Google Code Reviews （又名Rietveld ）来共享代码评审结果。这些工具与您的版本控制系统（有时还包括错误跟踪器）集成在一起，如果在不同位置和不同时区涉及多个审阅者，则这些工具特别有用。审阅者和程序员可以随更改直接添加注释或评论，从而减少了审阅会议的需要。

一些团队使用这些工具来确保完成代码审阅，并证明已完成合规性：他们可以强制执行工作流（在代码提交到主代码行之前进行审阅），经理（和审核员）可以看到代码审查的结果。新的程序员可以查看他们正在处理的代码的审阅历史，以了解有关代码以及如何进行有效审阅的更多信息，程序员和管理人员可以回顾审阅的结果并找到改进方法。这些工具中的一些收集代码审查指标，而其他工具（例如Klocwork Inspect ）将审查者的发现和静态分析发现整合到同一个审查空间中。

另一个可以帮助进行安全性检查的代码检查工具是Security Ninja的 David Rook的Agnitio 。 Agnitio的目的不同：不是帮助开发人员进行代码审查协作，而是按照详细的代码和设计审查清单，通过安全审查来组织和指导审查者，然后记录每次审查的结果。

评论发现的不只是功能缺陷

审查可以发现重要和根本的设计和实施问题。这包括由于难以测试而导致测试人员可能找不到的细微逻辑问题和操作安全弱点，并且审阅者具有“白盒优势”，即他们可以看到代码中的问题或遗漏。代码审查对于发现安全漏洞很重要，这通常是查找漏洞的唯一方法，除非通过详尽且昂贵的笔测试进行。这就是为什么代码审查像Microsoft的SDL一样是安全SDLC的基本部分的原因。

但是，除了查找错误和安全漏洞以外，还有更多的要回顾。 Mantyla和Lassenius在2009年进行的一项有趣的研究“ 在代码审查中真正发现了哪些类型的缺陷？ ”以1990年代末期Siy和Votta在贝尔实验室的早期研究为基础，该研究表明，审阅者发现的大多数问题不是功能性错误，而是审阅者所说的可进化性缺陷：使代码难以理解和维护的问题，更脆弱，更难以修改和修复。

平均而言，在代码审查中发现的缺陷中有60％至75％属于此类。其中大约1/3是简单的代码清晰度问题：改进元素命名和注释，确保代码有意义。其余大部分发现是组织问题，其中代码结构不良，或者重复或未使用代码。或解决一些问题，使审阅者可以看到更简单，更整洁的实现，有时可以用内置的语言功能或库调用来替换手动编写的代码。审阅者还可以发现不属于或不需要的更改，复制和粘贴错误以及不一致之处。

这些缺陷或建议会反馈给重构，对于将来对软件进行维护，降低复杂性并使将来更容易更改或修复代码很重要。不仅如此：许多更改还降低了实施的技术风险，提供了更简单，更安全的解决问题的方法，并隔离了更改或缩小了更改的范围，从而减少了可能导致缺陷的数量。在测试中发现或逃到野外。

那么，为什么没有更多的人来审查代码呢？

2005年的一项研究发现，不到一半的开发团队正在遵循代码审查。

当然，评论很难。我的一位同事花费大量时间来审查代码，发现它筋疲力尽，比自己编写代码困难得多。为了进行良好的审查，您必须花时间了解代码以及所做的更改，然后将自己放在程序员的脑海中，并按照他们决定的解决方案进行工作。这需要时间和纪律。但是投资回报是显而易见的。

我将给已经遵循纪律的结对编程的XP风格的团队通行证-尽管结对的重点是寻找一个好的解决方案，而不是寻找问题，但是结对编程中仍然会发现很多错误和结构性问题。好的静态分析工具可以解决其他问题。这些团队中的大多数也正在遵循TDD编写有纪律的单元测试。他们没有写草率的代码。

独奏程序员有一个明显的问题：如果您自己编写代码，谁来审查您的代码？您只能进行自我审查：将代码搁置一会儿，然后自行审查。这比您预期的要有效。杰森·科恩（Jason Cohen）说，审查自己的代码的程序员只需再看一遍，就能发现另一位审查者会发现的多达一半的问题。而且，单独的程序员也可以依靠静态分析工具来发现一些问题。

审核不一定重要，您不需要正式的审核会议。并且有一些工具可以使评论更便宜，更容易和更有效。那么，其余的人呢？您为什么不进行代码审查？你的借口是什么

参考： 不进行代码审查？你的借口是什么由我们的JCG合作伙伴Jim Bird组成的“ Build Real Real Software ”博客。

相关文章：