The Art of Refactoring II: Refactoring For Clarity
With the set of readability-enhancing strategies from Part 1 added to our toolset, let’s apply them to our original code blob and see what comes out of it.
I decided to go the video route with this one. Let me know what you think about this format in the video comments!
Keep reading below the embedded video for a follow-up discussion.
List of readability questions:
-
Is the intent of classes, methods, and variables clear by their names?
-
Are method argument and variable names written with nouns that represent their intent?
-
Do methods use a verb + noun combo to describe the action being performed?
-
Are there any magic numbers that could be replaced with enumerations or constants?
-
Can you see duplicated logic that could be consolidated?
-
Are the methods too big?
The Art of Refactoring Part 3: Refactoring For Abstraction
In most cases, your work can (and should) stop once you’ve got your code as readable as you can make it.
But sometimes refactoring can go one step further.
Refactoring for abstraction.
I say sometimes because it is at this point that that dirty word “over-engineering” can come into play.
Eager novice developers, excited to put some newfound polymorphism lessons into practice, can find themselves tangled up in interfaces and generics that do nothing but add unneeded complexity to the codebase.
We all do it so it ain’t nothin’ to be ashamed of. What’s important to remember is that you can very easily turn your readable code into something so decoupled that it loses it’s cohesiveness.
If you haven’t already, add your email below to get Part 3: Refactoring For Abstraction sent to you and to continue the discussion on overengineering.
This is a topic you won’t want to miss, as a trend is growing against traditional object-oriented programming…