如何清理您的静态分析：10 个技巧

您的开发团队是否被静态分析工具不断增加的违规数量压得喘不过气来？您当前静态分析配置产生的海量噪声是否已使团队对所有警报都麻木不仁——包括那些您认为至关重要的警报？

现在正是春天，这是通过一些春季大扫除来振兴您的静态分析工作的绝佳时机。首先要清除那些让您难以聚焦真正关心的问题的杂乱。接下来，通过扩大其范围来为您的计划注入活力，以增加其对您组织的价值。

以下是 10 种方法，可以刷新您现有的静态分析实现——无论您使用的是哪种静态分析工具。

技巧 1：禁用您目前不打算修复的违规的静态分析规则

检查大量规则并不是实现静态分析最佳投资回报率的秘诀。事实上，在许多情况下，情况恰恰相反。如果您专注于一小组有意义的规则，静态分析实际上会产生更好的结果。

当您进行静态分析时，就像有一个经验丰富的开发人员站在一个新手开发人员的肩膀上，在他写代码时给他提供建议。如果经验丰富的开发人员不断唠叨代码中每几行中的琐碎问题，新手开发人员很快就会不知所措，并开始过滤掉所有的建议——无论好坏。但是，如果经验丰富的开发人员专注于一两个可能导致严重问题的方面，新手开发人员更有可能记住他得到的建议，开始编写更好的代码，并真正欣赏收到此类反馈。

静态分析也是如此。如果您能保持其可管理和有意义，您将教给开发人员更多知识，并让他们对该过程的怨恨感大大降低。您是希望有一套遵循的小规则，还是一套不遵循的大规则？如果您不真正期望开发人员在报告规则违规后立即进行修复，您可能需要认真考虑禁用该规则。

技巧 2：禁用导致过多噪声的静态分析规则

如果某个规则被反复违反，现在是重新评估您是否真的想继续检查该规则的好时机。过多的违规表明开发人员没有按照规则的要求编写代码。说服他们改变编码习惯可能会遇到相当大的阻力。

您如何确定坚持这个问题是否值得付出努力？首先，尝试回想一下您最初为什么要检查这个问题。您是因为它似乎是解决您在现场遇到的问题的好方法而选择它吗？作为您合规性努力的一部分？还是仅仅因为它由供应商默认启用？供应商通常会在其规则描述中提供每个规则的参考。阅读这些描述可以帮助您确定该规则是否真正适合您的项目和目标。

接下来，看看是否有其他方法可以达到预期结果。是否有更具体的替代规则？是否可以微调规则参数，使其不那么频繁地触发？（更多关于此的信息，请参阅技巧 6）。您甚至可以考虑编写自己的规则，以便更好地匹配——或让供应商为您创建自定义规则。

如果您在重新检查了其优势并探索了替代方案后仍然有兴趣检查此规则，请获取一些开发反馈，了解遵循此规则将涉及哪些工作。然后，您可以使用这些反馈来确定要求开发人员遵循此规则是否真正值得。如果看起来工作量很大但收益甚微，请继续禁用该规则。

技巧 3：使用抑制来允许在特定情况下发生违规

在某些情况下，您可能承诺遵循某条规则，但希望在特定情况下允许豁免。例如，您可能有一条规则要求在代码中进行某种额外的验证。假设您有一个性能关键的代码方法，该方法每分钟被调用数百次——而且您已经验证过在该特定方法被调用之前已经执行了适当级别的验证。或者，假设基于流的分析正在警告您一个在集成应用程序中 100% 无法达到的路径中存在严重问题。这时抑制就派上用场了。

当您想检查某事，但在特殊情况下不关心报告的问题时，抑制是理想的选择。通过抑制，您可以继续检查关键问题，而无需反复收到关于您故意违反规则的消息。如果您不想收到特定规则的任何违规错误的通知，我们建议您完全禁用该规则（参见第 1 点）。

您通常可以从静态分析工具的图形用户界面、配置文件或源代码本身定义抑制。当抑制在源代码中定义时

• 您可以确保在您或团队成员分析该代码时应用相同的抑制。

• 您可以添加代码注释来解释每个抑制，这样当您或团队成员审查或修改代码时，每个抑制的原因总是清晰的。

• 您可以获得对文件、类或行级别上强制执行的规则的精细控制。

您通常可以抑制特定规则、多条规则的违规，或某个特定类别中的所有违规。您还可以豁免某些代码块免受所有静态分析（有关更多信息，请参见下一节）。

技巧 4：停止分析有问题的文件或代码块

有时，对某些文件运行静态分析根本没有意义——例如，自动生成的文件或您不打算修改的遗留文件。在这些情况下，您应该阻止对这些文件进行分析。这是确保您的结果不会因您不打算修复的大量违规而混乱的又一种方法。
有几种方法可以做到这一点。您可以设置路径过滤器来排除您不想检查的文件，或者只包含您想检查的文件。或者，您可以配置您的工具来跳过包含特定注释的文件——例如指示自动生成代码的注释。

专注于检查的其他方法包括

• 添加标记以指示您想在被豁免的文件中检查的特定代码块。

• 排除正在分析的文件中的特定方法。

• 仅检查自某个截止日期以来未添加或修改的文件。

• 仅检查在“截止日期”之后或在一定天数内添加或修改的文件。

技巧 5：通知静态分析工具供应商有关导致误报的无效规则

对于基于模式的静态分析，误报是指在代码实际遵循规则但被错误报告的规则违规。例如，如果规则说您有一个未关闭的资源（如 JDBC 连接），但实际上连接已关闭，那么这就是误报。如果您遇到此问题，并且该规则是您真正想遵循的，那么春季大扫除是最终向您的供应商报告它的好时机。

