这个静态缺陷需要关注吗？代码演化分析告诉你……

点击蓝字 关注我们

一般认为，代码静态缺陷的严重程度由该缺陷导致的最坏情况和发生最坏情况的可能性共同决定。严重的缺陷应该受到开发人员的更多关注和及时处理。

然而在开发实践中，不同团队不同业务需求对不同的静态缺陷实例严重程度的判断可能并不相同。有些静态缺陷是程序分析技术本身产生的误报，也有一些静态缺陷则可能由于在特定上下文中并不被触发等多种特殊因素而被开发人员有意忽略。

为了使得静态缺陷告警与开发人员关注程度更加匹配，我们通过历史上引入的缺陷是否被修复以及修复是否及时，来深入分析开发人员对各类静态缺陷的关注度。

在本文中，我们分享了对来自Apache的5个高星开源项目过去2年的静态缺陷演化分析结果，通过一些实际案例来说明，有哪些静态缺陷被扫描工具认为严重，但在实际项目中开发人员并不认为存在问题，而又有哪些被扫描工具认为并不严重的缺陷，却需要开发人员及时关注，从而避免潜在的质量问题。

面向质量和效能分析的代码大数据平台“祝融”具备精准的静态缺陷全生命周期构建能力，从高质量开源项目收集静态缺陷数据并内置静态缺陷关注分级模型，为静态扫描规则定制和静态缺陷关注度分级提供支撑，从而使得开发人员能快速关注到存在较高质量风险的代码静态缺陷，提升面对大量静态缺陷时的处理效率。

“祝融”预览地址zhurong.codewidom.net（推荐用桌面浏览器访问）。现已开放预览账号注册。若有开源项目试用需求，可联系服务邮箱[email protected]。

静态扫描基本情况

采用的静态扫描工具：SonarQube

采用的扫描规则集：默认的规则集，含452条扫描规则

扫描的代码仓：zookeeper等5个来自Apache的高星开源项目

扫描时间段：过去2年

扫描时间解析度：每个commit

静态扫描结果分析

SonarQube在5个代码仓的最新版本中总共检测出548个Bug类型的静态缺陷，其中严重程度为Blocker、Critical、Major和Minor的分别有57、18、333和140个。在这些静态缺陷中，对每个严重程度的静态缺陷，我们分别查看了存续时长为1年以上、4个月以上1年以下、1个月以上4个月以下以及1个月以下的缺陷。

结果发现，如果一个严重程度高的静态缺陷存续超过4个月以上，其被主动修复的可能性会变得很低；同时，一个严重程度较低的静态缺陷，也可能在较短的时间内（比如1个月内）修复。从具体案例上看，不修复的严重缺陷往往是开发人员有意为之或认为实际不会产生问题；而快速修复的非严重缺陷，则往往是开发人员在开发过程中“顺手”修复的一些较为简单的问题，或者是一些与开发进度相关的“暂时性”问题。随着开发进度的推进，原本纳入开发计划的工作完成后，这些缺陷通常在短期会被修复。

例如，在SonarQube判定严重程度为Major（即最坏情况虽然不至于造成程序崩溃等严重异常，但发生最坏情况的可能性高）或以上的75个缺陷中，有71个（近95%）存续时间超过了一年。经人工确认，这些缺陷长期不修复的原因大多数与误报或特定代码上下文有关。

我们发现，类型为“Loops with at most one iteration should be refactored”（只迭代一次的循环应该被重构，该类型缺陷的严重程度为Major）的多个缺陷经常被用作取列表（例如数据库查询的返回数据）中的首个元素。这时，为了代码书写方便，程序员选择了使用迭代器并且让循环仅执行一次就return的写法。因此，这个Major缺陷就被开发者“故意”忽略了。由此，在该代码仓中，该类型缺陷存续时间很长，确实大概率代表着开发人员并不关注该问题。

图1展示了另一个案例：“Loops should not be infinite”（不宜使用无限循环）缺陷。它在代码仓中也已经存续了超过一年。尽管这是一个Blocker级（最高严重级别，即最坏情况可能造成程序崩溃等异常且发生最坏情况的可能性高）的缺陷，但我们发现这是开发者有意编写的后台持续运行的线程。从实际运行情况来看，这段代码在程序实际运行中并没有造成问题。而事实上，同类问题在我们所观察的几个开源项目中，大部分都处于这种长期存续且不被修复的状态。

因此，我们初步推论出，鉴于这些开源项目整体质量相对优秀，如果某类缺陷即使严重程度高，但总体来看其存续时间长、修复比例低，那么开发人员对这类缺陷的关注程度就可以适当降低。

图1  严重程度高但开发人员不关注的缺陷代码案例

我们也发现一些低严重程度的缺陷需要开发人员在近期需要关注的案例。通常，这些缺陷与开发进度有关，可能是一些“暂时性”的问题。但如果开发人员不去关注，则一些原本应该注意到的实现细节则可能被忽略或遗漏。

图2展示了一个类型为“Method parameters, caught exceptions and foreach variables' initial values should not be ignored”（不宜忽略方法参数、捕获的异常以及foreach变量的初始值）的缺陷。该问题在出现后，很快（一周内）被修复。我们发现这是开发人员在开发新功能时“暂时”留下的缺陷；随着功能开发完成，该缺陷随即消除。

图2  严重程度低但建议开发人员关注的缺陷代码案例

尽管这个缺陷的严重程度为Minor（即最坏情况不会造成程序崩溃等严重问题，且发生最坏情况的概率比较低），且在大多数代码仓中很少出现，但我们在一个代码仓中发现该类缺陷引入较多且通常在引入后很快被修复，因此我们认为至少在该代码仓中，此类问题是经常被开发人员关注的。

由此，我们得到另外两个推论，首先，不同代码仓和不同的开发团队，由于开发模式、业务内容等方面的差异，其关注的静态缺陷类型可能大相径庭，因此有必要对不同代码仓进行定制化的静态扫描规则定制；其次，静态扫描工具检测出的低严重程度的缺陷也可能需要受到开发人员的关注，以免开发人员遗忘必要的开发任务。具体的缺陷关注优先级判定，需要结合本代码仓的静态缺陷修复情况并参考高质量开源项目的缺陷修复情况综合分析。

我们在面向质量和效能分析的代码大数据平台“祝融”中定义了一套启发式规则（见本公众号推文“基于历史分析的企业软件代码静态扫描问题治理”），并在实践中逐步优化，以帮助软件开发管理人员全面掌握静态缺陷对软件质量的影响，设定合适的静态扫描规则集，并给开发人员修复静态缺陷提供必要的优先级提示。

小结

传统代码静态扫描所给出的静态缺陷严重程度分级并不总是与实际开发过程中开发人员的感受完全一致。对静态缺陷进行关注优先级评估，是提升静态扫描分析结果利用效率和效果的重要手段。这种关注优先级评估不仅要考虑缺陷对软件质量的真实影响，还可综合代码演化历史数据以及开源项目的缺陷修复经验数据。这种全方位的考量能更有效地引导开发人员关注代码质量，其给出的关注优先级也因此更为精确和实用。

“祝融”平台的静态缺陷全生命周期精准构建能力为相关数据分析提供必要的支撑。我们期待在更多的实际应用场景中持续吸取经验，持续优化。

“祝融”网址：zhurong.codewisdom.net （推荐用桌面浏览器访问）。预览账号密码zhurong/zhurong；现已开放预览账号自助注册。

服务邮箱[email protected]。

企业本地部署试用也可联系[email protected]。

作者：周捷，孙婕，吴毅坚，彭鑫

编辑：孙婕

审核：吴毅坚