Agile techniques: When and how to conduct code review

author Shaojian posted on December 8, 2010 4:51 A.M.

Eric Landes recently described code reviews as a tool to help teams improve their software maturity, and ultimately to deliver higher value to customers, in an article called Agile skills: when and how to conduct code reviews.

He introduces code reviews from the following sections

Agile Engineering Practice

Eric first suggests starting with the engineering practices that are usually needed by Agile teams: test-driven development, continuous integration of war-room junctions, refactoring code for small-version publishing

It is also emphasized that the team needs to ensure that good development principles are kept in mind during code review, and that the code review is to let the team focus on when and whether they follow these principles and good practices.

when to implement code review

The timing of the code review should be decided by the team, there's no standard, depending on your team maturity and sprint/iterations, Eric's advice is that if your team has an iteration or sprint for 2 weeks, then the first code review after two sprints seems like a good time, At this time there is enough code to evaluate ... and good code reviews ensure that the team is focused on good engineering practices and allows continuous introduction of new practices.

who's going to do code review?

Developers of all levels of development should be involved, allowing team members to learn and enforce code based principles, and must have discussions and feedback. At the same time, your QA colleagues will also be involved if they also have development tasks.

Start code Review If you are a team leader, Scrum Master or project manager but never had a code review, don't be afraid.

Because code reviews don't need to be done entirely by hand, there are off-the-shelf tools and the team's technical members will come to help you, but you need to be prepared in advance.

Ready to

Code Coverage Coding Coverage

Eric tells the reader that a team needs some basic quality standards, such as code coverage for the business logic of unit testing, and there are many such tools, such as. NET environment, Ncover,visual Studio Test, Java environment, there are jcover, Hansel, Codecover and so on.

And the code coverage will reflect some of the problems, if there is less than 20% coverage of code, it may be questioned. Pay attention to ... There may be a good reason, but this is more a start to a conversation than just a report card.

Architecture architecture

For the architectural part of the code review, Eric mentions that this is a good time to understand the architecture ... To put all the old frame composition and the latest architecture and class library together ...

Code Analysis

You can use the tools to do some prior analysis, before the meeting through the analysis tool through the code, so you can know what to focus on, where to start.

The corresponding tools, such as. NET environment, the reports they generate can tell you the complexity of the loop and the depth of the ndepend.

Code Review

When you are ready you can have meetings with the team, but set aside the time for discussion, interact with the team, and guide each other. Eric advises the size and characteristics of the team to determine how long the meeting takes. For example, in a 8-developer, a project manager, a development manager's team, it takes about 1.5 hours to conduct a code review ... But this is only useful at the first meeting and will be adapted and adjusted based on the results of the first time.

In practice, our code review time may be longer than this, how to more effectively expand the code review meeting, the author also provides the following example of a time schedule:

1) Overview of this Code review story (10 minutes)

2. Discuss team metrics (10 minutes)

3) Emphasize the special focus of the review (5 minutes).

4 in-depth review of the code (55 minutes)

A) Code coverage

b) Structure

(c) In-depth analysis of the report

5 Summary and record of action (10 minutes)

This example can remind the team of what is most important, and it will vary depending on the team practice. In the review team members should not only focus on unit test coverage, complexity, but also focus on dependence, coupling and so on.

He concludes that during the meeting, the team should discuss the issues listed above and that any issues should be communicated. If you need to take action on it. Then write down the matters to be followed up to ensure that the problem is resolved. At the end of the meeting. Review action items and suggest positive direction in the team practice.

The code review has been implemented.

You may have implemented a code review in the previous steps, and he finally reminded the reader again that code review is a tool to help the team improve their software engineering maturity, and that ultimately means delivering higher value to customers.

Eric Landes is a project manager from the IT department of a large company, with a special focus on the agile team. He has over four years of experience in using Agile/lean technology to achieve customer value and to keep the team focused on the project.