How to carry out "small step reconstruction"?

Here is Z Brother's official account

Five a week 11：45 Deliver on time

Yes, of course , I will add a meal from time to time ～

My number 「227」 From the original

Hello everyone , I am a Z Brother .

I have written two articles about refactoring before ：

• 《 Take over old projects with a long history , dry or run ？》

• 《 Good refactoring methods can get rid of “ Shishan mountain ”》

But these two articles mainly talk about the ways and methods of refactoring . stay Z In my opinion , In addition to ways and methods, there is another point that is also important for refactoring , Is how to achieve “ Small steps to refactor ”.

Because only “ half step ” To reconstruct , To achieve that kind of preparation 、 Preventive effect , Strangle the risk in the cradle .

So-called “ Those who are good at war have no illustrious achievements ”, I don't advocate using “ nulling ” The way to rewrite a new system at some time , It is not only risky but also costly .

But to achieve “ Small steps to refactor ”, You need to pay attention to some details at ordinary times , Now let me share some of my experience .

First , In the final analysis, reconstruction is to repay technical debt . So before small-scale reconstruction, we must first have a better way to deal with technical debt .

I don't know if you've ever had such an experience ：

When coding a function , It is found that there is a logic that needs to be changed in many places if it is considered comprehensively , It may even overturn some of the code that has been written at present , But now there are not so many actual scenes , The current implementation can already meet . Forget it , Let's do that first. , How the follow-up business develops is unknown , We'll see .

This is a very common kind of debt , And this kind of debt is easy to ignore , Because it doesn't make you do anything curvilinear to save the country at the moment , It's just a “ myopia ” Compromise . But once there are more compromises , Subsequent iterations often have many large and small patches to cover scenes that were not considered before , In the end, it's hard to return , Rewritten because the project is difficult to continue maintenance .

As mentioned above “ Large and small patches ” In fact, it is another common debt , These patches are often accompanied by if-else This kind of code appears . You know that ,if-else If there is too much code , Reading to people is very unfriendly .

There are still many technical bonds , I think every programmer can actually recognize . Treat them differently , Finally, the difference of work results between different people will be formed .

Z Brother recommends that you treat technical debt in a simple way . Is to add todo, Then clean up todo As a fixed task arrangement , On a regular basis .

remember todo It seems to be a simple thing , But it's still worth taking time to improve efficiency . Common scenarios, such as ：

1. There are some changes that need to cover multiple places , Then you can use some kind of logo （ I am used to using the current time to the minute ） Let's mark it uniformly , In this way, there will be no subsequent changes. Only half of the changes lead to bug The situation of .

2. Some refactoring may depend on other changes , Then you can also write down the dependent change information , If the place it depends on happens to be in this project , You can also note the relevant file name and method name .

3. Some refactorings may also have some deadline Constraints , For example, we need to xx Complete by , Then you can also note .

I usually use todo The format is ：

//todo： Describe what refactoring needs to be done .（202206121536）. Depend on xxx Method in file xxx. Need to be in 2022.7.30 Complete before

Make notes , The rest is regular cleaning todo 了 , This needs to be arranged according to the current job saturation , but Z Brother suggested , Even if you are very busy , At least 1 Once a month .

Okay , How about this one Z Brother shared with you my views and experience on small step reconstruction .

Refactoring must be the best way to run in small steps , It can not only reduce the risk , In the long run, the cost is also the lowest . The specific method is also very simple, that is to remember todo And regular cleaning .

For some ways and means of refactoring, please refer to the two articles I wrote before .

• 《 Take over old projects with a long history , dry or run ？》

• 《 Good refactoring methods can get rid of “ Shishan mountain ”》

I hope it helped you .

by the way , Finally, I strongly recommend you . Just delete the methods that are not called as soon as possible , Don't keep it and think it may be used in the future . According to my experience for so many years , The probability of using it again in the future is very small , Keeping it increases the cost of subsequent code refactoring . Because when you modify a method or field , And then through IDE When looking for references , These methods that have not been called will also be associated with .

Recommended reading ：

• Take over old projects with a long history , dry or run ？
  

• Good refactoring methods can get rid of “ Shishan mountain ”
  

Originality is not easy. , If you think this article is good , Just 「 give the thumbs-up 」 perhaps 「 Looking at 」 Let's go. , Encourage my creation ：）

You can also share my official account name card with my friends .

If you have anything to do with software architecture 、 Distributed systems 、 product 、 The confusion of operation

Try clicking on 「 Read the original 」