How To Rewrite A Legacy Project And Stay Alive
In my previous posts I explained why we should only maintain legacy projects if no new features are added to them [Legacy, isn’t that a good thing ? ] and gave a No pain Guide to maintenance of legacy project.
Today I will share with you some points to think about when rewriting a legacy project. It’s not a recipe, but it’s questions to ask yourself and steps that will get you in the right direction.
Allocating resources is the place to start any big rewrite. This is also the point where most rewrites end. It’s easier for managers to agree a project needs a rewrite than sparing resources for it.
The key to pass this stage is remembering that the time and effort invested now will be gained in the future:
- new features will be written much faster
- Code flexibility will open new product opportunities
- It can make production debugging easier
Another open q is who should we assign this task to? Choosing a junior developer with a lot of motivation can move the project forward because he will want to impress. On the other hand an experienced developer will identify problems faster, she might also remember design decisions that were made on this project.
The show must go on. For a large system we cannot stop the world while we work on the rewrite. There are always bugs to fix , new features to add and we don’t want to write code twice. That is why the rewrite must be done gradually and the two systems have to co-exist. That means:
1. Data should be shared
2. We need to move one flow at a time
3. New features will be written in the new system only!
Identifying your flows is a tricky part, especially if your project has a lot of dead code in it. I suggest to identify the main flows first and move them to the new system. Then you can use your monitoring tools to find flows you didn’t know about.
Discuss limitations. Each project has its own limitations. Some examples are limitations on the technologies you can use, of other projects you interact with or your hardware .
Discussing them can affect you design!
At this point you have enough data to plan your architecture.
Working on each flow. Start by understanding what the flow does, Don’t take anything for granted — design decision that were made before might not be relevant anymore. Make sure it makes sense to you. If not, ask the question: Why are we doing this? Is this a business need or was this a limitation of the old system?
Once you understood what the flow does:
- write a sunny day E2E test
- Add a unit test for each branch you found in the old code.
- Copy the code and make sure your tests passed.
- Refactor. Now that you have proper tested code and you can refactor. Make it readable, extract classes, change a library or technology if needed.
Slowly and gradually shift traffic. Think how you’re going to move the new flow once it’s done. It is a good idea to use an experiments system to gradually move traffic for this flow. It can also enable us to run QA on production (Either manual or Automation).
Caring for the old system
We need to keep the build of our old system green and keep deploying it to production. We also want to update dependencies (if it’s not painful).
But what should we do with bug fixes ?
If they are urgent we will fix them in the old system. For other bugs we need to use common sense: small bugs we might fix in both systems. For big fixes we need to consider moving their flow to the new system and then fixing it there. It depends how much time we have to fix it.
You need to stay committed to the end!
There will be a point of no return when your customers will feel a difference in the service they’re getting.
Celebrate progress. Since it’s a long rewrite it’s important to share the progress with the team: show how many flows have moved, the amount of traffic and celebrate moving flows with the entire team.
That’s it - You’re all set ! Be brave and take the first step
My next post will be about Small steps to refactoring legacy projects. What to do with projects that need a rewrite but we cannot allocate the resources right now.
you’re welcome to follow me on twitter
