为什么你可能不使用静态分析(以及如何改变这种情况)

静态代码分析可以帮助实现一致性和避免错误。虽然它的好处得到了经验证据的支持，但要解开这些好处却需要太多的工作。为什么？

  • 设置开销 . 通常情况下，这涉及到改变许多项目的构建脚本。更糟的是，这种开销是持续的，因为所添加的东西需要维护。
  • 大量的即时工作 。当我们设置静态分析工具时，它们会立即 惩罚我们 ，发现很多问题。当我们有其他事情要做时，这就产生了工作。
  • 如果你拥有的唯一的锤子破坏了构建，你就少用它 。 传统上 ，静态分析工具是在构建管道中应用的。当静态分析可能立即破坏构建时，有一个很大的抑制因素来增加现有项目的静态分析。

我的上一篇文章 讨论了自动格式化。静态分析提供了另一个很好的例子。Atomist可以使引入它不费力气，通过。

  • 在 团队   层面的一致方法，避免重复和随时间漂移。
  • 一个 渐进式 方法，不是立即进行，而是只标记 新的 违反。
  • 一个集成的用户界面，如Slack，以浮现问题，而不依赖构建的破坏。

什么是 棘轮 ？在最近的Twitter对话中，微服务名人Phil Calcado 提出了一个有趣的观点 ，关于现有项目的检查。

我用来处理这个问题的方法是，有时被称为 "棘轮"。假设一个问题在第一次引入时比较容易解决(lint，测试覆盖率等)，让你的预检入测试检查没有添加新的问题，但不要因为现有的问题而破坏构建

最初的红色浪潮已经过去。我们专注于提高未来的质量。我们改变的越多，我们改进的越多。

使用Checkstyle和Atomist进行分级

让我们使用 Checkstyle ，一个常见的Java工具来应用这个。默认情况下，Checkstyle会在一个典型的Java项目中标出很多 个问题，所以消除遗留的噪音是很重要的。

创建一个Checkstyle抑制文件是可能的，但这是一个大量的手工工作。此外，基线是一个普遍的问题，所以最好是独立于Checkstyle来处理它。

Atomist来拯救。

Atomist实现了整个团队一致的政策。准确地决定应该发生什么，然后让你的所有项目都这样做。

为了在所有项目中加入Checkstyle ，我们使用一个 代码检查   目标 。这可以在每个推送上运行，分析项目的状态。它不会阻止或破坏构建。 

const checkstyleReviewer = checkstyleReviewerRegistration({
    checkstylePath: `${process.cwd()}/bin/checkstyle-8.8-all.jar`,
});
const sendMessageToUsers: ReviewListenerRegistration = {
    name: "messager",
    listener: async rii => {
        return rii.addressChannels(`There are ${rii.review.comments.length} issues`);
    },
};
const inspectGoal = withLegacyFiltering(
    new AutoCodeInspection()
        .with(checkstyleReviewer)
        .withListener(sendMessageToUsers));


检查目标配置了 个审查员 。在这种情况下，它包括开箱即用的Checkstyle集成和 监听器 ，它可以路由产生的审查输出。

我们可以通过 推送规则 安排这个目标在任何Java项目上运行： 

sdm.withPushRules(
    whenPushSatisfies(IsJava).setGoals(inspectGoal),
);


接下来，我们需要添加Atomist 扩展包 ，以执行传统的过滤(ratcheting)。 

sdm.addExtensionPacks(legacyFiltering({inspectGoal, autofixGoal}));


基准化

Atomist目标使用Checkstyle命令行来执行分析。 checkstyleReviewerRegistration 功能是Atomist的 Checkstyle扩展包 开箱即有的。

因为我们启用了 "遗留过滤"，Atomist增加了额外的价值，使Checkstyle更容易被采用。

第一次看到对项目的推送时，检查目标将执行一个初步分析，作为基线使用。它使用Atomist的核心 自动修复支持 ，将该分析结果持久化在 repo 中的一个文件中。下面的输出显示了第一次审查时发生的情况。 

# spring-format-sdm Running Checkstyle on ... to establish baseline: file is .atomist/legacyIssues_Checkstyle.json


在随后的推送中，Checkstyle将再次执行，但基线的违规将被忽略。然而，任何新的违规行为 将 被报告。

在几分钟内为你的所有项目添加静态分析

你可以在本地或云端使用这个SDM，对你的所有Java项目应用Checkstyle。只需克隆 https://github.com/atomist-blogs/spring-format-sdm ，签出 checkstyle 分支， npm 安装和运行 atomist start --local 。

当针对云计算运行时，你可以让它提出问题，以及像这样向Slack报告。

进一步的可能性

这种方法允许为 任何 静态分析工具建立基线，允许你在团队层面上投放工具，而不被立即的额外工作所淹没。 如果它有一个API或命令行，Atomist可以在每个推送上运行它 。Atomist集成了开箱即用的流行工具，而且使用 它们作为指导实现你自己的代码检查也相对简单 。

在团队层面上应用检查，而不是一个一个地修改项目，可以帮助你找到理想的静态分析解决方案，满足你的需求。这只是Atomist的团队范围内的政策可以使你的交付更一致和更敏捷的一种方式。
原文链接: Why You Probably Don't Use Static Analysis (and How to Change That)
分享到
相关文章