Legacy Code
As a software developer, when I hear the word ‘legacy code’, what comes to mind is code from the past, with functions containing hundreds line of unstructured code which is very hard to understand. If there’s documentation, it usually makes us more confused because it’s never been updated since the first version of the code. In my opinion, understanding and maintaining legacy code is one of the most difficult tasks for software developers.
Although working with legacy code is difficult, it is something we can hardly avoid, because many working systems that we should maintain and enhance, are written as legacy code. Rewriting such systems may be not an option for most organizations we are working at. Clearly, we need some strategies and techniques that will help us conquer the complexity in legacy code. Unfortunately, there are not many books which talk about legacy code, compared to the number of books about designing and programming from the scratch.
When I browse around, I found a very good article from Michael Feathers, Object Mentor, which contained several strategies to work effectively with legacy code. You can find the article in Object Mentor website. From that article, I learn an interesting point that what distinguishes legacy code from non-legacy code is tests. If we write new code without adequate tests, actually we write legacy code. It’s a bit extreme actually, but if you are extreme programming follower, that idea should be familiar. That article then present techniques to add tests to legacy code, which is called test coverings. After that, the authour shows some strategies to make ’safe changes’ to legacy code by breaking some dependencies and add test for each change we make.