2024 Public Training Schedule
November 18 – 21, 2024 – Agile Analysis and Design Patterns
Half-Day Sessions
December 9 – 12, 2024 – Agile Analysis and Design Patterns
Half-Day Sessions
Follow me on Twitter:
Blog Post Categories
- Announcements {19}
- Articles {2}
- Bits and Pieces {74}
- Blogosphere {1}
- Bonuses {2}
- Build in Small Batches {27}
- Collaborate {38}
- Create CLEAN Code {34}
- Implement the Design Last {11}
- Integrate Continuously {30}
- Off-Topic but Interesting {3}
- Rants {82}
- Refactor Legacy Code {24}
- Say What, Why, and for Whom Before How {22}
- Seven Strategies {38}
- Specify Behaviors with Tests {17}
- Write the Test First {27}
Archives
Privacy Policy
(c) 2024 To Be Agile
- August 29, 2018
- Refactor Legacy Code
In my last blog post, I shared with you my favorite refactoring and it might not have been what you were expecting. I can’t leave the topic without sharing with you my second favorite refactoring, as well.
Like my favorite refactoring, my second favorite refactoring is also a safe refactoring, which means that if you have an automated refactoring tool that supports this refactoring then you can apply it to any legacy code, even when it’s not under test, although you might have to do a bit more work than renaming a method.
Also, this particular refactoring I feel is one of the most important for adding clarity to the domain model and making code much more understandable. Have I piqued your interest?
Well, my second favorite refactoring is Extract Method.
Extract Method is an automated refactoring that allows you to highlight a block of code and extracted into its own method. In the old days of programming when I was learning to become a developer 30 years ago, this was considered to be a poor practice. Back then, the reason that we created a method was so that we could call it from multiple places and eliminate redundancy. Having a method that you only call from one place seemed wasteful because it meant that you were making an indirect call rather than just putting that behavior inline.
My how times have changed. Today we see that inlining code is a poor practice because it can make control flow more difficult to see and it violates the Single Level of Abstraction Principle (SLAP) by having code call out both delegation and implementation details.
Today, I mostly extract methods, not because I intend to reuse them but rather because it gives me the opportunity to give bits of functionality a meaningful name. If you can name a behavior then it makes sense to wrap that behavior in a method with that name. This makes code expressive so it is more readable and understandable.
Wrapping a block of code in a private method with an intention revealing name is preferable to using a block comment around code. Instead of tracing through code we can start to get a sense of the different layers of abstraction that we’re dealing with and if our models are consistent and our entities cohesive then we can more easily identify defects based upon the responsibility where it occurs.
Long methods are the number one hiding place not only for smaller component methods but also for entire classes. When we fail to call out classes, we tend to distort our domain model, making it far more difficult to understand what we’re actually doing. As we start extracting out behaviors and identifying the entities that they belong to then we begin to refine our object model so that what we’re doing becomes clearer.
Previous Post: « My Favorite Refactoring
Next Post: Read, Write, and Refactor »