Intro
When being an engineer longer than one year, having experiences to handle code written by other people is a common issue. With any luck, when handover, well-documented specifications and senior members would help you get over any challenge in the situation.
I'm Tetsu, the Akerun Android team member. Today, let's talk about the unlucky situation and how I faced (and fixed!) it at Photosynth.
Overview
- Why need to face legacy code?
- How to handle it?
- Finally fixed!
Why need to face legacy code?
"Hey, the code is so dirty, let's do refactoring!" or "No, it's impossible to refactor it, making a new one is easier." These kinds of conversations are common for engineers, but why do we need to tackle it? just for code quality?
My answer, the legacy code has provided values to users already-- and maybe from now on. But the legacy code brings challenges to engineers when we want to deliver more values quickly. So we need to consider how to face it. This answer sounds common? However we must tackle it anyway. ;p
(I also recommend a video talking about the importance of having "why" questions in our job. I hope this would worth to take your time) www.ted.com
How to handle it?
Now we confirmed the reason why we need to tackle a legacy code. The next step---we have to sort out the current situation. I would like to show an example at Akerun Android:
- We have a project to improve the Akerun app's UI/UX.
- Having not so much time to do code refactoring.
- No architecture policy and full of smelly code.
Hmm... I want to show an ideal case first, and escape from the real world...
Here is an architecture diagram in Akerun Android we want to have.
This looks perfect!
Usually, we choose the domain layer (user story, business logic) or frequently feature (like account register/login) first if no exception in refactoring. But in our case, UI/UX improvement is the most important task we want to deliver to users, and refactoring the domain layer is not the better way with limited time.
Now, back to the real world, we consider a “plan B”, which does not aim to refactor all things at once, but focus on refactoring the UI/UX improvement tasks only.
Finally fixed!
Here is an overview of the “plan B” (which we have actually done):
We focused on the UI/UX tasks and refactored it to multiple feature-modules and a UI-component-module without changing almost all domain & data layers.
It was unsophisticated yet and was not ideal.
But it became better, huh?
Outline the actions:
- Draw a blueprint that your team want to realize
- Check the blueprint if it fits your objective
- Keep enough buffer for unexpected incidents
Hope this article will provide you with any ideas when facing legacy code.
Thanks for your time!
By the way, we always welcome our new colleagues!~ hrmos.co
Please join us and let's innovate peoples’ lifestyle together.
P.S. For the limited time issue, another important part is to secure additional time to improve the team's overall working efficiency.
As examples, we did in the past year:
- Use the CircleCI tool to run unit tests.
- Add DeployGate Gradle task to distribute binary automatically.
- Use Danger + Klint to improve code quality without human review.
- Make a reusable UI component to keep UI/UX’s same behavior.
This makes our work quickly/easier and we can focus on more challenging tasks.
