sagenschneider

Yes, agree very capable of consuming large amounts of information

I'd be interested to see what happens:

- to token counts after a year of so of changes, as the specification list grows?

- how it goes with concurrent changes in teams?

Plus whether asking AI to add good commenting to the code could achieve the same thing?

Yep, not looking to replace cyclomatic complexity. Looking to use it in what I've researched is a novel new way.

Instead of focusing solely on the complexity of the thing you change. Include the context around what you are changing also.

This allows the Change Impact formula to differentiate between two different files of the same length. One is a complex god class with high CC. The other is an entity module that is simple but just has a lot of methods due to properties. Adding to the god class really should warrant a refactor. Adding to the entity class is just another field to store for the entity. The Change Impact formula can differentiate and point to the god classes.

Yes, agree. It's a learning process. I tend to find when I build systems that at some point you need to stop analysis and just start building things to explore the problem. As you do, you prototype, refactor and possibly throw out ideas in favour of understanding the problem and discovery the real solution.

The code becomes a reflection of that.

I'm interested in your experiences of capturing specifications and user discussion on whether this captures the end intentions? Or whether it keeps you focused on earlier dead end directions?

Yes

The research I'm actually doing is comparing:

- mutative architecture (Spring) which as single method handling the request. It grows in complexity as changes are added

- additive architecture (OfficeFloor) which does function injection. A pipeline of functions, where new functionality is an injected function as a step in the pipeline (i.e. adding functions, rather than mutating a single handler function)

What I've found is the complexity of the overall system is what it is. Between both architectures, the overall CC is the same. However, the distribution is very different. Mutative architectures pile changes into god handler method. Additive architectures spread the complexity into smaller manageable files.

This, however, does not come with perfect wins. Spread also means AI doesn't read the dispersed files. AI is good with complexity and tends to fix things when it sees them (so does fix bugs in god classes). But this is only to a certain point when the complexity then comes to overwhelm the AI.

The formula is trying to catch the mess of on going changes at a point before the expensive refactoring or rewriting becomes necessary.

Yes, you are right that looking at one commit doesn't tell you much.

It's looking at the nature of on going changes.

A single complex file written once and never touched is likely a good cohesive file about a single problem solved.

However, if we start making many changes to that file increasing it's complexity, it's likely not the problem getting more complex. It's likely we're adding more purposes to the file, eroding it's cohesion. This is the signal I'm trying to catch to avoid a mess starting.

Most static code analysis looks for bugs or just too complex functions.

The novelty of Change Impact is it looks at the context of the complexity. Adding complexity to something already complex should be flagged for review.

I've not come across any static code analysis so far that has provided this.

And in my own research of architectures, I came to this formula.

Yes, the formula does make some approximations.

The problem with cohesion is understanding what is "single purpose". Nothing can determine this without interpreting the code and making a judgement call on whether it needs to be refactored into two or more classes.

So I'm looking to approximate this. Instead of looking for cohesion, Change Impact formula approximates this by looking at existing complexity in the file.

If the change adds more complex functions to an already complex class, it scores high. Smell of it doing too many things.

If the change adds a complex function to an empty file, it's likely just a complex single problem.

If the change adds simple change to complex file, then if this happens too many times, we flag it for concern. Especially if it changes a lot of other files too.

So it's not mean to measure your code exactly. It's meant to highlight smell that needs investigation. And the formula points out the classes that need looking at.

Plus I'm not sure that all changes are equivalent. I'm not looking at single one off changes. I'm looking at 60 changes in a row. The first 20 might go through fine. However, after the changes pile on, there needs to be some refactoring to keep the code clean. This is trying to catch it before it becomes a mess.

It uses lizard for parsing, so Python, Java, JavaScript, TypeScript, C, C#, Go, Scala, and more.

I'm not looking at building prototypes. Looking at ways to manage code bases after they've gone through hundreds if not thousands of changes.

Comes from the basic Computer Science principals of High Cohesion and Low Coupling.

High cohesion means the functionality of a component are closely related and focused on performing a single well defined task. Basically single classes for single purposes.

Erosion of this is when classes start doing to many things, in the case of God classes.

The Change Impact formula looks at a way of detecting when the cohesion is eroding and flagging it on a change (as the pull/merge request itself should generally be single focus cohesive change)

When you think about a god class or god method, it occurs over time by adding more than a single responsibility.

Yes, there are generally complex algorithms but they usually are not things developers write (imported from libraries).

What is usually going on in the god class/method is that things keep getting added to it. These things should be separated out. So the cohesiveness of the class/method erodes into doing too many things.

The idea of the Change Impact formula is to catch this early so you start refactoring to separate out into classes with single cohesive purposes.

The problem with AI is it handles complexity really well and will happily keep piling changes into god classes/methods reaching ridiculous CC levels (have see over 200). Previously developers would get annoyed and do the refactor. But with AI these days, changes are happening faster. So Change Impact is to try to monitor the cohesive erosion.