如何通过gradle插件强制执行此模式? [英] How to enforce this pattern via gradle plugins?

查看:65
本文介绍了如何通过gradle插件强制执行此模式?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

随着时间的推移,我们正在努力使代码在项目中保持一致",并遵循这种模式

We are trying to keep our code 'consistent' over time on our projects and follow this pattern

https://blog.twitter.com/engineering/en_us/topics/insights/2019/onepattern.html

对于使用@Entity或@Data注释的任何类,我们考虑这些数据对象,并希望对此进行强制

For any classes annotated with @Entity or @Data, we consider these data objects and would like to enforce that

  1. new关键字不能用于未使用@Data注释的任何对象(即,所有业务逻辑均由guice创建)-这很难!
  2. 只有get/set/is成员方法位于数据对象中(可能与equals一起使用)-这可以通过扫描和反射来完成
  3. 所有不带@Data的对象都用@Singleton(我们在无状态编程)或@ExceptionNotSingleton注释异常(我们在构建无状态系统时非常罕见-可以再次通过扫描和反射来完成
  4. 在业务对象甚至公用程序上都不允许使用静态方法->扫描和反射

第4点是针对特定项目的Web片段,在该Web片段中,由于我们使用该平台,因此可以通过换出该类来修复任何代码中的错误.交换静态方法效果不佳.

The 4th point is for a specific project webpieces where since we use that platform, we can fix bugs in any code by swapping out the class. swapping static methods doesn't work very well.

什么样的工具可以做这样的事情,以便我可以为它提供一个简单的处理器?gradle插件将是不错的选择,我可以在其中添加一些小的代码片段,但是我不确定它是否存在.

What tool can do something like this such that I can feed it a simple processor? A gradle plugin would be nice where I can feed it some small snippets of code, but I am not sure that exists.

我想我也可以向每个项目添加单元测试,然后只需要一个类扫描器即可检查类.

I could add a unit test to every project as well I guess and then just need a class scanner to inspect the classes.

我正在寻找一个插件,也许它带有一些我可以尝试的示例的链接.

I am looking for a plugin perhaps with a link to some examples I could try out.

推荐答案

您在说什么类似于(简化后的)基本思想是将源代码解析为 tree 和然后针对您要查找的特定模式分析该树.

The basic (and simplified) idea is to parse the source code into a tree and then analyze that tree for the specific patterns you're looking for.

例如,在您遇到的情况下,只要在树中看到构造函数调用,就检查目标类是否用 @Data 进行注释.或者,每当您分析一个类时,您都访问其所有方法叶并查找静态变量.如果发现违规行为,请记录下来,并可能破坏构建.

In you case, for example, whenever you see a constructor invocation in the tree, you check whether the target class is annotated with @Data or not. Or, whenever you're analyzing a class, you visit all its method leaves and look for statics. If you spot violations – you log them and probably break the build.

这里的窍门是用AST树中的形式模式来定义规则.

The trick here is to define your rules in the term of formal patterns in AST tree.

大量的Java代码分析器,但恕我直言,最受欢迎一个是 Checkstyle .它们都可以与Gradle一起很好地工作(Checkstyle和PMD都可以),因此,这实际上不是有关构建工具的问题,而是有关扩展分析器的问题.

There are a plenty of code analyzers for Java, but IMHO the most popular one is Checkstyle. All of them probably work nice with Gradle (Checkstyle and PMD do), so it's not really a question about build tool, but about extending the analyzer.

通常,静态代码分析器允许用户使用自定义检查/规则/插件/等扩展它们.Checkstyle也是:阅读有关写新支票.本文详细介绍了AST和导航.Checkstyle还提供了 GUI工具来分析Java类,以帮助查找模式并编写检查.继续进行一些工作,看看是否可以通过AST树跟踪问题.

Usually, static code analyzers allows users to extend them with custom checks / rules / plugins / etc. So does Checkstyle: read more about writing new checks. This article describes the AST and navigation in details. Checkstyle also provides a GUI tool to analyze Java classes to help find the patterns and write checks. Go ahead an load some of you clases there and look if you can track your issues via AST tree.

当您对AST,它的导航,访问者等感到满意时,请去编写自己的检查并将其集成到您的构建中.

When you're comfortable with AST, its navigation, visitors and so on – go and write your own checks and integrate them in you build.

此想法也适用于其他静态代码分析器,例如 PMD SpotBugs (尽管SpotBugs的文档很差).

This idea is applicable for other static code analyzers as well, like PMD or SpotBugs (although SpotBugs's docs are poor).

这篇关于如何通过gradle插件强制执行此模式?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