Changes in a system can be made in two primary ways.
Edit and Pray is pretty much the industry standard. When you use Edit and Pray, you carefully plan the changes you are going to make, you make sure that you understand the code you are going to modify, and then you start to make the changes. When you’re done, you run the system to see if the change was enabled, and then you poke around further to make sure that you didn’t break anything. The poking around is essential. When you make your changes, you are hoping and praying that you’ll get them right, and you take extra time when you are done to make sure that you did.
Cover and Modify is a different way of making changes. The idea behind it is that it is possible to work with a safety net when we change software. The safety net we use isn’t something that we put underneath our tables to catch us if we fall out of our chairs. Instead, it’s kind of like a cloak that we put over code we are working on to make sure that bad changes don’t leak out and infect the rest of our software. Covering software means covering it with tests.
Cover and modify means coding with tests, when we have a good set of test around a piece of code we can make changes and find out very quickly whether the effects were good or bad. Testing this way is “testing to attempt to show correctness“.
“Testing to detect change” is called regression testing. We periodically run tests that check for known good behavior to find out whether our software still works the way it did in the past.
Unit testing is one of the most important components in legacy code work. System-level regression tests are great, but small, localized tests are invaluable. They can give you feedback as you develop and allow you to refactor with much more safety. And we want unit testing because large tests have the following issues.
Issues with larger tests:
- error localization
- execution time
- Coverage. Its hard to see the connection between a piece of code and the values that exercise it.
Here are qualities of good unit tests:
- They run fast.
- They help us localize problems.
The main issue when making unit testing is the breakage of dependencies, legacy code can or cannot be as easy to segment as one might think sometimes but when we are looking for change we have to leave the aesthetics to the side some of the time, if you come around code that was altered this way you can heal the scar.
THE LEGACY CODE CHANGE ALGORITHM
When you have to make a change in a legacy code base, here is an algorithm you can use.
- Identify change points. Where is the code you need to change?
- Find test points. Where is the place to put your test?
- Break dependencies. How to get past dependencies problems.
- Write tests.
- Make changes and refactor.
Michael, C. (2008). Feathers. Working Effectively with Legacy Code.