标签：添加 配置 重要 反馈 电池 开始 因此 噪声 widget
是否想清理您的静态分析实践？首先，清除导致您难以将精力放在真正关注的问题上的混乱杂事。接下来，通过扩大活动范围以增加对组织的价值来激发您的实践。您的开发团队是否对静态分析工具中越来越多的违规行为感到不知所措？您当前的静态分析配置所产生的高水平噪声是否使团队对所有警报（包括那些您认为关键问题的警报）不敏感？
无论您使用哪种静态分析工具，都可以通过以下10种方法来更新现有的静态分析实现。
检查大量规则并不是通过静态分析获得最佳ROI的秘诀。实际上，在许多情况下，情况恰恰相反。如果您专注于最少但有意义的一组规则，则静态分析实际上可以提供更好的结果。
当您执行静态分析时，就好像您让经验丰富的开发人员站在没有经验的开发人员的肩膀上，并在编写代码时向他提供提示。如果有经验的开发人员在每几行代码中不断挑剔，那么经验不足的开发人员将很快不知所措，并开始过滤掉所有好的和坏的建议。但是，如果有经验的开发人员专注于他知道可能会导致严重问题的一两个问题，那么经验不足的开发人员就很可能会记住所给出的建议，开始编写更好的代码，并且很欣赏收到这种反馈。
静态分析也是如此。如果您保持它的可管理性和意义，那么您最终将更多地教您的开发人员，并让他们对流程的重新关注减少。您是希望遵循一小套规则，还是不遵循大套规则？如果您真的不希望开发人员在收到举报后立即清除违规行为，那么您可能要认真考虑禁用该规则。
如果特定规则屡次遭到违反，那么现在是重新评估您是否真的要继续检查该规则的好机会。过多的违规表示开发人员未按照规则要求的方式编写代码。说服他们改变其编码习惯可能会遇到很大的阻力。
您如何确定解决问题是否值得努力？首先，尝试记住为什么首先要检查该问题。您选择它是因为这似乎是解决您在现场遇到的问题的好方法？作为法规合规工作的一部分？还是仅因为供应商默认启用了它？供应商通常在其规则说明中为每个规则提供参考。阅读这些描述可以帮助您确定该规则是否确实适合您的项目和目标。
接下来，查看是否有其他方法可以达到预期的效果。还有其他更具体的规则吗？有没有一种方法可以微调规则参数，使其不会经常触发？（有关技巧6的更多信息）。您甚至可以考虑编写自己的更合适的规则，或者让供应商为您创建自定义规则。
如果您在重新检查了该规则的好处并探索其替代方法后仍然有兴趣检查此规则，请获取一些开发反馈，以了解遵循此规则可能涉及的内容。然后，您可以使用此反馈来确定要求开发人员遵守此规则是否确实值得。如果看起来工作量很大，却收效甚微，请继续执行并禁用该规则。
在某些情况下，您可能会遵守规则，但希望在某些情况下允许豁免。例如，也许您有一条规则，要求在代码中执行一些额外级别的验证。假设您有一种使用性能关键代码的特定方法，该方法每分钟被调用数百次，并且您已经验证了在调用此特定方法之前已执行了适当级别的验证。或者，假设基于流的分析正在警告您某个严重问题，即您认为100％确定无法在集成应用程序中使用它。这是抑制派上用场的地方。
对于需要检查的情况，抑制是最理想的选择，但是您不关心在特殊情况下报告的问题。使用抑制，您可以继续检查关键问题，而不会收到有关故意违反规则的重复消息。如果您不想因违反特定规则而收到错误消息，建议您完全禁用该规则（请参见第1点）。
通常，您可以从静态分析工具GUI，配置文件或源代码本身定义抑制。在源代码中定义抑制时：
通常，您可以禁止违反特定规则，多个规则或特定类别中的所有违规。您还可以将代码的某些部分从所有静态分析中免除（在此之后的更多内容中）。
有时，对某些文件（例如，自动生成的文件或您不打算接触的旧文件）进行静态分析只是没有意义。在这些情况下，应防止对这些文件进行分析。这是确保您的结果不会因您不打算解决的一系列违规问题而混乱的另一种方法。
有几种方法可以做到这一点。您可以设置路径过滤器以排除您不想检查的文件，或仅包括您想检查的文件。或者，您可以配置工具以跳过包含特定注释的文件，例如，注释指示自动生成的代码。
其他检查重点包括：
在基于模式的静态分析中，误报是违反规则的行为，当代码实际遵循规则时会错误地报告这些错误。例如，如果规则说您拥有未关闭的资源（例如JDBC连接），则实际上该连接是关闭的，那么这是误报。如果您确实要遵循这样的规则，那么春季清洁是将其最终报告给供应商的好时机。
请注意，如果您沿着这条路走下去，则需要确定自己所看到的是误报，而不是简单地遵循自己不喜欢的规则。开发人员经常将消息称为“误报”，因为他们不喜欢该规则，或者感觉不到该规则在这种情况下适用。此类消息不是误报，在这种情况下，您的供应商将无法为您提供帮助。
但是，如果您可以减少一个显示特定规则实际上是如何获得错误消息的简单测试用例，则应该发现大多数供应商在纠正问题方面非常有帮助。
降低噪声因子的另一种方法是自定义规则参数。例如，假设您的团队正在进行Android开发，而您正在检查一条Android规则，该规则要求“确保窗口小部件的更新时间不要太长。”
使用默认设置时，此规则将识别将小部件设置为每天更新4次以上的代码。它通过标记将标签[appwidget-provider]中的元素[android：updatePeriodMillis]设置为小于21600000的数字的代码来实现。
假设获取更新的信息对于您的应用至关重要，因此您愿意为更频繁的更新而牺牲一些电池电量。在这种情况下，您可能只希望每天更新超过8次才被警告。为此，您可以简单地将“最长最大更新时间（以毫秒为单位）”规则参数从21600000 ms（6小时）更新为10800000 ms（3小时）。
如技巧2所述，如果规则没有所需的参数，则可以编写一个新的规则，也可以让供应商（或顾问）为您编写自定义规则。
您是否已经厌倦了Security 123等同于ACME 3.1指南？Performance 987和Performance 567是否都与您的ACME 5.6准则相关？即使您的工具说线程123的严重性为4，您的组织仍认为违反该规则是非常严重的缺陷吗？
如果是这样，“春季大扫除”是映射供应商的静态分析规则集以匹配团队和/或组织定义的不同策略的好时机。大多数静态分析工具可让您自定义规则的严重性，ID和名称，以及创建新的规则类别，以便已部署的规则与您自己的编码策略文档的内容精确匹配。
如果您的组织执行静态分析作为合规性工作的一部分，这将使您的报告更加容易。
每个团队都有一个政策，无论是否正式定义。您最好将过程编成代码并将其正式化。毕竟，采用正式的政策比不采用书面政策来识别和诊断问题要容易得多。
理想情况下，您希望自己的政策与您当前遇到的问题（和/或致力于预防）直接相关。这样一来，总体政策和具体实施方式都有着很好的依据。
考虑到这些目标，该政策应阐明：
清除混乱情况后，您将可以使用团队进行静态分析了，报告的问题很少，而所报告的问题也得到了及时清理，您可以继续进行下一步，并扩展检查范围。
扩大检查范围的一种方法是添加更多对项目和目标至关重要的规则。要对要添加的规则归零，请考虑：
您可以使静态分析过程自动化的程度越高，对开发人员的负担就越小，并将他们从他们真正喜欢的更具挑战性的任务中分散出来。另外，增加的自动化功能将帮助您在整个团队和整个组织中获得一致的结果。
许多组织遵循多级自动化过程。每天，当开发人员在IDE中处理代码时，他或她都可以按需运行分析-或配置自动分析以在后台连续运行（就像拼写检查一样）。开发人员在将新的或修改的代码添加到源代码管理之前清除这些违规行为。
然后，基于服务器的进程会再次检查签入的代码库是否干净。该分析可以作为每晚持续进行的持续集成的一部分，等等，以确保没有任何漏洞通过裂缝。通过这种基于服务器的流程，重要的是避免使用旧的向开发人员发送电子邮件的范例。有效工作流程的一部分是将错误消息分发到开发人员编写代码的同一UI。电子邮件会强制执行额外的步骤，从而导致违规行为丢失，浪费时间在文件中查找正确的行以及对编码人员的不满，他们觉得自己在常规程序之外做了其他事情。
要通过自动化进一步优化工作流程，请考虑：
超实用的10个技巧！让您无论使用哪种静态分析工具都能轻松更新现有的静态分析实现
标签：添加 配置 重要 反馈 电池 开始 因此 噪声 widget
原文地址：https://blog.51cto.com/11855672/2571003
