Small Steps To Refactoring Legacy Projects
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 ? ], gave a No pain Guide to maintenance of legacy project and explained How to rewrite a legacy project and stay alive.
Today I will discuss the compromise, projects that have new features added to them and we know we need to rewrite but we don’t have the resources right now.
Unfortunately this is the reality for most projects. Managers aren’t keen on sparing the resources for a proper rewrite.
But if we don’t take small steps to refactor the project, we end up with unmaintainable code.
So, what can you do?
Know where you’re going. The first place to start is by spending the time to do the design stage, understand how the project would look like if you wrote it today. It’s an effort, but not as big an effort as rewriting the full project.
I suggest going over the first 4 steps from my previous post, you will end up with a plan of where you want to go.
Move new features. Try to see if you can already create the new system (or maybe just a skeleton of the servers you need right now) and write new features there. You will gain a huge advantage of writing the new code faster, properly and maybe even in a different language using different technologies.
Keep in mind you will pay a penalty of interactions between both system. There will be network penalty, but maybe also a penalty of supporting some old networking technology the old system uses (At wix we had a new system support SOAP calls made by the old system).
Make small steps. Allocate regular time to dedicate to the project . Improve tests, make small refactors, remove deprecations and dead code.
Whenever you work on the project — make sure you improve it.
Make a rule not to commit new code that is not tested, This will force you to fix tests for older code as well.
You can also gamify it, suggest a score point competition to the team for making the most improvements to the old system. It’s a great way to encourage people to do tedious work
Ask for help. It’s the companies interest to improve those projects, ask for help from management. They might not be able to allocate a developer for a year to work on this project but they can have someone lend a hand for a week or two. We tried that at Wix and it did wonders. For a few weeks we had two developers come help each week. It didn’t frustrate them because it was only a week, they were very motivated to help and it did a big difference.
Big bugs are an opportunity. If you have big bugs that will need a few weeks work on the system it might be an opportunity to move the flow they are on to the new system.
Use any opportunity you have to move code to the new system. any task that is a few weeks long is a great candidate for a move.
Working on legacy projects is frustrating, and in a perfect world they would all be rewritten. But this is our reality and you don’t need to suffer, you can be proactive and improve the code.
I think those steps can ease you life and can lead to a full rewrite in the end.
That is the end of my 4 post series about legacy project. I hope you found it helpful.
I would love to help you if you have any q or you want to consult: dalias@wix.com
you’re welcome to follow me on twitter
