Is this an indication of high coupling

Question

I am doing a code review for a commercial software system. I noticed that some user's story and even sub-tasks when are implemented they result in a large code commit and usually end up in changing tens of source code files (java classes, javascript files, HTML, etc)

I expect that when someone implements a subtask or a single user story will only require changing few components. Sometimes the commit can have up to 60 files changed.

Attached a screenshot to illustrate the case

another example

Note: I don't think my question is a duplication of I changed one method signature and now have over 25,000 errors. What now? In my case, I am trying to understand if the software suffers from high coupling or not by looking at the cost of code review. Why changing the behavior of a user story requires many changes in the source code?

Answer 1

Is this an indicator of high coupling?

Maybe.

Sometimes this is an indicator of high coupling because when one thing changes, it cascades along, impacting a bunch of other things.

Sometimes it's an indicator of loose coupling because when you want to do one sizable thing you need to touch all of the different responsibilities necessary to provide a cohesive feature to end users.

Full stack features tend to make this worse, since you get to do the front end, and the back end, and the tests for each, and the contracts for each.

Java tends to make this worse with its idiomatic BlahBlahServiceProviderFactory style need for classes to do everything.

Your need for internationalization will tend to make this worse, since you'll need to separate out resources from the code.

And frankly, code reviews tend to make this worse, since people want to avoid the overhead of the review, and reviewers want cohesive features to review, not small slices with things still in progress.

So while broad check-ins can be a sign of coupling, they're more often a practical side effect of business features necessarily crossing module boundaries.

Answer 2

EDIT: I wrote the following response under the mistaken read that the asker wanted to know whether the widespread use of a Java method by other components was an indication of tight coupling between that method and the components using it (in which case the answer is no, as I replied below).

Now I see that the asker was trying to infer the likelihood of tight coupling in the system on the basis of the review.

The following answer addresses only the former case, but I'm leaving it up because I think it's still relevant to that part of the question.

---

I wouldn't consider this tight coupling. The signature of a method is part of its specification. If I changed String::length() to String::length(boolean derp), it would probably break a lot of Java code out there. You can't expect that changing a method won't cause a lot of errors.

All this indicates is that this method is widely used. If you need to change what the method does, then in most cases you should be writing a separate method, not modifying a method that is already in wide use.