Write in front
The main function of the article is to help yourself think and summarize. For example, we may have encountered some unpredictable bugs after the function is launched. We will deal with these bugs. After improvement, the project leader may ask several main developers of this function to conduct a review meeting. Let's discuss the reasons for the problems together, and then customize the corresponding solutions to prevent similar situations from happening again.
The principle of writing an article is actually the same as a review meeting. Through thinking and summarizing, we can change ourselves better. Learning can change ourselves, and we learn for the sake of change, and writing articles is also a way to learn.
Of course, due to the limitations of writing style and literary talent, the content written may not meet everyone's needs. However, among these contents, as long as one thing can be explained clearly, even if there is only one knowledge point, even if there is only one person agrees with this matter or this knowledge point, then it is meaningful to write these things.
Review's functional module
The function involved in this CodeReview is the data inference training module. The specific requirement is that when developers enter data, there are two formats: yaml and json. Some people are not very clear about the data format of yaml, so there is a place that can support the configuration of yaml syntax, and support the mutual conversion between yaml and json before, that is, after entering yaml, I suddenly find that what I need is json, so it can be directly converted into json format and passed to the backend, and vice versa.
The functions of yaml and json before conversion have corresponding packages on npm. If you are interested, you can learn about it. I won’t describe it here.
Reviewd's Problems (Grain)
- True Requirements VS Fake Requirements
The direct leader asked a fatal question: Who is using this function? Is it really necessary to do this function?
As developers, if we are not familiar with the syntax format of yaml and we can learn it quickly, then there is no need to waste manpower and time to develop this function. Wouldn't it be better to spend time developing more important functions?
Of course, this is not to say that this function is not good. The problem reflected here is: Do we understand the corresponding requirements before developing a function? Is this requirement a real requirement or a fake requirement? .
This problem must be confirmed before development.
- Data format
When a function may be expanded later, such as a list for enumeration, the data returned by the backend is usually an array.
For this extensible data format, we need and must align with the backend, and the frontend must do corresponding empty judgment processing. Never believe that the data returned by the backend is reliable.
For example, in the following two formats, the backend may tell you that they both represent empty arrays.
var a = []
var b = [{name:''}]
The backend may tell you, ah, I only have one piece of data in this b. When the name is an empty string, it means that there is no data in this b.
However, a and b fundamentally represent two different meanings.
Therefore, the ambiguous data format must be aligned with the backend, and the frontend must take corresponding defensive measures to judge the empty ones.
- You still need to pay attention to the type definition of ts
Functions must have their own return value type, and function parameters must also have corresponding parameter types. Where ts cannot be inferred, ts will be inferred as any type by default. So what is the significance of using ts for development?
- Definition of asynchronous functions
Usually when requesting an interface, we will use the function's asynchronous identifier async to define an asynchronous function. But sometimes you may be used to writing, and you also define asynchronous functions where there is no need to do asynchronous processing, such as:
const print = async () => {
('print')
}
Unexpected problems may arise at this time.
- Where there should be comments, please have comments
If the variables defined are ambiguous and have certain business meanings, the annotations must be clear and clear, such as:
if( === 'pc'){
// do something
}
If pc has a very specific business meaning, then does it mean personal computer or process center, or other meanings?
If the definition of variables with specific business meanings is too simple and there are no corresponding comments, then inadvertently we dug a hole for ourselves and other colleagues.
- Use of operators
When using ternary operations to make judgments, we usually write this:
let hasGold = ===''?false:true
We can use the !! operator to optimize this judgment:
let hasGold = !!
Of course, there are many other operators, such as ?., ??. The double question mark is a null judgment operator, and its function is the same as the || double vertical line.
const headerText = || 'Hello, world!'; const headerText = ?? 'Hello, world!';
When the left side is null or undefined, the right side will take effect.
- Pay attention to the handling of try/catch outside the code to prevent other exceptions
When we write code, especially when writing events related to page interaction, we generally don’t consider using try-catch for processing.
However, when the event is triggered on the page and the interaction is manually triggered by the user, it is necessary to take some defensive measures to add try-catch to prevent unexpected problems from occurring.
The use of try-catch is mainly used to prevent some external errors, such as:
try {
(a)
} catch (error) {
(error);
// VM654:4 ReferenceError: a is not defined
// at <anonymous>:2:15
}
Sometimes when we define variables or functions, some unexpected problems may arise. Try-catch will throw these problems out in advance to avoid more complex problems.
External problems can be understood as problems outside try{} curly braces.
at last
Although the functions involved in CodeReview this time are very simple, the problems exposed are still worth our careful consideration.
Although we are already very experienced in development work, there are still many places worth thinking about and improving.
The above are the detailed contents of several common problem sorting and solving examples of CodeReview. For more information on the codeReview problem sorting, please pay attention to my other related articles!