Change Preventers

These are smells that make change hard.

As mentioned in my first article, some people dislike refactoring because they believe that it does not add any new features or fix bugs, and it may introduce additional risks to the stable old code. This is a valid point. Sandi Metz has also stated that if your project is only used once and never requires any new features or modifications, then code smell might be acceptable. In such cases, we can choose to ignore it and move on. However, in cases where no requirements or modifications are needed, it is pointless to hire a developer. So, I believe that in most cases, new features and requirements keep coming to the developers.

The only thing that never changes is change itself. — D.B. Coulson

Because change is unavoidable and hard to predict, knowing how to do it safely and efficiently is one of the key skills for developers when writing code. Kent Beck, the father of Test-Driven Development (TDD), suggests a specific direction to target when performing the refactoring task.

For each desired change, make the change easy (warning: this may be hard), then make the easy change. — Kent Beck

In short, when your code is hard to change, it might be a sign of code smell called “Change Preventers”. Let's take a look at some common code smells in this catalog:

Divergent Change

When you need to change something in one part of your code, you often have to make many corresponding changes in other unrelated parts as well.

Shotgun Surgery

Making changes requires many small changes to be made to various classes at the same time.

Parallel Inheritance Hierarchies

When creating a new subclass, it may be necessary to create a subclass for another class too.

Combinatorial Explosion

When multiple pieces of code achieve almost the same thing but with different combinations of data or behavior.

Reference

https://twitter.com/KentBeck/status/250733358307500032

https://refactoring.guru/refactoring/smells/change-preventers