Disadvantages of Code Review Walk-Through

The most common kind of code review is the ever common wal-through review. It can be over the shoulder review or a more formal process involving meetings, either way the walk-through review involves the author highlighting his changes and attempting to gain feedback from other members of the team.

Even though this is a popular type of review I really feel there are some major disadvantages which in my mind hinder the effectiveness of the process.

A fundamental can become apparent when the next developer has to understand or even maintain the code. He will not have the advantage of the author walking him through it and important information is often left out of the code due to the reviewer’s acceptance of what made sense when the review was written.

Walk through reviews tend to be rather shallow with little time allowed to look for the more subtle problems within the code. A bug will be fixed when it is spotted in the walk-through, but what other code depends on it? Will it cause any behavioral issues within the code? These questions can be best answered in a lone review.

There is real lack of diversity in any code walk-through with the author driving the process and others simply clarifying what has been said matches what has been done. This also creates a lack of depth as it turns into a very basic confirmation process.

Meetings can be extremely time consuming and can be hard to manage when participants are separated by many time zones. It also very easy to become sidetracked in these meetings even though a good moderator can mitigate this problem.

Despite the above down sides to walk through reviews, they do have their advantages. Because the process is carried out in a team, it is an excellent environment for new developers to learn and to pass new ideas between each other. There are also many instructive conversations that have the benefit of happening in person which you do not get in a lone review.

It’s also nice to have multiple skills present in the room as this provides wider learning as well as the review benefiting from multiple expertise. So to round up I would always recommend doing a lone code review as the default mode but do not forget to communicate and never turn down the walk-through option, especially if there is a member who could benefit from the experience.

Source by Tom Greaves