Code review Comprehension

Peer programming and code review are mentioned in extreme programming. Anyone who understands programming a little bit will agree. This also reflects the importance and necessity of code review. However, in the actual execution process, it is often difficult to execute the code review. The main reasons may include the following:

(1) lack of confidence in the code you have written, and fear that others may find problems;

(2) You are too confident in your own code and do not need to review the code;

(3) your code is too closed and you are unwilling to share your coding experience with others. You are afraid to teach your apprentices to become masters;

I personally think that for a team, the code is open. At the same time, we also need to review the code regularly to help every team member improve its ability to write code. If a large system is used as a building, the system architecture is like a steel structure, and every line of code is brick-and-mortar. The architecture is ready, and the bricks and tiles are useless, the system still does not work. For code review, the code specification, system architecture specification, and document specification are consistent with the business logic (that is, whether the business needs can be met ). With this, the quality of the entire system development and the quality of the Code will take a new step.

From the aspect of coding specifications, the following notes are summarized after the query:

(1) whether it meets the code formatting standards (refer to Sun code formatting standards)

(2) Whether there are redundant import items (if there are redundant items, excessive resources will be consumed)

(3) Whether redundant fields are defined

(4) Whether redundant local variables are defined

(5) Whether redundant private methods are defined

(6) Is there any code with repeated logic that can be reconstructed (if so, reconstruction is required)

(7) is the public/private/static/FINAL attribute of the method/member reasonable?

(8) whether to call static Constants by class/Interface Name

(9) whether all Java. io. the serializable interface classes all have serialversionuid (this is very important. I have encountered such a problem. If the classes on the middleware server are different from the locally compiled versions of the classes, an error is returned, this problem does not occur if serializable is implemented)

(10) Class/interface/variable/parameter name, whether the name is standard

(11) are all if, for, and while Blocks Used {}

(12) Is there a complex statement?

(13) write the URL, file path, and so on to the Program (hard coding, applying static constants or properties files)

(14) write Chinese in a program (Application Properties)

(15) whether non-descriptive strings used in the system use Constants

(16) whether the number used in the system uses Constants

(17) whether the constant has a detailed comment

(18) Whether system. Out, system. Err, and throwable. printstacktrace () exist in the program ()

(19) whether the stream, file, and connection opened in the system can be properly and closed in time

(20) when outputting logs, the low-level output must judge isxxenabled.

(21) Output a large number of debugging logs in the production environment

(22) Pay attention to the thread security of objects used

(23) Large-scale String Assembly

(24) Use of recursive Methods --- avoid as much as possible

(25) whether the local thread object causes memory leak

(26) Hard-to-code conversion is strictly prohibited in the application code, and only unified processing can be performed in the framework.

(27) whether regular expressions have been compiled and whether large-scale expressions exist

(28) whether all resources (database connection, file lock, etc.) and references in the Error Path have been released

(29) While ensuring thread security, pay attention to avoid excessive use of synchronization, leading to performance degradation.

(30) whether the locks on the synchronization object are obtained and released in the same order to avoid deadlocks. Pay attention to the error handling code.

(31) are all cycles optimized?

(32) if the blocking method is called, whether measures to ensure performance are taken into account

(33) security checks on methods (functions)-code is selfless, mutual improvement, and mutual progress are fundamental to the progress of the entire team and the improvement of system development quality.