At the end of January I am going to talk in Agile Practitioners 2015 TLV. I’ll be talking about Legacy Code and how to approach it. As the convention’s name implies, we’re talking practical stuff.
So what is practical in working with legacy code? Is it how to extract a method? Or maybe it’s how to introduce setter for a static singleton? Break dependency? There are so many actions to make while working on legacy code.
But I want to stop for a minute and think. What does it mean to work on legacy code? How do we want the code to be after the changes? Why do we need to change it? Do we really need to change it?
Definition
Let’s start with the definition of Legacy Code. If you search the web you will see definitions such as “…Legacy code refers to an application system source code type that is no longer supported…” (from: techopedia)
People may think that legacy code is old, patched. The definitions above are correct (old, patched, un-maintained, etc.), but I think that the definition coined by Michael Feathers (Working Effectively with Legacy Code) is better. He defined legacy code as:
Code Without Tests
I like to add that legacy code is usually Code that cannot be tested. So basically, if 10 minutes ago, I wrote code which is not tested, and not testable, then it’s already Legacy Code.
Questioning the Code
When approaching code (any code), I think we should ask ourselves the following questions constantly.
- What’s wrong with this code?
- How do we want the code to be?
- How can I test this piece of code?
- What should I test?
- Am I afraid to change this part of code?
Why Testable Code?
Why do we want to test our code? Tests are the harness of the code. It’s the safety net.
Imagine a circus show with trapeze. There’s a safety net below (or mattress). The athletes can perform, knowing that nothing harmful will happen if they fall (well, maybe their pride). Recently I went to an indie circus show. The band was playing and a girl came to do some tricks on a high rope. But before she even started, she fixed a mattress below. And this is what working with legacy code is all about: Put a mattress before you start doing tricks… Or, in our words, add tests before you work / change the legacy code.
Think about it, the list of questions above can be answered (or thought of) just by understanding that we need to write tests to our code. Once you put your safety net, your’re not afraid to jump. ⇒ once you write tests, you can add feature, fix bug, refactor.
Conclusion
In this post I summarized what does it mean to work with legacy code. It’s simple: working with legacy code, is knowing how to write tests to untested code. The crucial thing is, understanding that we need to do that. Understanding that we need to invest the time to write those tests. I think that this is as important as knowing the techniques themselves.
In following post(s) I will give some techniques examples.
| Reference: | Working With Legacy Code, What does it Really Mean from our JCG partner Eyal Golan at the Learning and Improving as a Craftsman Developer blog. |
