Hands-on experience in peer code review process

Statement: This article after I translated the first published in Bole Online, no matter what form of reprint please indicate the same place.

Millions of years ago, the ape came down from the tree and evolved the right thumb, finally. Become human.

We look at the mandatory code review in a similar light: it seems to be something that separates humans from the beast in a vast field of software development (Review).

It's just that I sometimes hear the following comments from our team members:

• "The code review of this project is simply a waste of time. ”
• "I don't have time to do code reviews.

  ”

• "My project announcement was postponed. It's all because my cowardly colleague hasn't done any judging. ”
• "Can you believe that my colleague wants me to pity dorado something in the code?" Explain to them that, assuming that my original elegance code is altered in any way, it means that the delicate balance of the universe will be undermined. ”

Why do we have to do code reviews?

First, let's remember why we do code reviews.

For software developers, no matter what the professional. One of the most important goals is the ability to continuously improve the quality of their work. even if your team is full of good program apes. You also cannot differentiate yourself from a competent freelance practitioner unless you are able to work as a team. code Review is one of the most important ways to achieve this.

In particular, they:

• Give your second pair of eyes to find flaws and better ways to do something.

• Make sure that at least one other person is familiar with your code.
• Help train your new employees by showing them the code of more experienced developers.
• promote knowledge sharing by enabling reviewers and reviewers to demonstrate good ideas and practices to each other.
• Inspire developers to be more dedicated in their work, because they know their code will be reviewed by one of their colleagues in the future.

Do a thorough review.

It's just that if you don't devote a certain amount of time and effort to the work of the review, these goals are not achievable.

Just scroll through the patch to make sure the indentation is correct, all the variables take small camel orthography does not constitute a thorough review. It is a fairly popular practice to be able to consider pairing programming with the inspiration of the industry. But it also adds 100% additional overhead to the overall development time as a benchmark for code review work.

You may spend a lot of time in code reviews, but compared to pairing programming. There is still much less overall project time to use.

I think the time spent on code review work should be about 25% of the original development time .

For example, suppose a developer spends two days implementing a small project. Then the reviewers should spend roughly 4 hours to review it.

Of course, the amount of time spent on judging work is not the most important. As long as the review can be accurate and complete. In particular, you need to be able to understand the code you are reviewing. It does not just mean that you understand the syntax of the language used in the code, it also means that you have to understand how the code fits into a larger application environment, component, or library. Suppose you don't grab the full meaning of each line of code. Then your review is not very valuable. That's why good reviews can't be done very quickly: it takes time to investigate the different code paths that trigger a given function. To ensure that third-party APIs are used correctly (including whatever the edge situation is), and so on.

In addition to finding flaws or other problems in the code you are reviewing, you should also make sure that:

• Including all the necessary tests.
• The appropriate design document has been written.

Even developers who are good at writing test and documentation do not always remember to update the code as soon as it is modified.

Fine-tuning from code reviewers at the right time is essential to ensure that the code does not deteriorate over time.

Prevent code review work from overloading

Assuming your team is forcing a code review, it's risky, because your code review work may have been piling up, finally to the point where you can't manage it. Assuming you don't do any review work for two weeks, you'll be able to take a few days to fill it out.

But it also means that when you finally decide to deal with them. Your own development work will be a certain accident stranded.

This also makes it more difficult to do the review, because the correct code review requires a strong, continuous mental work, it is very difficult to keep up for several days.

As a result, developers should do their best to empty their review backlog every day.

One way is to use the first thing in the morning to solve the review. Before you start your own development work, do a good review of the complete department, you can prevent the future review situation out of control. Some people prefer to do a review before or after the lunch break or at the end of the day.

No matter when you do these things, pass the code review as a regular day job rather than as a distraction. You can avoid:

• There is no time to process your review backlog.

• Delay the announcement of the project because your review work is not finished.
• Make some reviews that are no longer relevant, because the code has been modified very much during this period.
• Due to the last minute to deal with them, the review was finally completed very poorly.

Write code that is easy to review

The inability to manage the review backlog is not entirely a fault for the reviewers. Let's say that my colleague, regardless of 3,721, spends a week adding code to a large project project. Then the patches they publish will be really hard to review, and because there is too much work to be done at one stage, the purpose of the code and the underlying architecture will be very difficult to understand.

This is one of many reasons why it is important to divide your work into manageable units. We use the scrum management approach, so the right unit for us is the focus.

By working together, using units to organize our work, and submitting reviews that are relevant only to one of the units we are working on, we are able to write code that is easier to review. Your team might use a management approach. But the principles are the same.

There are some other prerequisites for writing easy-to-review code. Assuming that there are some very tricky architectural decisions to make, it is reasonable to have a discussion in advance to meet the requirements of the reviewers. This will make it easier for reviewers to understand your code, as they will know what you are trying to achieve in your code and how you plan to do it. This also helps to avoid situations where you will need to rewrite your large piece of code after the reviewer has proposed a different, better approach.

In your design document, the project structure should be descriptive. This is important anyway, because it allows a new project member to catch up very quickly and understand the existing code base. It also helps the reviewers to do their job better, which is another advantage. Unit testing also helps to explain to reviewers how the component should be used.

If your patch contains third-party code, please submit it separately. For example, when jquery's 9000 lines of code are inserted in the middle of the code, it is much harder to do the code review work.

One of the most important steps in writing easy-to-review code is to add a gaze to your code review section . This means that you can browse the review section yourself and join the gaze wherever you think it helps the reviewer understand the meaning of the code. I found that this kind of gaze only takes a relatively small amount of time (often just a few minutes) and can have a huge effect, allowing code reviews to work faster and better. Of course. Code Gaze also has many of the same advantages that should be used in the right place, but it is usually wiser to review the gaze. Finally, it's a bonus, research shows that when developers read and stare at the code again, they find that they have a lot of flaws in their own code.

Massive code Refactoring

It is sometimes necessary to refactor a code base that affects many components. For a large application, this process can take days (or longer) and lead to huge patches. In these cases a standard code review work may be impractical.

The best solution is an incremental refactoring of code.

Find a certain point of change within the working code base to the extent that you can achieve your purpose. Once it has been changed, review has passed. Then make the next modification until the entire refactoring is complete. This approach may not always work. But with ideas and plans, it is generally practical to avoid huge patches when refactoring. Refactoring your code like this may take a lot of other time for developers, but it also produces better code quality and easier review work at the same time.

Suppose you really can't implement incremental refactoring code (which might say something about how to write good and organize good sources). One possible solution is to replace code reviews with pair programming when refactoring is in progress.

Dispute resolution

Your team is undoubtedly made up of a group of smart professionals.

When you have a different view of a certain coding problem. are basically controversial. as a developer, keep an open mind. Be prepared to compromise when your reviewers are more inclined to a different approach. do not take a proprietary attitude towards your code, and do not bring a personal opinion review.

Assuming it's just that someone thinks you should refactor some repetitive code into a reusable function, it doesn't mean that you're not an attractive, good, or charismatic person.

as a reviewer, you must be witty. Before you change your proposal, think carefully whether the offer you give is really better or just your personal style question. Let's say your chosen battlefield focuses on areas where the source code obviously needs to be improved. You will have a lot of other successes. Say something like "consider ... It might be worthwhile "or" someone suggested ... "is more appropriate than" even my pet hamster can write a more efficient sorting algorithm. "

Assume that there is no middle ground (i.e. both parties are unwilling to compromise). Then invite a two-party respected third-party developers to come and see. Let them give some ideas and suggestions.

Hands-on experience in peer code review process