When and how to conduct code review

I recently read an article about code review on infoq, which is a translation edited by infoq. I later read the original article, and I feel that the translator has missed some background knowledge and more details of the original article. So I re-translated it again. Please criticize and correct the translation.

 

Original article and infoq link:

Infoq: http://www.infoq.com/cn/news/2010/12/agile-code-review

Http://www.devx.com/architect/Article/45741? TRK = dxrss_latest

 

My translations:

 

Most of my articles focus on Agile Project management. One way to improve the team is to use the product manager and the engineering team for good engineering practices. If a good engineering practice introduction mechanism is not established in the team, the product manager must participate in the construction. Then the product manager needs to start and lead the team to adopt some good engineering practices, and code review is a very good practice.

 

Agile engineering practices 

Let's start with the basic engineering practices that agile teams should adopt. Usually these practices come from extreme programming. Below are important engineering practices in extreme programming:

Test-driven development
Continuous Integration
War Room
Pair Programming
Small and frequent releases
Reconstruction
Code

I believe that most development teams will consider starting from the extreme programming engineering practice. Of course, the software process declaration will be more suitable for some teams that want to go faster and more advanced. The Software Process Declaration aims to improve software development. The following are the main principles of this Declaration:

1. The software that can work is insufficient, so we still need to keep improving.
2. The response to changes is insufficient, so we need to steadily increase value.
3. Individuals and interactions are insufficient and need expert communities.
4. Customer collaboration is insufficient, and effective partnerships are needed

In the process of pursuing the left item, we found that the right item is also indispensable.

 

In addition, some software design practices, such as loose coupling and solid principles, are beyond the scope of this article and will not be repeated. No matter what the principle of good development is, team members must be kept in mind during code reviews. Code review is the best time for teams to focus on when and whether they follow these principles and good practices.

 

When to start code review 

 

The time for code review should be determined by the team. It is appropriate to carry out at least two or three times in a project. If the project time is relatively high, it can be increased in a proper amount. There are no standards for the code review time, but it is enough to be consistent with the team's investment.

 

If your team has one iteration or sprint in two weeks, it is more appropriate to perform a code review after two or two iterations. In this way, there will be enough code for review, but you must be able to quickly find the Code related to the topic of this meeting. The number of code reviews depends on the maturity of the team. If your team is practicing Pair programming or is relatively mature, the number of code reviews can be reduced as appropriate. The frequency of code reviews should be determined based on the team's maturity. A good code review pace will keep the team continuing to carry out good engineering practices, and some new practices will be introduced by some organizations.

 

Who should participate in code review? 

 

The entire development team should participate in code reviews, including developers at all levels. The review can explore some principles outside the code and require the team to learn and strengthen these principles. The review process must have discussions and feedback. If the QA Team has development tasks, they should also participate.

 

Organize code review 

 

If you are a team leader, scrum master, or project manager and have never organized code reviews, don't worry. Not all code reviews are completed manually. You can use some existing tools and major technical members will help you. Be fully prepared before the review, because unexpected code is often found during the review.

Preparation

• Code coverage

The team should have some standards in basic quality measurement. For example, most teams require code coverage for unit tests. Many tools are available in the industry, such as. Net-based ncover and Visual Studio test, while jcover, Hansel, and codecover are available in Java.

 

Code coverage rate may reflect some problems. If there is code with coverage rate lower than 20%, you may have to question it .. please note... there may be a good reason, but this is more of the beginning of a conversation than just a report card.

 

• Architecture

The architecture discussed during the review is also a very good practice. We will take out all the old architecture diagrams and compare them with the current structure and class libraries.

This article describes how files of the current project are organized. This is also a way to check whether the project is organized properly. If any change occurs, make sure there is a proper reason.

 

• Code Analysis

Use tools to analyze the code before the meeting so that you can know what needs attention and how to start.

There are already a lot of tools in the industry. Before the meeting, you must prepare the report .. The tool I recommended in the net field is ndepend. Using these reports, we can know the complexity of the circle and the inheritance depth of the class.

 

Code Review

When you are ready, you can start the review meeting. Be sure to leave enough time for discussion. Code review meetings should be interactive, provide mutual guidance and make progress together, rather than where architects or leaders talk about each other. All preparations should be directed at triggering discussion and discussion.

 

The length of the Meeting is determined based on the size and characteristics of the team. The following data can be used as a reference: The team has 8 developers, 1 project manager, and 1 Development Manager. The entire team works well and has a harmonious internal relationship, A code review lasts about one and a half hours. This data can be used at the first meeting, and will be adjusted based on the first result.

The following is an example of meeting content arrangement:

1) Overview of the content of this Code Review (10 minutes)

2) discuss team indicators (10 minutes)

3) special focus on review (5 minutes)

4) In-depth code review (55 minutes)

A) code coverage

B) Architecture

C) In-depth Analysis Report

5) Summarize and record action items (10 minutes)

 

The focus of the meeting arrangement should be on what the current team needs to pay attention to and what is important in software engineering practice, and then explore these things in the code. Some teams may focus on some specific practices. For example, if my team is using test-driven development, my focus may be on some test-related things, such as code coverage.

 

When talking about code coverage, we must discuss unit tests. For unit tests, you need to test the normal path and the limit path. Ensure that all error traps should be tested in unit tests. In the team, we should reach an agreement on how to do a unit test well, and then look for unit tests in the code to verify these principles.

 

Another point is to consider the complexity of the Code. The high complexity means that the method is difficult to maintain. Circle complexity means that the Code has many branch paths. Specifically, if, while, for, foreach, Case, default, continue, Goto, &, |, catch, and ternary operators are used? : And so on. We should reduce the complexity of code circles from the perspective of maintenance.

 

The dependency between objects is also considered. It is an object dependency graph generated by using dependency matrix. Specifically, if I find that objects are mutually dependent, they are tightly coupled, developers need to explain why they are designed to be tightly coupled.

 

We should discuss these topics at the meeting, and other topics can be introduced. The reports generated by tools must be verified by all members of the team and an agreement should be reached, believing that there is a reason for this. If you need to take action on it, write down the items to be followed up to ensure that the problem is resolved.

 

At the end of the meeting, review the topic. Observe and record the code review and discover the problem trends, and prompt the team for positive directions in practice.

 

You have completed the code review!

Now you can use some methods to review code with your team. Remember that code review is an engineering practice that can help the team improve the software engineering maturity, and this will mean that it will ultimately deliver higher value to the customer!