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
- March 11, 2020
- Implement the Design Last
Refactoring code is not just changing the design of code without changing its external behavior, it’s also doing it in small, safe steps that are repeatable. This is what elevates refactoring to a discipline that we can talk about and create best practices around rather than just willy-nilly ways of changing code.
It was Martin Fowler’s book, Refactoring: Changing the Design of Existing Code, that turned this practice into a true discipline. His book is now in its second edition and is really a classic for all software developers to read.
Let’s face it, if you write code you need to refactor code. Understanding that there are known transformations that you can bring code through to go from one design to another design safely is for me very freeing because it tells me that I can always change my design later when I know more. I don’t have to get it right the first time.
I think that software developers are under the illusion that they have to come up with the right design first off, even before they have a full set of requirements. Very often our initial requirements only tell part of the story and we end up committing ourselves to design choices that restrict us later from handling new requirements. New requirements mean that the world is changed, that needs have changed. This also very typically means that a design needs to change.
What I find is that most developers don’t have techniques around being able to go into existing code and change it in a safe way and then also be able to validate and verify that the changes they made didn’t break anything. Because of this, I find a huge stigma in the industry around changing legacy code, which is one of the main reasons I wrote my book, Beyond Legacy Code: Nine Practices to Extend the Life (and Value) of Your Software.
When you understand refactoring and know how to go from one design to another design safely and effectively because you have good behavioral tests in place, then you will find it’s easy to emerge good designs in existing systems.
“There’s nothing to fear but fear itself.” This is especially true with legacy code. I find that developers are often scared to touch legacy code for fear of breaking it but that fear is often unfounded. Just by knowing a few simple techniques for working with legacy code, we can learn a system while untangling it. Even the most intractable systems can be improved, little by little, in this way.
When you understand refactoring and design patterns then it becomes doubly good. The patterns become design goals or targets and the refactorings become code transformations that allow you to improve the design and implement the patterns. I think of design patterns and refactoring as two critical tools that go hand-in-hand when doing emergent design.
Note: This blog post is based on one of the “Seven Strategies…” sections in my book, Beyond Legacy Code: Nine Practices to Extend the Life (and Value) of Your Software.
Previous Post: « Understand Test-Driven Development
Next Post: Focus on Code Quality »