Change Preventers
These are smells that make change hard.
Last updated
These are smells that make change hard.
Last updated
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:
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.
Making changes requires many small changes to be made to various classes at the same time.
When creating a new subclass, it may be necessary to create a subclass for another class too.
When multiple pieces of code achieve almost the same thing but with different combinations of data or behavior.