Lightweight Code Review

This is the third article in a series of articles that describe code review process. In this part, we will have a look at the lightweight code review process.

Lightweight code review techniques, as distinct from formal inspections, are less official and must be a part of the modern software development process. Lightweight inspections can be divided into the following types:

• Pair programming
• Over-the-shoulder inspections
• Email pass-around inspections
• Tool-assigned code review

Pair Programming

Pair programming is a software development technique in which two programmers work together at a single computer. One, the driver, writes code while the other, the observer, reviews each line of code as it is typed in. The two programmers switch roles frequently.

It is important to adhere the following principles while programming in pair:

Use Ping-Pong pair programming

Shortly PPP is a derivative of Test Driven Development (TDD). While using TDD you write a test first, and then you confirm that the test fails, and write code to make the test pass. After this, you confirm that the test passes and no other tests are broken.

TDD is an excellent way to ensure robust test suite for all of your software development. However, there are some challenges. It is very easy to shortcut your tests a little by writing more than really needed. It is also easy to avoid testing the difficult cases.

Ping-Pong pairing works with two people. The first person writes a test and confirms it fails. Then the keyboard passes to the second person. The second person works on making the test pass. The second person finishes the implementation and confirms all the tests pass. Then they write a new test and confirms it fails. The first person takes the action and writes code. The process repeats as long as needed.

The following illustration demonstrates the process.

The difference from the TDD approach is that after failing a test, the other developer takes control. As far as control switches quite frequently, partners stay more engaged in what is going on. They do not have to implement the code for their own tests. Developers are much less likely to take shortcuts just to allow themselves to get by.

Discuss your actions

It is important to discuss all current and potential actions with the partner while writing code. Explain to your mate what do you do and why? If there are no subjects to discuss, you got the wrong direction. Avoid using the pair programming approach for simple and trivial tasks.

Concentrate on your work

The pair work must be planned in such a way to take the whole time interval from start to the end. Calls or meetings should not disturb developers.

The main problem of a regular code review is that the reviewers give not sufficient feedback while reviewing your code. However, when they start work with this code, you receive a lot of criticism and indication of all bottlenecks.

Over-the-Shoulder Inspections

This type of review supposes that one person stands behind another and the code author steps through their code with the reviewer. When the team finds bugs, they work together to fix it on the spot or simply submit it to a bug tracking system.

This type of review may be accomplished by using a diff-tool. Typically you go through a change list and examine the changes between the current and previous versions of the files in that change list.
This lightweight method is suitable when developers are in the same office and can schedule the time to work together. It doesn’t work when developers are geographically separated.

Email Pass-Around Inspections

This type of code review supposes that team members email the code to each other as it is developed and send feedback and comments back and forth. The author is responsible for collecting the files under review. Reviewers then have to extract those files from the email and generate differences between each version. It is easy to involve other people in this process, and it works well for geographically-distributed teams. However, it is hard to track issues or tie comments to the specific section of code they apply to.

Tool-Assisted Code Reviews

As a matter of fact, the tool-assisted code review is the most popular and modern approach these days. It allows developers to review code without interruption from the main tasks, often right inside an IDE. There are a lot of extremely powerful tools and solutions on the market today. Such tools not only facilitates the review process but also provides a rich set of features like:

• Code discussion
• Multiple review iterations
• Integration with source control systems and diff-tools
• Reporting and Statistics

This is not commercial content, so please add your comments if you are interested in a detailed review (and demo) of the most popular tools for code review. If there will be at least 10 comments, I will create an article or a series of articles on this topic.

Also Read

Uprooting Source Code Defects