Java engineers must read the treasure book of avoiding pits

1、 Background

All students who have worked will have experienced or heard of various failures in person.

They may be criticized at the light level, or even fined or dismissed at the heavy level.

So, as Java engineers, how can we avoid pitfalls as much as possible? Is there any experience we can share?

In this article, I will talk about my own views based on my own experience.

2、 A treasure book for avoiding pits

2.1 Follow development specifications

It is highly recommended that you read the Alibaba Java Development Manual by Gujin, which contains many specific development specifications.

The book involves: coding protocol, exception log, unit test, security protocol, database, engineering structure and design protocol. There are many entries and clear cases, which are common mistakes and blood lessons.

It is not difficult to read this book at first, but many students will violate the specifications in the development, resulting in some bugs and hidden dangers. It is recommended that everyone read it again and again.

2.2 Compare with master

In the development process, compare the current branch with the master branch.

So as to be able to:

(1) Early detection of incorrect modifications

(2) Find the wrong code of merge as soon as possible

(3) Self-code review

Sometimes, when we develop multiple functions together, we may change project A to project B branch; Sometimes, we may delete a text by mistake; Sometimes, even if we have been very careful, when merging code conflicts, it is likely to merge errors. It is easy to find these problems by comparing with the master branch.

Generally, when we write code, it is easy to fall into a certain class or function. Compared with the master branch, it is easier for us to zoom out and see my changes from a higher perspective. Review your code to find some problems as soon as possible.

2.3 Static code check

Large companies have their own PMD plug-ins and files. If the company does not have some open source PMD plug-ins, it can scan common rules and fix common problems as early as possible in the development stage.

Insert picture description here

2.4 Pay attention to code review

Plug-ins can check out common problems. Many problems need to be examined manually to find.

such as

(1) Some potential performance problems

(2) Problems that violate some design principles, such as high cohesion and weak coupling; Violation of single responsibility, violation of open and close principle, violation of Dimit rule, violation of dependency inversion principle, etc.

(2) Some businesses do not consider comprehensive verification

(3) Some designs that lack extensibility

Some companies enforce code review before merging into the master branch. If there is no mandatory code review, it is recommended to actively review with colleagues around.

We did find many problems in the actual code review, such as:

(1) Call RPC interface in for loop -->use batch interface to improve performance

(2) Sensitive information is not desensitized

(3) Manually create threads -->use thread pool

(4) Resource not closed

(5) The parameter verification is not done well. There may be security problems and potential null pointer exceptions

(6) Print a lot of unnecessary logs, print large text ->reduce the log level, simplify the log content, etc

With regard to code review, the book "What to Look for in a Code Review" produced by JetBrains is highly recommended.

Insert picture description here

This book discusses code review from the perspective of code design, code test integrity, performance issues, whether the data structure is reasonable, whether it conforms to SOLID principles, and whether it conforms to security principles.

The book provides matching cases for different principles, such as:

Insert picture description here

Other reference articles:

《What to look for in a code review》

《Code Review Best Practices》

2.5 Read more error logs

Due to some degradation logic in the code and other reasons, some functions seem to meet expectations during testing, but in fact, some errors will be reported.

Some functions may report occasional errors, which may not be noticed during the test.

We should read the error log frequently in the self-test, front and back end connection and test raising stages, so as to find the problem as soon as possible and repair the problem as soon as possible.

Insert picture description here

For example, during the front end and back end joint debugging, the front end student triggered an exception scenario, and a null pointer exception occurred. You found it in the error log for the first time. When she gave you feedback, you had already repaired and republished it.

For example, when testing a student to verify your function, a situation that you did not consider triggered an exception, and you detected and secretly repaired it at the first time.

By reading more error logs, we can reduce communication costs, solve problems as soon as possible, and discover and repair some potential hazards as soon as possible.

2.6 Checklist

You can record some important design principles, some mistakes you often make during development, and check the list during or after the development of each project by means of mind mapping or notes, which can greatly improve the coding quality and reduce the probability of dropping holes.

Insert picture description here

For example, some important design principles:

(1) High cohesion and weak coupling

(2) Reduce complexity (technical complexity, business complexity, etc.)

(3) Principles of design mode: single responsibility principle, Dimit principle, Richter substitution principle, interface isolation principle, opening and closing principle, dependency inversion principle

(4) Programming for failure. What if an interface call times out? Do you need a bottom? Do you need to retry?

(5) What other optimizations can be made to better expand?

(6) Are there any security risks?

