Experience in reconstructing the refund business of the city’s after-sales system | JD Cloud technical team

From data to large model application, on November 25th, Hangzhou Yuanchuang Conference was held to share development tips.

1. Reconstructing the background

1.1. Refund

There are two structures for Home Delivery, Hourly Purchase, and Tianxuan Refund , and the code logic is confusing;

Among them, some after-sales orders for hourly purchase and Tianxuan are refunded interactively with Hepingsheng pop, and some are refunded interactively with the after-sales center; and are compatible with 3 sets of logic;

Pain points : heavy code, lack of rational design, high subsequent iterative development and maintenance costs , and increased system risks and instability.

1.2. Amount calculation

There are two independent sets of logical structure calculations for home delivery and hourly shopping. On this basis, two sets of logic are implemented for refund and non-refund ;

The amount calculation for the product part dimension, product line dimension, and after-sales single dimension is confusing, and there is a lack of domain boundaries and hierarchical design ;

Pain points : The calculation of amounts in the after-sales single dimension, product line dimension, and split piece dimension is confusing , and the code lacks a hierarchical structure ; there are problems with code legibility , maintenance costs , and subsequent scalability .

1.3. After-sales reverse account

The after-sales order details interface and the complaint order details interface have two sets of logic for home delivery and hourly purchase;

Among them, the after-sales order details interface has 5 sets of logical processing for hourly purchase blacklist, hourly purchase whitelist, Tianxuan, home refund, and home non-refund ;

Moreover, these two interfaces obtain the amount from the split in real time for after-sales reverse split calculation, and can directly obtain and assign values ​​from the database, without the need for single-dimensional after-sales split calculation;

Pain points : A large amount of code redundancy , high change costs , increased system risks and instability

2. Reconstruction ideas and plans

2.1. Reconstruction ideas

What is refactoring?

Noun : An adjustment to the internal structure of software with the purpose of improving its understandability and reducing its modification costs without changing the observed behavior of the software;

Verb : Use a series of techniques to adjust the structure of the software without changing its observable behavior.

The purpose of refactoring is to make the system or code easier to understand, modify, and iterate

The Secret to Refactoring: Be Bold and Careful

Bold (means having the courage and determination to change and improve existing code. Refactoring may involve modifications to complex code structures, and may even require rewriting parts of the code. Bold developers are willing to face these challenges and believe Changes can lead to better results)

Careful (refers to maintaining meticulous thinking and action when refactoring. This includes carefully analyzing the structure and logic of the code, understanding the function and dependencies of the code, and considering the potential impact that each refactoring step may bring. Careful developers will carefully handle every detail during the refactoring process to ensure the correctness and maintainability of the code)

1. Seize the opportunity to refactor: When I find that the code of business modules such as after-sales refunds and amount calculations has quality problems, poor readability, poor maintainability or bad taste, and when the project demand schedule is not tight , is a good time to refactor;

2. Preliminary sorting is very important. Find the pain points first; it is not suitable to fight in the long term or in parallel with the business.

3. Clarify goals and values: After-sales refunds and amount calculations can be reconstructed to improve development efficiency, reduce maintenance and development costs, etc.

4. Determine the goal of refactoring: First of all, you must clarify the code blocks or functions that need to be refactored, and clarify what the goal of refactoring is. For example, there may be a need to improve code readability, maintainability, or performance.

5. Analyze bad code smells: Use code static analysis tools or manually check the code to identify possible bad code smells ; for example, there are more than 1,000 lines of classes, more than 600 lines of methods, too many variable parameters, and A lot of duplicate code and other bad code smells .

6. Choose the appropriate refactoring technology: Choose the appropriate refactoring technology based on the type of bad smell in the after-sales code and the goal of refactoring. The refactoring techniques I use are: small-scale refactoring-->large-scale refactoring-->top-level design pattern; I use the idea of ​​​​first small then big, and from big to complete to refactor the design . Small-scale refactoring : extract methods, eliminate super-large classes or function methods, extract classes, rename, merge duplicate code, etc.; large-scale refactoring: adopt layering, modularization, decoupling, abstract reusability, etc. Technique; Design pattern : The refund business adopts the strategy pattern + abstract factory; the amount calculation business adopts the strategy pattern + abstract factory + responsibility chain pattern

7. Write test cases: Before refactoring, write appropriate test cases to verify the correctness of the refactored code. Test cases should cover various scenarios of the refactored code block or functionality.

8. Perform refactoring: Modify the code step by step according to the selected refactoring technique. Ensure that each modified code still passes the previously written test cases.

9. Run test cases: After each refactoring, run the previously written test cases to ensure that the refactored code is still correct.

