How to reconstruct the class explosion caused by m*n strategies?

background

Receive an invitation from a friend to write an article on the specific problems they encounter , The problem is that

friend :

Our company has connected M Three party services   Then there are N Business   It feels like a bit of a class explosion when implementing strategies   I can't think of any good way   This is what I thought of when I just received a demand for reconfiguration payment this morning   There are too many strategies implemented according to the business and suppliers [ dizzy ]

I :

The initial feeling is that it should be solved by building an access platform

friend :

I didn't think about it at first   The code is hard to say [ Over your face ]   Thank you, Miss Xie

I broke down the following questions from the conversation

1、 Understand refactoring 、 Rewrite and restructure

2、 How to refactor ？

3、 How to balance the refactoring process and business support ？

Now I will discuss these three issues .

Understand refactoring 、 Rewrite and restructure

Refactoring is the progressive improvement of code and functionality ; Rewriting is to destroy it , Rebuild ; Restructure to make changes and redesign on the large framework , Each implementation module may use the original .

for instance , Building blocks . Refactoring is that I build a pony with building blocks , I found that some parts of the pony were not good-looking , I will adjust a few blocks , Make the pony look better ; Rewriting is that I build a pony with building blocks , I found that I didn't like it when I built it , Push the building blocks until they are rebuilt , Since it's a remake , It's hard to tell how far the built thing is from the original one ; Re architecture is that I built a pony with building blocks , Find out that you actually want a small bridge , There is no need to push it all to redo , Instead, you can draw the design first , And then directly remove the four legs of the pony to make a pier , Part of the bridge deck is made at the back , If it is really useless, remove it and reinstall it .

Refactoring is the process of trotting , If there is no change in the functions provided externally , This is a safe way ; Rewriting is often accompanied by functional upgrades , Otherwise for “ I don't know what this code is for, but I dare not delete it ” It's hard to guarantee that the functions provided externally will not change .

Refactoring and rewriting are not directly related to the amount of modification . There is a philosophical problem called “ The ship of Theseus ”, It means that a ship continues to sail at sea , Some parts of the ship are constantly aging or damaged for replacement , Eventually all the parts of the ship were changed , Is the ship still the same at this time ？

So let's stop worrying about concepts , Use the word refactoring uniformly , Focus on how to solve the problem .

How to refactor

First, a life cycle estimation of the system is required , Include ：

• Prediction of future demand

• Module division and disassembly

• Sum up historical issues

Friends say ：“ I didn't think about it at first   The code is hard to say ”, In fact, there is no need to think so . Architecture and code are not designed , It's evolved . If I had to do it at first , After a while , You may also encounter the same situation that you feel you must refactor . Although I will definitely make a prediction of future needs , But in reality, there are often many exceptions , Let the program be full of compromises .

That's for my friend's problems , How to design more reasonably ？

Payment restructuring

If only the payment part is reconstructed , Personally, I think it's relatively easy . Because the elements needed for payment are more abstract , It is mainly about what downstream payment channels need . Since the establishment of the Internet , Now the docking party is fixed . Directly connect to Internet connection or wechat payment 、 Alipay pay 、 Lucia Lacarra …… They all need the same elements . Because they all have to access the Internet to meet the needs of national supervision , Therefore, the elements mainly depend on what elements are required by the Internet connection .

Of course , They may be signed differently ; The address of the payment channel called is different ; The input and assembly methods are also different when transferring to the payment channel . Even some payment channels need special steps . At this time, how to abstract ？

recommend “ workflow ”+ The strategy pattern . This is a way of building blocks . Define a unified interface , such as

class Executor {

      void execute(Task task);

}

task Put all the input parameters in the , And the result of each execution , Intermediate data required downstream . Signature and other processes implement this interface respectively . In this way, the reuse of free assembly is realized .

for instance , below “ Building blocks ” Each has realized its own execute：

Wechat payment signature 、 Wechat payment participates in the assembly 、 Wechat payment result analysis 、 Alipay payment signature 、 Alipay pay into the assembly 、 Analysis of Alipay payment results 、 Special treatment by Alipay 、 The downstream http call ( It is assumed that wechat and Alipay are both http Of post Request to call , In this way, the request address and the input parameter are different for initiating the call ）

At this time, wechat payment process can be assembled ：

List list = new List();

list.put( Wechat payment signature );

list.put( Wechat payment participates in the assembly );

list.put( The downstream http call );

list.put( Wechat payment result analysis );

for(Executor e ：list) {

    e.execute(task);

}

Alipay payment process can also be assembled ：

List list = new List();

list.put( Alipay payment signature );

list.put( Alipay pay into the assembly );

list.put( The downstream http call );

list.put( Analysis of Alipay payment results );

list.put( Special treatment of Alipay payment );

for(Executor e ：list) {

    e.execute(task);

}

The different processes are just list Different , This list It is time configurable , It can be configured in the configuration file 、 You can even read from the database . Wechat payment process and Alipay payment process are two different strategies , You can use the strategy pattern . The input parameter selects which strategy to use . such , There is no interference between processes , The change of building blocks has little impact and can be combined at will with high flexibility .

Overall reconstruction

The complexity of a friend's business is not payment , It's about acquiring . The solution is to access the platform mentioned at the beginning of the article . The key to building a platform is not technology , It's norms . Make your own specifications . Others should access according to the specifications .

There is a premise ： The influence of the company itself . The platform is the bottom layer and needs to have decision-making power , For example, wechat open platform , If you want to access, you need to understand and use their API. Because wechat is based on , It must be done according to what others say , This is the platform influence .

In practice , There are generally two situations . The access party does not have any specifications , The function itself is required to be available , At this time, we have our own rules , The other side is more receptive . another , The other side is a large company with strength background , It also has its own norms . At this time we are in a weak position , Follow the rules of others , It can be combined using the above building block method of payment refactoring .

How to balance the refactoring process and business support ？

In the process of refactoring, there are usually two thinking hats ： One is the hat of demand , One is a reconstructed hat . How to allocate the limited time ？ It is recommended to set goals at the beginning ： At what stage and to what extent , Then break down the work . Finally, it is allocated to each day, such as the need for 2 Hour time . Then the time should be deducted when evaluating the requirements development time .

Refactoring completed , There are risks in moving from old logic to new logic . My advice at this time is ：

First , Use the new functionality as a litmus test of the refactoring results . New features , First, verify the correctness of the new logic on the new function . Because there is a process from the launch of new functions to the upgrade , If something goes wrong in the early stage, the impact will not be great .

then , Old logic migration requires grayscale . You can perform grayscale migration from one service to another , You can also migrate by traffic percentage .

summary

Finally, some suggestions for refactoring are summarized ：

1、 Small step run , Iterate steadily

2、 Design goes hand in hand with code refactoring

3、 If a module or function can't think of a good name , It is likely that there is something wrong with the design

4、 Each step should be simple enough , Imagination may stop at any time