author ： Ding Yi
A few days ago, I happened to see the content of an online friend , It's said that the old system crashed after changing a line of code , It's really bald . The more successful the company is , The more old systems and legacy code that can't be counted , In particular, code related to basic services , It's a real-life version of a gourd that floats . Start up companies are better , There is no burden of history . We also often refactor old code , If for no other , It's just that I'm afraid it's moldy for too long . It happens that I'm also doing system refactoring recently , Sum up what we're doing and some tips .
Code can get moldy, too
It's not just food that molds , The code will also . We usually call it corruption . The process of corruption happens every day , An urgent need , A new colleague joins in , A perverted problem fix , A co construction project , wait . corrupt , It can never be avoided , Just like the entropy of the universe is irreversible . In the face of corruption , Architects often add a coating . If your system doesn't have an anti-corrosion coating , Think about it now . Even if there's an anti-corrosion coating , Also can not withstand the devastation of the years , It's like hair's thinning out , That's life .
therefore , We need to refactor . It takes a lot of work to reverse entropy , To sort out the messy code again , Make it clear again 、 A state of well-defined architecture .
carding , Or comb
Spend a lot of time sorting out the historical logic before reconstruction , And be careful . The ancients said “ A good workman does his work well , You must sharpen your tools first ”. The logic sorted out is the guiding light of reconstruction . What to discard , What needs to be optimized , What to refactor , Which products need to be repositioned , What are the risk points , After carding, it is basically clear that . It's not just the emergence of logic that brings about , There may also be the direction of Architecture . By combing , Be able to clearly discover business logic , You can even define new domain models 、 value 、 Events, etc. . Think of the Galactic era , Fight with the real-time star map of the galaxy , You know how important it is to comb .
The playback , Contrast changes
After refactoring , The test should cover all aspects of . Now , Playback is very important . Ali also open source a playback tool jvm-sandbox-repeater.GitHub Address https://github.com/alibaba/jvm-sandbox-repeater. Through playback , It can be in the pre launch environment debug Online problem , You can see the actual performance of online real traffic in the pre launch environment . by force of contrast , You can find out what's different after refactoring , In particular, page rendering and persistent data .
After the playback is finished , It can also be used as a quick verification of daily releases . As long as there is no difference between this playback and the last normal playback , Basically, the risk is very small .
framework , Start with the end
Now that we're doing refactoring , In terms of architecture, we should design well . Try to get rid of the intricate historical logic , Design a new architecture . To improve R & D efficiency 、 Reducing maintenance costs is the ultimate goal , All of the refactoring design revolves around this goal . Nothing can't be changed , If not , Then add two better programmers . If the refactoring keeps a pile of shitty legacy code , I don't know the meaning of refactoring . Refactoring is about starting with the end , In the new architecture design , Let legacy code be reincarnated to get new life .
improve , Code refactoring
Good programmers need to refactor existing code more or less from time to time . stay 《 restructure Improve the design of existing code 》 In a Book , The author has given many concrete methods of refactoring . Duplicate code extraction 、 Too long function split 、 Model redesign 、 Encapsulate fields 、 Encapsulation set 、 With State/Strategy Replace type code 、 Methods moving position and many other skills , It's not going to unfold here . I think every programmer should study this book well , And then go deep into code level refactoring . As the book review said “ You shouldn't go through the refactoring manual , But it's important to know what's mentioned in this book 70 There are several reconstruction methods in mind ”.
Speed , A quick victory
A lot of legacy code is already like online loan , Deeper and deeper . The return on the resources invested , It's actually much higher than maintaining old code . The process of refactoring should be fast , During the process, daily needs should be suspended as much as possible . Refactoring is a lot of work , But it's also very fast . If you reconstruct , One side of the line is still changing requirements , It's likely to get into trouble , Even lost online logic after refactoring . It's done , The playback is done , Programmers can quickly refactor as planned , A few more people , Make sure it's done quickly .
State of mind , Calibrated boldness
All the work ahead has been done , Then the next step is to do .
Don't worry about it , Don't particularly . This code does not understand how to do , Change ！ Watch the replay . This code is stinky and hard , Change ！ Watch the replay .
When we change it , Be careful, too , Understand the original business logic . Defy the enemy strategically , We should also attach importance to the enemy tactically . do code review, Let the people who know see the changes together , Or team members to check the gate together .