Are You Writing Legacy Code?
Legacy code is often defined as code that has been around for a long time. Wikipedia defines it as code that is no longer supported. So what exactly makes legacy code? Code that is written without tests, even if it was written a few seconds ago, is legacy code.
Do you see that car above? It is old and dilapidated. The owner did not take care of it. The car looks as though it has been left outside for a long time and ignored.
Can you see the parallels in code? Legacy code does not often get changed. Developers are scared to touch it. Changing it might break something. Code that can’t be changed is rotting code. It smells; it warns others to stay far away. Over time, only tiny changes are applied to it as needed. No one dare refactor that code in fear of owning it. You touched it last? You own it!
Code without Tests is Legacy Code
Technology changes. Your awesome design today may be completely outdated in a few years. How do you ensure it does not become that rotting piece of meat that everyone stays away from? How do you prevent yourself from becoming ‘that guy’ that everyone hates because of that big stinking mess that was developed months or years ago?
Great design helps, but that alone won’t do it. Other developers may hastily add to your code. You may have to add a feature after several months and completely forget everything about it.
The only way I know that prevents code from rotting is having a complete set of automated tests around it. Manual tests are not enough! You may know all the tests to run. Perhaps you even document all of them. However, I can almost guarantee not everyone is going to be as diligent in running your test suite as you were when you first designed that code.
Automated Tests Prevent Legacy Code
Let’s fast forward several years. Your hot new language or design pattern is not being used by anyone. You have moved on to greener pastures, and no one that remains understands the code anymore. If you have an automated suite of tests, preferably a suite that gets run whenever code gets committed (and emails developers when those tests fail)… you prevent future programmers from breaking the code. You do them a big favor by allowing them to not have to worry about breaking existing functionality.
These tests can allow others (and your future self) to refactor that code without the fear of breaking something. If developers are proactive, they will even refactor that code every time they touch it as needed, because they do not have to worry very much about breaking existing functionality.
So instead of this…
We get this:
Be kind to your fellow developers, and let them modify and add features to your code without worrying about breaking it!