How to love legacy code
At some point in your professional career as a developer, you were dealing with some legacy code — a code someone else wrote some time back, that was turning you crazy and maybe you were complaining about.
Everyone wants to work on new features, using new technologies and learning new stuff, so working on legacy code will just hold you back from reaching what you want. Some can even think about leaving the company if legacy code starts to be a daily basis task, then looking for other challenges can be the obvious choice to take in order to push your career to the next level, and no one will blame you for that.
In this article, I will share my own experience dealing with legacy code and how I managed to change that mindset and make my time working with legacy code enjoyable and fun.
Understand the code
Your team lead handed you a piece of legacy code and ask you to add a new feature on top of it. At first sight, it may seem “gibberish” and difficult to read. This difficulty can even go higher if no documentation is provided or none of the original authors is around.
At this exact moment, you’ll start feeling the responsibility of the task, start stressing and even doubting your skills, especially if the task is critical and/or with a higher priority.
What should you do then, to avoid this situation?
Start by taking a step back and avoid making the code’s style matches your way of writing because trust me, it’s a waste of time.
Instead, try to think from the developer’s point of view and consider that everything you see was done, this way, for some reason-following some logic, it will change the way you see the codebase.
Focus on adding the asked feature and avoid refactoring the code, for now, as it might break some other logics, that are maybe out of the scope, BUT bear that in mind.
Analyze the code
This is where you will conquer the code, shine, and share your knowledge.
After delivering the feature, get back to the code and start reading it, again, but from a refactor point of view, this time. You will understand the code, even more, which will help you identify eligible problems to fix.
List those problems and their solutions in a document (e.g: Confluence) and share it with your team members (developers) and wait for their thoughts and ideas. I usually learn a lot from it.
Gather their feedbacks to complete your document and share it with your lead while defining the high-level effort for this refactor to be done, the gain, and the reason behind it.
This task can be done alongside others you may be working on, it’s good to vary the tasks a bit to not feel bored.
Refactor the code
You might probably not be the one that will refactor/improve the code but your document will be the reference and everyone will give you credit for that, so make sure it is clear enough.
In case you do the refactor, you will then, hit 2 birds with one stone, and not only you will show your value to your lead but you will shine inside the team and the company.
For the worst-case scenario, the improvement can be postponed, de-scoped, or canceled, you will still appreciate the things you’ve learned and taken this initiative will improve your self-confidence.
That was my experience with legacy code that I try to apply every time I face it. It helps keep me busy, excited, and productive at the same. I can assure you that doing so will improve your skills and knowledge and helps you see legacy code from a different angle.
Thanks for your time and have fun refactoring!
