How to conduct efficient and rapid codereview

background

The first time to participate in Codereview do not know how to do, do not know why to do, later participated in more, slowly understand the meaning of Codereview, but also found codereview efficiency problems:

Sometimes it is found that a codereview time is long, the participants will feel the torment and waste of time;

Sometimes do not understand the other side of the review of things, can not keep up with everyone's thinking, affecting efficiency;

Sometimes go to check the code is too large, can not be detailed walk-check;

Sometimes it can be seen that some people do nothing, do not concentrate, do not speak, will affect the effect.

Write this article, hope that some of the suggestions in this article can alleviate the above problems, can make the new people understand the meaning and methods of codereview faster, the experienced person can more quickly and effectively codereview.

Codereview's goals and principles

Codereview's goal is to improve code quality, identify potential bugs and bugs early, reduce remediation costs, and promote knowledge sharing within the team, helping more people understand the system better. The principles of the proposed codereview are as follows:

Find the correctness of the code

The code review is intended to find the problem before the code is submitted-what you need to find is its correctness . One of the most common mistakes in code review-almost every novice will make is that the reviewer judges someone's code according to their own programming habits.

Not only in review Code, but also in sharing and learning

The most important thing about Code review is that the speaker shares the business process and the design ideas that the participants use to obtain this information, which allows more people to understand the system, improve the overall level of the team, and improve the team's ability to maintain the code.

Efficient and rapid completion of Codereview

We can't do it in haste. A code review is also important, and the review is futile if code review is not guaranteed to be implemented.

how to complete codereview efficiently.

The participant should check the rationality of the design and whether the business logic is wrong, check the readability of the code, and try to share the knowledge of design, technology and experience.

1. Check the rationality of the design and the correctness of the business logic:

Whether the code is designed to meet the design requirements:

If there is a discrepancy between the code and the design there is a need to ask why the change, because these changes may be due to developers in the actual design of the code when the depth of consideration, or because of the momentary error.

The business logic is correct:

Whether the business process is in accordance with the detailed design of the process, do not appear originally a process after the B flow and design when the first B after a, or lost process.

Some of the incoming parameters are reasonable: To determine whether some interface parameter input is redundant, such as the input a field can satisfy all the operations in the A interface, then more input a B is redundant.

Database field design, database design is the actual business mapping, we want to ensure that each field appears to reflect the actual business and reasonable validation, such as the design of the Table1 when the A field has appeared in the Table2, and a and B table has a corresponding correlation, Then note that the a field for Table1 redundancy is reasonable, if there is no reasonable persuasion can remove a, and save the maintenance cost of a field (storage space, update operations, etc.).

Some judgments are reasonable, such as whether the input amount of certain parameters can be judged by 0 and so on.

System interaction is reasonable, for example, when the code design is not concerned about the order of the system interaction, so that some information can not be obtained, such as the payment method to obtain the rate information must wait for the payment of the time to get, then access to the information should be placed in Pay_trans rather than create_ Trans, most of these problems are actually detailed design, the code review phase is relatively rare.

Whether there is an exception handling mechanism, a good code design should consider a variety of exceptions and appropriate exceptions to make reasonable processing, such as the Reentrant interface, when the code detects the re-entry of this situation, how to do this exception processing so that the caller can catch these exceptions and later processing.

Focus on Business scalability:

Our business is constantly developing, each project design will affect the expansion of follow-up business, a good design should take into account the development of follow-up business, and try to avoid the custom design.

Focus on the data structures , design patterns, and code performance you use:

A good data structure and design patterns can increase the maintainability of code, such as security and efficiency, such as when we design to consider the different scenarios to choose what kind of data structure, sometimes we will be entangled in the map or with Hash_map, at this time we will be based on the specific situation of specific analysis;

When we design the code, if we can use the function provided by the system, then it is better not to write on their own, such as the realization of a linked list when you can think of the system library provided by the List_head to ensure the correctness of the structure of the list;

Some designs, if applied in design patterns, make the design more aesthetically pleasing to the reader, and for system performance, we focus on the overhead of writing code, including the reasonableness of the algorithms used, and the attention to some of the more time-consuming operations such as database operations.

2. Check code readability and maintainability:

If the code is very readable, it is much easier to maintain; a good code specification and coding style will save you the time to understand the code, reduce maintenance costs, although we have a programming standard check tool, but some of the content can not be checked out, we need to rely on everyone to standardize.

Follow the code comment: when writing functions and making logical judgments, it's a good idea to label this function or what the judgment is for, and the benefit of making this comment is that when someone reads the code, they see your comment and then quickly understand the code based on your ideas, and don't even read it. Skip directly and prevent yourself from forgetting this code for a long time without reading the code.

Focus on naming conventions: Although we have our own coding specifications, this specification only restricts the use of hump naming or other nomenclature, and a good naming style should be to see the variable or function name can be "words too literally", after all, we can not write all the code to comment.