请注意，如果您走这条路，您需要确定您看到的是真正的误报，而不是您不喜欢的规则。开发人员经常将一条消息称为“误报”，因为他们不喜欢该规则，或者觉得它不适用于此实例。这类消息不是误报，您的供应商在这种情况下无法帮助您。

但是，如果您能提供一个简单的测试用例来显示某个规则实际上是如何产生错误消息的，您会发现大多数供应商在解决问题方面都非常乐于助人。

技巧 6：自定义静态分析规则参数以满足您的需求

另一种减少噪声因素的方法是自定义规则参数。例如，假设您的团队正在进行 Android 开发，并且您正在检查一条 Android 规则，该规则说“确保小部件不会更新太频繁”。

在默认设置下，此规则识别将小部件设置为每天更新超过 4 次的代码。它通过标记将 `[appwidget-provider]` 标签中的 `[android:updatePeriodMillis]` 设置为小于 216,000 的数字的代码来做到这一点。

假设获取更新信息对您的应用程序至关重要，因此您愿意牺牲一些电池消耗以获得更频繁的更新。在这种情况下，您可能只希望在更新次数超过每天 8 次时收到警告。要实现这一点，您可以简单地将“最大更新时间（以毫秒为单位）”规则参数从 21,600,000 毫秒（6 小时）更新为 10,800,000 毫秒（3 小时）。

如技巧 #2 所述，如果规则没有您需要的参数，您可以编写一个具有这些参数的新规则——或者让您的供应商（或顾问）为您编写自定义规则。

技巧 7：将静态分析规则映射到您自己的术语

您是否厌倦了记住“Security 123”相当于您的“ACME 3.1”指南？“Performance 987”和“Performance 567”都与您的“ACME 5.6”指南相关？即使您的工具说“Threads 123”的严重性是 4 级，但您的组织认为违反该规则被视为非常严重的缺陷？

如果是这样，春季大扫除是映射您的供应商的静态分析规则集以匹配您的团队和/或组织定义的独特策略的好时机。大多数静态分析工具允许您自定义规则的严重性、ID 和名称——以及创建新的规则类别——以便部署的规则能够精确匹配您自己的编码策略文档的内容。

如果您的组织将静态分析作为合规性工作的一部分，这将使您的报告更加轻松。

技巧 8：重新审查和澄清您的静态分析策略

每个团队都有自己的策略，无论是否正式定义。您最好将该流程编码并使其正式化。毕竟，与非正式的策略相比，更容易识别和诊断正式策略中的问题。

理想情况下，您希望您的策略与您当前遇到的（和/或承诺防止的）问题直接相关。这样，无论是总体策略还是其具体实施方式，都有充分的理由。

牢记这些目标，策略应明确

• 哪些团队需要执行静态分析

• 哪些项目需要静态分析

• 需要哪些规则

• 需要何种程度的合规性

• 何时允许抑制

• 何时需要修复遗留代码中的违规

• 是否允许代码带有静态分析违规

技巧 9：扩大分析范围

一旦您清理了杂乱，并且团队已经习惯了进行静态分析，报告的问题很少，并且报告的问题得到了及时清理，您就可以采取下一步行动，扩大检查范围。

扩大检查范围的一种方法是添加更多对您的项目和目标至关重要的规则。要确定要添加哪些规则，请考虑

• 哪些规则似乎最有可能防止消耗团队大量资源的现场报告问题？

• 如果您很快就需要开始遵守行业特定或组织合规性计划，哪些规则将有助于您快速启动工作？

• 当您首次创建或最后一次优化您的规则集时，哪些规则是您最不愿意删除的？

另一种扩大检查范围的方法是检查其他代码。如果您最初设置静态分析工具以跳过遗留文件（例如，跳过在开始静态分析时的“截止日期”之后未添加或修改的任何文件），您可能希望考虑将截止日期提前——或完全删除它。

技巧 10：自动化，自动化，自动化

您能自动化繁琐的静态分析过程的程度越高，它对开发人员的负担就越小，他们就不会分心于他们真正喜欢的更具挑战性的任务。此外，增加的自动化将帮助您在团队和组织中获得一致的结果。

许多组织遵循多层自动化流程。每天，当开发人员在 IDE 中编写代码时，他或她可以按需运行分析——或者配置一个在后台持续运行的自动化分析（就像拼写检查一样）。开发人员在将新代码或修改过的代码添加到源代码控制之前，会修复这些违规。

然后，一个基于服务器的进程会仔细检查签入的代码库是否干净。此分析可以作为持续集成的一部分运行，也可以每晚运行，等等，以确保没有遗漏任何内容。使用这种基于服务器的流程，避免旧的发送电子邮件给开发人员的模式很重要。有效工作流程的一部分是将错误消息分发到开发人员编写代码的同一 UI。电子邮件会强制执行额外的步骤，导致错过违规、浪费时间查找文件中的正确行，以及更多的程序员怨恨，因为他们觉得自己在做一些超出常规流程的事情。

为了通过自动化进一步优化工作流程，请考虑

• 自动将每个报告的问题直接路由给负责的开发人员——以及自定义问题优先级以适应您的策略优先级——以确保您的最关键问题得到及时处理。

• 集中配置管理，以确保规则集得到一致应用，并能在优先级和流程演变时轻松更新。

• 在可行的情况下，利用自动化的“快速修复”重构来帮助团队尽快纠正规则违规。