When you change slots and fill holes, you face a new environment. Being able to quickly become proficient and get started to implement business requirements is the key.
However, what factors will affect your quick start? Is the original code written well enough? Or are the comments not well written enough?
Last night, leisurely and elegantly, I looked at Xiao Wang's code next door. After reading it, I was so angry that I couldn't get angry.
So, I made a list of the mistakes Xiao Wang made, and helped him improve together. By the way, take a look at these bad habits. Do you have them too?
1.
If you trust others too much, you will dig a hole for yourself.
For the interface input parameters, there is no strict verification, especially the parameters to be inserted into the database database, all the way to the end (database level), the database reports data insertion exception.
For the caller, they will always wait for the interface to respond, and finally get a database error, and they will be confused; for the interface itself, it will occupy the database connection and consume resources. If the amount of concurrency is large, the impact can be imagined. Know.
Suggestion: During the development of business code, do not believe that the caller will pass parameters as required, and do defensive programming.
2.
The exceptions are caught, and they are almost shivering.
2.1. Caught exception, but did nothing!
2.2. The way of printing the exception stack is meaningless.
It is estimated that many people will write this way, but in production, it does not make much sense, so it is best to output abnormal information in the form of logging.
Suggestion: In the process of business code development, for exceptions that occur in the interface, since they have been caught, they must be packaged and handled well. If you do not do anything, the exceptions will be swallowed up privately. Know where the problem is.
3.
Pediatric problems will be careless in Jingzhou.
3.1. The code is written like this, what user experience is it talking about?
For example, in the scenario where the user binds a bank card, it is determined whether the bank card has been bound, and if it is not bound, it will be bound.
Loop through the list of bank cards bound by the user, and then compare whether the incoming card number (cardNo) has been bound. When the incoming card number is consistent with the bound card number, modify hasCard to true, and it does not jump out of the loop, continue to the next A comparative judgment.
Then, if code like this happens in a scenario with a large amount of data, it will inevitably reduce performance, waste resources excessively, and users will definitely scold.
Suggested modification method (the benevolent see benevolence and the wise see wisdom):
3.2. The data is processed one by one, how come there are still fish that slip through the net?
For example, when the third-party data is reconciled, it is judged whether the data sent by the third-party matches the local state normally, and the unmatched data is cancelled.
The code is written in this way. Once the condition is matched and a record is deleted, the size of the list changes, and the value of i also changes, which will cause some records to be missed during traversal.
For example, when you delete the first element and continue to access the second element according to the index, because of the deletion, the following elements are moved forward by one place, so the third element is actually accessed.
It is recommended to use Iterator to delete, or to traverse the collection in reverse order to delete.
3.3. Improper use of & and && will eventually lead to mistakes.
For example, in a Web project, check whether the entered mailbox is empty.
When the email input is null and & is used, a null pointer exception will occur in the following condition.
It is suggested to change to:
Similarly, | and || have similar situations, so when using them, you should also pay attention to the problems of such scenarios.
3.4. Equals comparison, maybe there will be a moth.
A null pointer exception occurs when resMap.get(Global.RETCODE) is null.
In view of the fact that the equals method of Object is prone to throwing null pointer exceptions, in business development, constants or objects with certain values should be used to call equals.
It is suggested to change to:
3.5. Mathematical operations, it might lead to bankruptcy.
The output result: 0.010000000000005116, generally you can use java.math.BigDecimal wherever you need to use floating-point arithmetic.
It is suggested to change to:
Note that the parameter for constructing BigDecimal is String, don't make a mistake, this is also a problem that newbies tend to make.
3.6. Strange comment, I want to scold when I see it.
3.6.1. A type of annotation in the project.
The author of the code is the administrator, dare to ask, who is the administrator TM? And the source file has been modified, but what does the modification describe? Really puzzling!
3.6.2. Annotation of a method in the project.
The method parameters are not explained; the method return value is not explained; the author belongs to the administrator; what is the description of the modification description?
4.
Let the code speak.
4.1. Avoid selling water by the river.
4.1.1. Business interface signature verification code snippet.
The red circled part, I feel a little bit of selling water on the riverside, unnecessary. Then, you can remove the false judgment, and it is recommended to modify it as follows:
Similarly, in code development, the true judgment can also be removed.
4.1.2. User login code snippet.
The last else is a bit superfluous and can be omitted and modified to:
4.1.3. Whether the user binds the bank card fragment.
The judgment before return seems to be slightly redundant and can be modified as:
4.2. Reduce bugs and reduce the complexity of the circle.
(The picture comes from the Internet)
It will be found that the more nesting levels, the more complex the code, and the higher the cyclomatic complexity may be. However, controlling the number of nesting levels is an effective way to reduce the probability of bugs.
For example, the following code snippets can be said to be a lot of work in the project.
According to the scene, it can be adjusted as follows:
4.3. Unified operations, the code has not been moved, and the norms are first.
In order to make the code written can be read clearly, the premise is that the team must be unified, and it is not possible to create original research and development tips for personal hobbies.
Dare to ask, what needs to be unified?
Unified development environment (JDK version, integrated development tool IDE, storage directory...);
Unified development framework, more focus on business development;
Unified development template, development tools should be unified Scheme;
Unified development protocol, naming, annotation, code structure and other constraints;
Unified DB statute with a good standard.
unified ......
5.
The process of code review will make people laugh and cry!
For the hard-working code farmer , your code will be taken over by other colleagues sooner or later. In order to make the colleagues who take over your code not silently scold you, it is recommended to treat coding well and write every line of code carefully.
Writing code is a happy thing, and reviewing code is even more interesting . By reviewing code, you can learn from each other, make the code more robust, and find bugs early, so don't miss it every time.
Finally, this sharing is here, I hope you like it.