1 Reconstruction
Refactoring is not that complicated. Refactoring is our daily work, just like eating and drinking water.
Refactoring has a chance, just like our three meals a day. If the time is right, it will get twice the result with half the time. If the time is wrong, it will get half the result with twice the result with half the effort.
In our development work, the timing of reconstruction is all about.
2 Time for reconstruction: When the function is repeated
If you find that the function of the code is repeated, this is the time to refactor. This is often the case, as long as the developer has refactoring in this string.
2.1 Case initial status
For example, recently I am learning about WeChat applet development, which involves page jumps,front pageThe code of the index page is as follows:
Page({
gotoCollection() {
({
url: '/pages/collection/collection',
})
},
gotoActivity() {
({
url: '/pages/activity/activity',
})
},
gotoFace() {
({
url: '/pages/face/face',
})
},
gotoVoice() {
({
url: '/pages/voice/voice',
})
},
gotoHeart() {
({
url: '/pages/heart/heart',
})
},
gotoGoods() {
({
url: '/pages/goods/goods',
})
},
})
- This code means:
- If the Collection event is triggered, jump to the collection page.
- If the gotoActivity event is triggered, jump to the activity page.
- If the gotoFace event is triggered, jump to the face page
This code is in the js file on the homepage. Have you found the time to refactor it?
- analyze
- Jumping pages is regular: /pages/[action]/[action]
- Appeared many times
- And the meaning is clear, you can use one sentence to fate:
- Jump to a page (face)
- Jump to a Tab page (activity)
- in conclusion
Based on the above understanding, I think it needs to be reconstructed- Abstract general functions:
- The page jumps, and the page complies with:/pages/action/action
- Abstract general functions:
2.2 Refactoring and Implementation
Based on the above understanding, the code of the refactored index page is as follows
Page({
jumpPage(tag) { // Jump to a specific page
({
url: '/pages/' + tag + '/' + tag,
})
},
switchTab(tag) { // Switch to a specific Tab
({
url: '/pages/' + tag + '/' + tag,
})
},
gotoCollection() {
('collection')
},
gotoActivity() {
("activity")
},
gotoFace() {
('face')
},
gotoVoice() {
('voice')
},
gotoHeart() {
('heart')
},
gotoGoods() {
('goods')
},
})2.3 Reconstruction Analysis
- Abstract jump and switchTab, when writing code, there are fewer details, which is more in line with people's thinking habits
For example: Jump to face page: ("face") - Hide implementation details: , url: '/pages/' + tag + '/' + tag
- More suitable for specific environments: '/pages/' + tag + '/' + tag may be rules for specific scenarios
Compromise to implementation (applicable environment reduction: 80% principle)
2.4 Other benefits of reconstruction
The benefits of reconstruction, in addition to
- Reduce the code volume
- Highlight the main logic: More in line with human thinking (AI?)
Are there any other benefits?
- Common Functions Substitutability: Hidden Details
Taking jumpPage as an example, it is our implementation method and is a detailed
After we abstract the jumpPage, if we think it is inappropriate or upgrade it to a new method, just modify the jumpPage, and there is no need to modify gotoFace, etc. - Easy to scale, fix errors
For example: I want to print information before and after jump, before refactoring, and before refactoring, I need to modify it one by one. After refactoring, I only need to modify jumpPage
This is more beneficial for fixing errors and extending functions
The following is the code for the index page after adding the print information, which is usually applicable during debugging:
Page({
jumpPage(tag) { // Jump to a specific page
(tag) // Print tag
({
url: '/pages/' + tag + '/' + tag,
})
('jumpPage:/pages/' + tag + '/' + tag) // Print url
},
switchTab(tag) { // Switch to a specific Tab
(tag) // Print tag
({
url: '/pages/' + tag + '/' + tag,
})
('switchTab:/pages/' + tag + '/' + tag) // Print url
},
gotoCollection() {
('collection')
},
gotoActivity() {
("activity")
},
// ...
})2.5 Refactoring is just the beginning: further refactoring
- After abstracting jumpPage, think about whether other pages are facing page jumps. If so, just put them
front pageIs it suitable
More suitable for abstraction as global functions, put in
Put common functions in, multiple pages can be reused
App({
jumpPage(tag) { // Jump to a specific page
(tag) // Print tag
({
url: '/pages/' + tag + '/' + tag,
})
('jumpPage:/pages/' + tag + '/' + tag) // Print url
},
switchTab(tag) { // Switch to a specific Tab
(tag) // Print tag
({
url: '/pages/' + tag + '/' + tag,
})
('switchTab:/pages/' + tag + '/' + tag) // Print url
},
})After the modification of the index is as follows:
Page({
gotoCollection() {
const app = getApp()
('collection')
},
gotoActivity() {
const app = getApp()
('activity')
},
// ...
})
The refactored jumpPage, switchTab other pages can also be applied, but also require that the jump url must comply with'/pages/' + tag + '/' + tagspecification
3 Time to refactor: When designing the interface
When programming a WeChat applet, the loading page is a specific scenario, and the logical description is as follows:
3.1 Common Implementation
The following code is a normal logic of the collection page:
// ...
Page({
// ...
onLoad() {
// load
({
mask: true
})
({
url: ,
method: 'GET',
success: (res) => {
if ( == 100) {
({
dataDict:
})
} else {
({
title: 'Net loading failed',
})
}
},
complete: () => {
()
},
})
},
// ...
})3.2 Code Analysis
After analyzing this code, I found:
- Most logic is universal
In this code, most of the codes are universal. The regular meeting: , , send a request request, the request is successfully processed, and the request is failed to process - Part of the logic is unique
In this code, only some logic is different, url and success processing - Exposed too many details,
This code exposes too many implementation details, for example, - Inconvenient testing
Through the above analysis, it is found that this is a general scenario, not only applicable to one page, but can be applicable to multiple pages.
If the testing requirements are strictly required, it is not economical to provide separate tests for each page.
3.3 Problem pursuit
The above code is undoubtedly correct, but there are problems.
We were trapped in details from the beginning without further thinking.
This is an interface that complies with the logic in 3.1.
3.3.1 Abstract general interface
After the logic analysis in 3.1, it is the following interface.
void onLoad(url, onSuccess);
To describe in words:
Request a certain URL. If the request is successful, it will respond according to the onSucess method. If it fails, it will be processed by default.
3.3.2 Abstract interfaces are conducive to testing
3.3.2.1 Test cases
For the above interface, we can easily write test cases
There are two main test cases:
1. A successful url can be requested, and onSucess will be called
2. The URL that failed request, onSucess will not be called, and onFailed may even be called
Can you think of the third situation? Please think about it
According to the above test case, the interface can be corrected:
void onLoad(url, onSuccess, onFailed);
3.3.2.2 Compromise
According to the settings of the test case, an interface containing onFailed is undoubtedly good
If we take into account our limited situation, void onLoad(url, onSuccess) is also acceptable, which is the need to choose and compromise between ideal and display
If I were designing the interface, I would design it like this
function defaultFunc() {
}
void onLoad(url, onSuccess, onFailed=defaultFunc);
In this way, it is convenient for testing. If onFailed is not required to be processed, it can be ignored.
3.3.2.3 Interface definition
The following is the redefined interface, placed in a global location
App({
// Fix function name spelling error
defaultRequestFailed(error) {
("load failed:" + error);
({
title: 'Net loading failed',
});
},
loadPageByGetRequest(url, onSuccess, onFailed = ) {
({
mask: true
});
({
url: url,
method: 'GET',
success: (res) => {
if ( == 100) {
// Fix callback function calls
onSuccess(res);
} else {
onFailed("res code is failed");
}
},
// Correct the event name
fail: (error) => {
onFailed(error);
},
complete: () => {
();
},
});
}
});3.3.2.4 Conclusion
When programming, the best time to refactor the interface is to consider generality, testable rows, dependencies, and placement. In this way, the interface designed can be easily applied and tested, and has fewer external dependencies, which is also conducive to subsequent evolution