Focus on Duplicate code: If there is a lot of repetitive code, consider abstracting the code out of common functions to reduce the amount of code and enhance code readability.

Focus on the tedious logic: if a simple function corresponds to a large amount of code, consider whether there is a relatively simple implementation, because the overly complex code will bring trouble to the subsequent maintenance, if there is no short way, be sure to write the comments.

3. Sharing design, technology, knowledge and experience

In the process of code review, we tend to focus on the shortcomings of the discovery code, ignoring the code review process design ideas, technical methods, business knowledge dissemination, I think these content is also very important, but also need to pay attention to.

The reviewer will drill down into the business process in their own code, which will see some of the algorithms, data structures, design patterns, and even the system architecture of the review code, as well as the pits that the reviewer stepped into during the coding process. Through this information participants can improve their level of business and technical ability to increase the level of the entire team.

In addition to this sense of learning, the reviewer also has to find ways to enable participants to quickly and efficiently understand the spread of knowledge in the code, which helps to improve the speed of review, so it is recommended that the reviewer can briefly introduce the background of the project and detailed design, The introduction of this information has the following benefits:

First of all, the design of the code is carried out according to the detailed design, but the designers in the real code when there will be some changes, these changes to everyone a synchronization;

Secondly, the person who has participated in the detailed design may forget the process of detailed design because of the lack of direct participation in the code, the brief introduction will let the participants remember, facilitate the understanding of the participants;

Third, for those who did not participate in the detailed design of the students, after a brief introduction of these information, you can have a general understanding, or the entire review process will be very painful;

Therefore, if the participants do not understand the information of the code, it will cause the participants to understand the difficulty of the code, but also can not provide constructive advice, but also difficult to learn the assessment of the dissemination of knowledge, this is more easily overlooked in the previous review, especially in the cross-team code review, It is hard to understand what the other person is talking about when they are unprepared and inexperienced.

The best way to explain code is to use the interface function as a unit to explain

If the reviewer at once all the detailed design is explained, may be because the information is relatively large, or design to some details, participants can not effectively remember or understand the speed and efficiency of the review will also be affected;

The reviewers can share the pits they have stepped on during the presentation, and the participants can discuss them at any time based on the problems they have identified.

How to complete codereview quickly.

The so-called rapid is to save time, as long as we try to avoid some insignificant things can save time, speed up the review speed, to do this we recommend that you try not to do the following things:

1. Don't deliberately look for code bugs

Some of the logic of the code is relatively complex, if it is easy to find the flaw, most of the time the reviewer himself in the coding process will find that the remaining is not easy to find defects to find also will spend more time, these problems can be given to testers to find;

If the participant deliberately to find the bug will cause forgotten how, ignoring more important things, of course, some bugs you may have seen at a glance, it is better to put forward.

2. Do not comment on other people's code according to their own programming style

Some participants are more confident and satisfied with the code they write, so they sometimes comment on someone's code according to their familiar coding language or coding style.

As a participant, as long as the reviewer's code to meet the naming requirements and design requirements can be, but if the reviewer's code flaws are obvious, can be proposed to bring you to discuss.

3. Do not carry out code reviews with a mindset of attacking and questioning others ' abilities

Sometimes the participant may be in a bad mood, or feel that the other person is new and can not help attacking each other's code, it will be easier to waste time on ambiguous issues;

Participants may think that a method is good, and the reviewer may think that the B method is not bad, which can lead to a waste of time without the necessary controversy.

4. Don't compete on uncertain issues

If there is still no conclusion after a period of discussion, or if a third party is required to confirm or the reviewer cannot immediately understand the participants ' comments, do not spend too much time discussing these issues;

Record these issues first, and when the meeting is over, the reviewers can discuss them with the participants at the same time, solve them according to their own understanding, then give us a feedback, which can save a lot of time.

5. Don't listen to other people's opinions

Some reviewers are more stubborn, unwilling to accept the views of the people, will cause some unnecessary disputes and discussion, wasting time;

Of course, sometimes the participant's opinion is not necessarily the best, as the reviewer as a reference to the direction and perspective, if there is a controversy, these suggestions can also be made into the minutes of the meeting, the reviewers privately and the proposed person to discuss the future to give you a conclusion.

6. It is better for the participants not to be aware of their own opinions

If the participant does not want to understand the matter to ask the opinion, then the reviewer asks the time will waste everybody's time;

Participants can write down their own thoughts, and then mention them to the reviewers when they are clear.

Summary

In summary, to introduce some how to carry out a number of high-efficiency and rapid codereview some thinking direction, whether these methods are applicable also need to be verified in the practice process, but also according to the actual situation of different teams to make corresponding adjustments, our ultimate goal is to hope that Coderreview can effectively and quickly , on the one hand, improve the quality of the code itself, on the other hand can also create a good learning atmosphere support each other to enhance the overall code level of the team.