...
The Legacy Code Dilemma
When we change code, we should have tests in place. To put tests in place, we often have to change code.
A structured way to change legacy code
The stepwise procedure:
- Identify change points.
- Find test points.
- Break dependencies.
- Write tests.
- Make changes and refactor.
Common problems in changing software
- I Don't Have Much Time and I Have to Change It
- It Takes Forever to Make a Change
- How Do I Add a Feature?
- I Can't Get This Class into a Test Harness
- I Can't Run This Method in a Test Harness
- I Need to Make a Change. What Methods Should I Test?
- I Need to Make Many Changes in One Area. Do I Have to Break Dependencies for All the Classes Involved?
- I Need to Make a Change, but I Don't Know What Tests to Write
- Dependencies on Libraries Are Killing Me
- My Application Is All API Calls
- I Don't Understand the Code Well Enough to Change It
- My Application Has No Structure
- My Test Code Is in the Way
- My Project Is Not Object Oriented. How Do I Make Safe Changes?
- This Class Is Too Big and I Don't Want It to Get Any Bigger
- I'm Changing the Same Code All Over the Place
- I Need to Change a Monster Method and I Can't Write Tests for It
- How Do I Know That I'm Not Breaking Anything?
- We Feel Overwhelmed. It Isn't Going to Get Any Better