Every programmer, I guess, would meet the code from others that you have never contributed to. And one of the ways to distinguish experienced programmers from beginners is to see if they can quickly dive into the legacy code and maintain, develop, and refactor it in the right way.
There is no silver bullet to approach it, I’ve also been caught in the nightmare of not being able to read the code at all. But I have some tips from my experience to guide you to master it step by step. Hope it would be helpful.
It’s very lucky if there is some detailed documentation, or if the person who wrote the code is still around. This can save you a lot of time, but of course the best way is that the previous team can help you walk through the whole codebase.
In this stage, you’d better know:
if there are no docs and no person was responsible for it available, promise me, please do not get angry and smash your keyboard :)
Learn by doing is always the fastest way to master code. For instance, if the legacy code is for the front-end, you can just change the Button style, if it’s for the back-end, you can just replace the response, that’s the easy but effective method to:
These small bugs or tweaks allow you to get better familiar with the code, especially if you are really confused and have no idea how to start.
If you do not want to make things more complicated, then keep your new code clean. To follow the Unix philosophy, make each function do one thing and do it well.
You can’t control the quality of the inherited code, but you can make sure the code you add is the style you love.
I know every developer can’t help trying to rewrite the legacy code, but it usually brings much undesirable behavior.
Every time when I have to rewrite some functions, I will imagine the code taken over is a black box full of magic (and it always is!) so that I will be careful with each input and output.
When it comes to interdependent functions, try to control the scope of their impact, change the code as little as possible, try to ensure that no new bugs are introduced, and keep smooth iterative development.
Maintaining and developing the legacy code is a progressive process. When you have to rewrite it, don’t rush to completely overturn the previous code first, try to take it apart first.
Dividing code makes you understand the code logic totally. You could keep the input params and output as simple as possible. Roughly split first, and then split again on top of that until it is minimized.
The advantage of this step is that any future refactoring of your code will also bring minimal impact.
Best practices for refactoring are written in many books, but I still recommend doing it on top of completing the previous step. Which will take weeks, months or possibly years depending on the complexity.
At the same time you need to keep up with the speed of developing new features, so it’s a trade-off. I know that refactoring parts of the legacy code can improve the speed of writing new code, but it can also be more of a burden. It needs much patience to take your time and get the refactoring done.
In short, don’t rush to overturn all the old code, but change it little by little, modularize and optimize it. Which like eating a pie, starting from the edges and working your way to the core, little by little.
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。