10. Code evaluation after refactoring: Evaluate whether the refactored code has achieved the expected goals, such as whether it has improved the readability, maintainability or performance of the code.

2.2. Reconstruction plan

2.2.1. System interaction diagram before reconstruction

2.2.2. System interaction diagram after reconstruction

 The refund business is strongly coupled to the after-sales system, and the business code is scattered to various business layers. There is a serious lack of domain boundaries and hierarchical design of the system. After reconstruction, the refund business logic does not rely heavily on the after-sales core business logic and can be deployed independently. .

2.2.3. Amount calculation flow chart before reconstruction

 2.2.4. Amount calculation flow chart after reconstruction



 Use design patterns to merge two sets of amount calculation business logic into one set of amount calculation business logic to create an anti-corrosion layer

2.3. Reconstruct the design class diagram

Based on the design flow chart formulated above, I drew a UML class diagram. The following is a class diagram for the amount calculation business module.

2.3.1. Abstract Factory + Strategy Pattern Class Diagram



2.3.2. Responsibility chain model class diagram



3. System stability guarantee

3.1. Reconstruction in small steps

Divide post-sales reconstruction into three steps: refund, amount calculation, and reverse accounting, and run test cases after each step. This allows introduced errors to be discovered and fixed in a timely manner, preventing them from spreading throughout the system.

3.2. Step by step verification

After each refactoring step, perform step-by-step verification of the system. Grayscale is launched in batches. Grayscale configurations are absolutely isolated and cannot be reused. Ensure that various parts of the system function properly and coordinate well with other parts during the refactoring process.

3.3. Monitoring and performance testing

After the refactoring is completed, perform system monitoring and performance testing to ensure that the refactoring does not introduce performance problems or affect the stability of the system. If problems are found, repair and optimize them in time.

3.4. Team code review and testing

Collaborate with team members and conduct code reviews when refactoring. The perspectives and experiences of multiple people can help discover potential problems and provide suggestions for improvement; in-depth analysis of the refactored code can more effectively ensure the security of the refactoring.

The refactoring business notifies the testers in a timely manner, so that the testers can evaluate the test points and improve the test cases.

3.5. Grayscale steps

3.5.1, bcp continuous comparison and verification

3.5.2. According to merchant grayscale

Gradually perform grayscale cutting according to the order of small -> medium -> large after-sales orders , and observe whether the after-sales order data such as refund and amount calculation are abnormal.

4. Reconstruction results

1. Reduce development and maintenance costs

2. Improve code quality and system stability

3. Enhancement of system scalability and flexibility;

4. System application and business boundary positioning are clearer

5. Unify and standardize the core after-sales business context, reduce business learning costs, and improve development efficiency

6. Improve your technical skills, code quality awareness, problem-solving skills, teamwork and communication skills; there is a passage in the classic book "Refactoring":

In the beginning, the refactoring I did was all about minutiae. As the code becomes more concise, I find that I can see some design-level things that I couldn't understand before. Without refactoring, I wouldn't be able to reach this level.

5. code show

5.1. Calculation of amount before reconstruction

Service method for calculating the amount of home after-sales orders

Jingdong after-sales order amount calculation service method

A large amount calculation class has more than 1,000 lines of code, and each method has hundreds of lines of code. The following is part of the code for calculating the amount of an after-sales order.

 5.2. Amount calculation after reconstruction

The same interface is used to calculate the after-sales order amount of Daojia and JD.com, and the policy + abstract factory model is used to realize the amount calculation of Daojia, hourly purchase, and Tianxuan business.



Strategy mode to obtain the amount split result set



The core method of amount calculation only has 4 steps



The core of the amount calculation is calculated using the chain of responsibility business.



The in-process dimension and sku dimension adopt the responsibility chain model for amount calculation for different businesses.



6. References

Bad code smell: https://www.qinglite.cn/doc/87036476d565d55f9

"Refactoring to improve the design of existing code": [American] Martin Fowler

"Agile Software Development": [US] Robert C. Martin

Author: JD Retail Gao Kai

Source: JD Cloud Developer Community Please indicate the source when reprinting

Alibaba Cloud suffered a serious failure and all products were affected (restored). Tumblr cooled down the Russian operating system Aurora OS 5.0. New UI unveiled Delphi 12 & C++ Builder 12, RAD Studio 12. Many Internet companies urgently recruit Hongmeng programmers. UNIX time is about to enter the 1.7 billion era (already entered). Meituan recruits troops and plans to develop the Hongmeng system App. Amazon develops a Linux-based operating system to get rid of Android's dependence on .NET 8 on Linux. The independent size is reduced by 50%. FFmpeg 6.1 "Heaviside" is released

{{o.name}}

{{m.name}}