Code review Those Things

This tweet is a former colleague to share the time of the PPT, here I sorted out to share to everyone

What is code review?

Code review is a quality assurance mechanism that verifies code implementation by systematically checking the source code during the software development process.

Why not do code review?

• Business needs are big and working hours are tight.
• Small projects, fewer people to collaborate, no need

Why do you want to do code review?

• Improve code quality and improve your own level
• Early detection of potential defects and bugs, reducing the cost of accidents
• Promote the knowledge sharing within the team and improve the overall team level
• Ensure good communication between project team members.
• Prevent developers from committing common, common mistakes

The goal is to find system defects, ensure the overall quality of the software and improve the developer's own level, making project code easier to maintain.

The benefits of code review

1. It is the most well-known benefit of code censorship to have a lot of double eyes staring at a bug before the code is submitted. (People can really find bugs in code reviews, but most of these bugs are obvious little bugs that developers can find in minutes, and those that really take time to find are often found in code reviews)

2. The greatest benefit of code review is purely social. (If you know when you're programming that your coworkers are going to look at your code, your programming will be different, your code will be more uncluttered, your notes clearer, and your organization better.) Because you know other people will look at your code, their opinion is what you need to focus on. Without censorship, you know that people will end up looking at your code, but that doesn't give you a sense of urgency and doesn't give you the same feeling of personal judgment. ）

3. A bigger benefit is that code reviews can spread knowledge. (In many development groups, everyone is responsible for a core component, focus on their own piece, as long as the other colleague's module does not break their own code will not pay attention to, this mode causes a module only one person familiar with the corresponding code, if a person consult or leave, others will not know about the module he is responsible for. With code review, at least two people are familiar with code-authors and reviewers. Reviewers know less code than authors, but they are familiar with the design and structure of the code, which is significant.

The premise of Code review

1. Pay attention to code review
   (Code review people understand the concept of code review and what code review will do if the person doing code review doesn't understand the importance of code review to the success of the project or the quality of the code, their approach might be to deal with something. )

2. Whether the code has been properly build,build to make the code no longer has a basic syntax error
   (We don't want senior developers or supervisors to waste their time checking out code that doesn't even compile.) )

3. Whether the code is functioning correctly when executed
   (Code review Personnel are also not responsible for checking the correctness of the function, that is, the code that needs to be reviewed must be the responsibility of the developer or quality officer for the code's functionality.) )

4. Did the developer unit test the code?
   (This is also to ensure that some of the syntax and functionality issues before code review have been addressed, and code review can focus on the quality of the code.) )

What does Code review need to be aware of?

1. Integrity Check (completeness)

   • code fully implements the functional requirements presented in the design documentation
   • code has been integrated and debug
   • code according to the design documentation Have you created the required database, including the correct initialization data
   • code for any variables, constants, or data types that are not defined or are not referenced

2. Consistency Check (consistency)

   • the logic of the code conforms to the design document
   • the formatting, symbols, structure, and other styles used in the code are consistent

3. Correctness Check (correctness)

   • All variables are correctly defined and used
   • all comments are accurate
   • All program calls use the correct number of arguments

   • Modifiable Check (modifiability)

     • code The constants involved are easy to modify (such as using configurations, defining class constants, using specialized constant classes, etc.)
     • code If there is only one exit and one entry Port (except for severe exception handling)

   • Robustness Check (robustness)

   • Comprehensible check (understandability)

     • Comment A clear enough description of whether each subroutine
     • uses ambiguous or unnecessary complex code, whether they are clearly commented
     • uses some uniform formatting techniques (such as indentation, whitespace, and so on) to enhance the clarity of the code
     • is used when defining a naming convention Methods such as easy memory, reflection type
     • each variable defines a valid range of values
     • the algorithm in the code conforms to the mathematical model described in the development document

   • Verifiable check (verifiabilit Y)

     • Implementation Technology in code is easy to test

Code Review Experience Check

1, code specification aspects of the check
2, object-oriented design aspects of the inspection
-whether class design and abstraction are appropriate
-Is it compatible with the idea of interface-oriented programming?
-whether to adopt the appropriate design mode

3, performance aspects of the check
-Suitability for selection and setting of collection class data structures such as Hashtable,vector
-There is no abuse of the string object phenomenon
-use cache technology such as a common thread pool, object pool module to improve performance
-Does the I/O aspect use the appropriate class or adopt a good method to improve performance (e.g. reduce serialization, use buffer class encapsulation flow, etc.)
-The use of synchronous methods is appropriate, whether excessive use

4, database processing aspects
-whether the database resources are properly shut down and released
-The database access module is properly encapsulated for ease of management and performance improvement
-whether the appropriate transaction isolation level is used
-Resource leak handling aspects check cursor

5, communication aspects of the inspection
-There is a long-term blocking problem with socket communication

6. Duplicate Code
7. Other
-Log is normal output and control
-How the configuration information is obtained and whether it is hard coded

How to do code Review more effectively

1. One review is less than 200–400 line code defect density is the number of errors (bugs) found in every 1000 lines of code
   

2. Target per hour below 300–500 LOC inspection rate
   

3. Spend enough time on appropriate and slow reviews, but not more than 60-90 minutes
   In turn, however, the review code takes no less than five minutes, even if the code is only one line. In general, a single line of code can also affect the entire system, so it takes five minutes to check the possible results of the change.

4. Make sure the code developer has commented the source code before the review begins
   

5. Use checklists because it can greatly affect the results of code developers and reviewers
   Another useful concept is the personal checklist. Everyone usually makes 15-20 mistakes (bugs). If you notice some typical errors (bugs), then you can develop your own personal checklist

6. Confirm that the defect has been repaired

Finally, make code review a habit

The biggest thing that makes Google's code so good is Simple:code review

Welcome to my public number: Wwjblog

Code review Those Things