Refactoring Legacy Assets With Agile
Working with legacy assets can be difficult. You will start out with fear, uncertainty, and doubt (aka the FUD factor) and you will probably question if it is worth going through the trouble of touching old code. It might be tempting to just leave a legacy system alone and just write new code for what you need. Initial estimates for understanding and making code changes to legacy modules are likely to be gross underestimations. Good news – this won’t be the case forever. You will find that as you add regression tests and pay down technical debt in your legacy systems become the number one place you go for reusable assets. The inertia against making code changes will be high initially but over time this feeling will diminish. Your ability to refactor legacy code and analyze legacy processes improves over time.
You are doing right if…
- Your refactoring tasks are prioritized with the rest of your tasks for the iteration (maybe your coach or tech lead can help you with this).
- You identified the legacy asset changes, implemented them, and reviewed them iteratively. Getting the changes right with a legacy asset the first time isn’t realistic for most teams.
- Is there a single place to find all reusable assets? Is it accessible by all team members? If you have a geographically distributed team can they get to this?
- Do you have a plan for how this asset is going go be packaged, deployed, and consumed?
- Everyone in the team is aware of the new reusable asset and they know how to use it
- Every reusable legacy asset is either refactored fully or wrapped and consumed
Here are some warning signs to watch out for while building reusable assets from legacy systems:
- More time is spent documenting what is wrong with a legacy asset rather than coming up with the refactorings needed.
- It takes weeks for you to identify what the legacy asset does or what it is coupled with (hint: ask your team for help. You could be surprised how much undocumented knowledge is locked up!).
- The refactoring tasks are completely irrelevant to what your team is working on for the iteration (hint: the refactoring is either a waste of your time or your team isn’t communicating).
- The legacy asset changes are made without creating automated tests.
- The newly crested reusable asset has no documentation. No one knows what it really does.
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)