静态代码分析可以帮助实现一致性和避免错误。虽然它的好处得到了经验证据的支持,但要解开这些好处却需要太多的工作。为什么?
我的上一篇文章 讨论了自动格式化。静态分析提供了另一个很好的例子。Atomist可以使引入它不费力气,通过。
什么是 棘轮 ?在最近的Twitter对话中,微服务名人Phil Calcado 提出了一个有趣的观点 ,关于现有项目的检查。
我用来处理这个问题的方法是,有时被称为 "棘轮"。假设一个问题在第一次引入时比较容易解决(lint,测试覆盖率等),让你的预检入测试检查没有添加新的问题,但不要因为现有的问题而破坏构建
最初的红色浪潮已经过去。我们专注于提高未来的质量。我们改变的越多,我们改进的越多。
让我们使用 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的团队范围内的政策可以使你的交付更一致和更敏捷的一种方式。