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


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

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

我的上一篇文章 讨论了自动格式化。静态分析提供了另一个很好的例子。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的团队范围内的政策可以使你的交付更一致和更敏捷的一种方式。