(7) Is there any code with high complexity?

（8）...

For example, some common mistakes:

(1) When using the thread pool, do not forget to pass the trace context, which will cause the traceId to be lost when an error occurs.

(2) When calling a batch interface, you must pay attention to the downstream limit on the number of parameter sets.

（3）...

Although most people know many principles, there are still many violations of the above principles when writing code.

Therefore, during or after coding, we can look at our code in the checklist and optimize it, which can reduce the number of trips.

2.7 Look at the dependent service source code

We should not only keep our heads down, but also look up at the road.

If the development period is not particularly tight, strongly pull the warehouse code of the downstream service, check the specific implementation of the service that the current function needs to be connected with, and be sure.

For example, we need to call the batch interface of the commodity center to batch query the commodity information.

By pulling the warehouse code of the commodity center and viewing the source code of the service, we found that the downstream has a limit on the size of the commodity ID, and more than 50 will report an error.

In the development stage, we will actively call in batches, instead of not more than 50 products in the self-test. After going online, we will modify the code and re-issue it after more than 50 products report errors.

After we look at the source code of the dependent services, we will have a deep understanding of the development function, and we can quickly troubleshoot problems.

2.8 Look at the source code of middleware

If you have time, you should master the source code and principle of common middleware.

Only by mastering the source code and principle of commonly used middleware can it not be easily misused. Only by mastering it can we know why and solve the problem as soon as possible when encountering errors.

Some books are recommended:

(1) Spring recommends "Learn Spring from 0" and "Spring Boot Source Code Interpretation and Principle Analysis"

(2) Redis recommends Redis Deep Adventure

(3) ES recommends Elasticsearch

(4) Dubbo recommends "Understanding Apache Dubbo and Practice"

(5) HBase recommends reading the HBase Sleepless Book

(6) Kafka recommends "Deep understanding of Kafka's core design and practice principles"

(7) ...

2.9 Multi-write single test

If the development period is not particularly tight, try to write effective unit tests.

We usually require a single test coverage of more than 80%.

Insert picture description here

Many common problems can be exposed in advance during single test.

With single test, if a method is incorrectly modified, it can also be found as soon as possible.

2.10 Full self-test

We should fully self-test ourselves to avoid many problems during the front and back end joint debugging, which will affect the project progress, and to avoid the front-end and test students from questioning their ability.

We should not only consider normal scenarios, but also consider what abnormal scenarios exist in each project, so as to expose the problems in the self-test stage as much as possible.

2.11 Comply with three-board axe

The so-called three-board axe can be gray, monitored and emergency.

The function should be grayscale, continuously cut the flow, and reduce the impact of the problem.

To be able to monitor, problems should be found as early as possible through monitoring, rather than waiting for user feedback when actual losses are caused to users.

We should be able to deal with emergencies as soon as possible in case of problems.

Here is a tip. Many students will leave some switches for dynamic configuration (such as apollo) of the developed functions, and quickly switch back to the old logic in case of problems.

2.12 Reconsideration

Not all project problems are technical problems, but also planning problems and communication problems.

Many people do not complete the project and will not repeat it. The problems that existed before will still exist in the future, resulting in a lot of projects but not much progress.

After completing each major project, we should go to the review to avoid the same problems in the next project.

Insert picture description here

For example, if the project has not been developed with the front-end one or two days before the joint commissioning, the progress will be affected if the front-end students haven't developed it on the day of the joint commissioning. Before the joint commissioning of the next project, confirm with the front-end students whether the joint commissioning can be carried out on time.

For example, this project has a tight schedule. It was tested online without code review. Finally, a bug appeared. If code review is carried out, this bug may be avoided.

For example, a certain expression of the product is not consistent with our understanding, and we did not align the concept, and the problem was found in the acceptance stage. In the next project, if there is ambiguity or you don't understand it well, you should align it with the product in time.

For example, some new students did not write department scores in detail, and the evaluation workload was inaccurate, resulting in project delays. In the next project, let the new student department write a detailed re-assessment of the workload, and leave some buffers when evaluating the workload.

For example, the release plan is not written in detail, and the release order is still being sorted out before release, resulting in delayed release or release problems. The next project release plan must be written in detail.

3、 Summary

Only by forming a good coding standard, improving the coverage of single test, adhering to the classic software development principles, adhering to code review, adhering to checking error logs, and adhering to double-check, can the probability of pit trip be reduced as much as possible.

I hope everyone can be less BUG and more professional; Less faults, more salary increases, and good and precious.