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
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
Boldness: means having the courage and determination to change and improve existing code. Refactoring may involve making changes to complex code structures and may even require rewriting parts of the code. Bold developers are willing to face these challenges, believing that changes can lead to better results.
Careful: Refers to maintaining meticulous thinking and actions when refactoring. This includes carefully analyzing the structure and logic of the code, understanding the functionality and dependencies of the code, and considering the potential impact that each refactoring step may have. Careful developers will carefully handle every detail during the refactoring process to ensure the correctness and maintainability of the code.
-
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, it is A good time to refactor;
-
Early sorting is very important
, find the pain points first;
it is not suitable for long-term operations
, and it is not suitable to run in parallel with the business;
-
Clarify the goals and values
:
after-sales refunds and amount calculation reconstruction can improve development efficiency, reduce maintenance and development costs, etc.;
-
Determine the goals of refactoring
:
First, identify the code blocks or functions that need to be refactored, and clarify what the goals of the refactoring are.
For example, there may be a need to improve code readability, maintainability, or performance;
-
Analyze code smells
: Use code static analysis tools or manually check the code to identify possible
code smells
; for example, there are more than 1,000 lines of classes, more than 600 lines of methods, too many variable parameters, and many duplications in the refund business Code and other
code smells
;
-
Choose appropriate refactoring techniques
:
Choose appropriate refactoring techniques based on the types of bad smells in after-sales code
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;
-
Write test cases
:
Before refactoring, write appropriate test cases to verify the correctness of the refactored code.
Test cases should cover various situations of the refactored code block or function;
-
Perform refactoring
:
Modify the code step by step according to the chosen refactoring technique.
Ensure that each modified code still passes the previously written test cases;
-
Run test cases
:
After each refactoring, run the previously written test cases to ensure that the refactored code is still correct;
-
Code evaluation after refactoring
:
Evaluate whether the refactored code achieves the expected goals, such as whether it improves code readability, maintainability, or performance.
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 dissection of refactored code can more effectively ensure the safety of 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
-
Reduce development and maintenance costs
-
Improve code quality and system stability
-
Enhanced system scalability and flexibility;
-
System applications and business boundary positioning become clearer
-
Unify and standardize the core after-sales business context, reduce business learning costs, and improve development efficiency
-
Improve your technical capabilities, 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.1、重构前金额计算
一个大的金额计算class类就有1000多行代码，每个方法中都有几百行代码，以下是到家售后单金额计算部分代码：
到家和京东售后单金额计算用同一个接口才承接业务实现，并且使用策略+抽象工厂模式实现到家、小时购、天选业务的金额计算。
其中金额计算的核心则采用的是责任链业务进行计算
在件维度、sku维度针对不同的业务又采用了责任链模式进行金额计算
参考资料
[1] 代码的坏味道：https://www.qinglite.cn/doc/87036476d565d55f9
[2] 《重构改善既有代码的设计》：
[美]MartinFowler
[3] 《敏捷软件开发》：[美]RobertC.Martin
-end-
本文分享自微信公众号 - 京东云开发者（JDT_Developers）。
如有侵权，请联系 [email protected] 删除。
本文参与“OSC源创计划”，欢迎正在阅读的你也加入，一起分享。
