Static code structure analysis

Axon Framework
1

Hi :wave:,

for the past couple of month I was (and am still) working on a fully automated code-graph-analysis-pipeline in my free time. I have chosen AxonFramework to get started with a concrete code base because it is open, it is not too big or small, I know it a little bit but not too well and it is very well structured.

I’m still working on this and trying to improve it. I’ve seen some copy&paste issues in the reports (I’ll fix them). I also try to make it work with larger code bases and hopefully can also get some visual graphs into the reports. So stay tuned… :eyes:

Examples

Selected Reports

Cyclic Dependencies

A classic static code analysis feature is the detection of cyclic dependencies.
The following steps could resolve some of the cyclic dependencies. They aren’t guaranteed to do so because moving classes can lead to other cyclic dependencies as a consequence. These suggestions are based on AxonFramework-4.8.0 InternalDependencies (table 3)

Interface Segregation

This is a less common analysis. At least I couldn’t find anything like that in commonly known tools. The following (selected) step could help to improve encapsulation and extensibility by applying the Interface Segregation Principle. On the downside this could lead to additional complexity by abstraction. So careful with these… :slight_smile: This suggestion is based on AxonFramework-4.8.0 InternalDependencies (table 3b)

  • CommandMessage declares or inherits 11 methods. 19 types only use the method getCommandName. Either could they be changed to only use the return type of getCommandName without any reference to CommandMessage, or a new interface could be introduced that provides just getCommandName that can then be used instead at these code locations. The latter change could be introduced without any breaking changes.

Graph Data Science

It gets really exciting when applying Graph Data Science to get even more information about the structure of the code:

1 Like
2

It’s interesting and funny to see the deadline handlers all similar. They are mostly made from copy-pasting, so it doesn’t surprise me. I’m not sure about some of the suggestions from a semantic perspective. Also, as we want to move to work on Axon 5, chances are slim we will pick them up.

3

Hi @Gerard,

thanks for your thoughts about that.

It’s interesting and funny to see the deadline handlers all similar.

Note that in this case Similarity is determined by the nodes and their neighbors (dependencies) and not by the actual code (e.g.duplicate code).

I’m not sure about some of the suggestions from a semantic perspective. Also, as we want to move to work on Axon 5, chances are slim we will pick them up.

You’re right. The suggestions are purely derived from data / the query results. They can give some ideas, a starting point or show spots in the code that aren’t that obvious. What is best for the code will still remain in the hands of software engineers.

What I find exciting about graphs is their ability to have a look at the whole but with different points of views. And this leads to thoughts about the code, that might not come up normally.

Since it is no problem to query annotations, this could also be used (as done here already with other tools) to get an overview of which command leads to which event.

1 Like
4

:newspaper: Some news on this:

I’ve published the first major release v1.0.0 of the code-graph-analysis-pipeline :tada: and v1.0.1 fixes a graph visualization issue.

Newest results: AxonFramework-4.9.1 reports

There are now more than 130 CSV reports and 9 Jupyter notebook reports. Everything is fully automated and runs locally as well as in a GitHub Actions pipeline.

Some of the new reports:

Since the results are very detailed it is more considered to be an expert tool for now :wink:.