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 15, 2018
- Refactor Legacy Code
One of my early blog posts that I wrote nearly 10 years ago that I called Sony Baloney discussed how the electronics giant cultivated some unusual, yet highly successful practices. One of the practices that Sony is known for is taking young and inexperienced engineers and putting them on new product development, while their senior engineers focus on reworking and redesigning their successful products to be more cost-effective. I consider this to be a very wise practice and so do they.
We want innovation in new products but we always want to balance it so that our work is maintainable and cost-effective. The electronics industry pays a lot of attention to this because manufacturing is expensive. Of course, there are no manufacturing costs, per se, in the software industry but there are maintenance and ongoing costs for software and that’s actually where the bulk of our funds are spent. So, paying attention to the maintainability of our code is quite important yet often overlooked.
We don’t have many common standards and practices around developing software and so while software systems may be functional they are often very difficult to maintain. Most existing systems have accumulated a great deal of technical debt, which makes it difficult to work on, and in many organizations, there is a stigma around touching legacy code. This happens for good reason because when developers touch legacy code they often break it and that can be costly to an organization and embarrassing to the developer so our preferences to leave legacy code alone and when we have to go in to change or extend legacy code, we try to do it as minimally invasively as possible.
I realize that we mean well but this is often not the right choice. Surgery, if done improperly can cause great injury to the patient but that doesn’t mean that every time we do surgery to remove a tumor that we should only take a part of it. In software, providing just half a solution can be as fatal to a system as removing half of a tumor in a patient.
Surgeons have figured out how to do the impossible and open a person up so that they can remove a disease. I’m sure there are many important rules and caveats around doing this safely. I would never attempt to do surgery without first going through the process of becoming a doctor, no one should.
The same thing is true when doing “surgery” on an existing legacy system. We have to understand the root causes of problems in poor code and insufficient designs so that we can find safe and effective ways of remedying a situation.
Once we know some basic refactoring skills then it’s just a matter of applying them to improve the code. One of our main goals, when we refactor, is to make the design clear and straightforward. Doing this may include renaming methods and fields so that the intention of the extracted code is clear, and even extracting entire classes from methods if needed. As we do this, we call out missing components from our domain model, thus filling it in and making it more robust so it’s more understandable when we work with it in the future.
Previous Post: « Sharing Knowledge
Next Post: My Favorite Refactoring »