Google发布针对构建错误的研究洞见
英文原文:Google's Study Provides Insights into Programmers' Build Errors
Google 的工程师们最近发布了一份研究论文,针对过去九个月中,Google 内部数以千计的开发者所生成的两千六百万份构建进行了实证研究,并给出了一些洞见。这份论文介绍了构建工作流,并分析了失败频率和编译器错误类型,以及开发者们解决这些错误所做的努力。论文作者们表示,研究结果所引申出的洞见,能帮助我们理解构建过程在大型组织机构中如何发挥作用,以及如何更有效地为开发者们提供支持。
论文作者们认为,研究过程中采用了描绘业界程序员与其编译器和构建工具如何交互的方法,使得该研究“非常新奇”。此外,他们强调了构建过程的重要性,认为它是“编辑-编译-调试”循环中的核心步骤:
缓慢的编译可能会让程序员被其他任务分心或是丢失当前工作的上下文[…]任何延误都会放大程序员决定下一步要执行的变更,与查看该变更效果之间的间隔。确保构建过程快速,并了解何时以及为何失败,是提高程序员生产力的关键部分。
研究者们对以下四方面指标的分析,并试着回答一些问题:
- 每个开发者执行的构建数量。
- 构建失败率。
- 每个错误类型实际发生的错误数量。
- 开发者解决错误所花费的时间。
构建失败的情况有多频繁?
构建失败率的分析结果显示,“失败情况接近正态分布。其中,C++构建失败的中位百分比(38.4%)高于 Java(28.5%)。”研究者们将不同语言之间的差异,归结于(至少部分程度上):大部分 JAVA 开发者能够从他们使用的 IDE 所提供的内建的检查中获益。
“失败率极低或极高的开发者都很少见,”而且这两种类型的开发者似乎都不是某一特定语言或项目的常规参与者(临时使用该语言或参与该项目)。
对于构建数量与构建失败率之间,这次的研究并没有发现强相关现象。因此,或许能够排除这样的假设:构建更频繁的开发者可能会拥有更高的失败率。
而对于开发者经验和构建失败率之间,研究甚至没有发现相关性,或许某种程度上“这也许是因为很难精确地描绘经验或专业度。”
构建为何会失败?
论文中列出了许多构建错误,并对其发生频率进行了测量,如图 1 所示(点击查看大图)。
对于列出的这些错误,该论文将其进一步划分为五大类:依赖性、类型不匹配、语法、语义和其他。错误的数量在这五大类型中的分布如图 2 所示。
对C++(52.68%)和 Java(64.71%)来说,依赖相关的错误都是最常见错误。而语法方面的错误,C++多于 Java。对此,论文作者同样认为,这是由于 Java 开发者能够“享受到”更强大的 IDE 所致。
解决构建失败的问题需要多久?
总的来说,这次的研究发现,解决构建错误的中位时间分别是 5 分钟(C++)和 12 分钟(Java)。
对于不同错误类型来说,这两个数字可能会有数量级的差异,但平均来说,C++解决时间要少于 Java——不过,部分 C++ 构建错误的解决时间的中位数要高于 Java,因为它们更难以解决。
在修订错误之前的构建尝试方面,无论 Java 还是C++,面对 25 个最常见的错误时,75% 的构建错误在最多两次构建中就得以解决了。
调查结果与启发
这项研究最主要的启示,作者认为包括以下方面:
- 编程语言无关,90% 的构建失败分布在大约 10% 的错误类型中。
- 依赖性错误最常出现。
- 平均来说,修复一个构建错误需要一次构建迭代,而大部分错误可以在两次构建迭代中得以解决。
作者们认为研究结果对 IT 从业者和工具开发者来说都很有价值。
<引文>对于 IT 从业者来说,该研究提供了一套手段,用来识别在哪些领域中,额外的专业知识、工具使用或开发行为(例如减少依赖)能够带来最大的好处。
另一方面,“更好的能够解决依赖性错误的工具,将带来最大的潜在回报”。类似地,对错误信息和类型所做的定量分析,能够帮助编译器团队识别出,需要重新审视哪些错误信息,以便使其对开发者而言更有意义。
最后,希望大家能够意识到,与任何其他研究报告一样,这份研究也有其局限性。论文的作者们给出了以下可能影响其有效性的因素:
- 该研究仅在一家公司内部展开,因此受限于特定的流程、制约因素、资源和工具。不过,该研究覆盖的构建、开发者和涉及系统的数量量级,为社区提供了宝贵的基线。
- 该研究专注于 C++ 和 Java 两门编程语言。
- 最后,与以下因素有关的抉择,都可能会影响研究结果的适用性。这些因素包括数据采集、错误分级、将错误映射到分类方法(归类),以及为了消除干扰而对数据做的裁剪。
这项研究由 Google 工程师 Caitlin Sadowski、Edward Aftandilian 和 Robert Bowdidge,与香港大学研究员 Hyunmin Seo、Nebraska 大学研究员 Sebastian Elbaum 共同完成。
来自: InfoQ