Disadvantages of the code review walkthrough
The most common type of code review is the ever-common walkthrough review. It can be an over the shoulder review or a more formal process involving meetings; either way, walkthrough review involves the author highlighting their changes and trying to get feedback from other team members.
Although this is a popular type of review, I really feel that there are some major drawbacks that, in my opinion, hinder the effectiveness of the process.
A fundamental can become apparent when the next developer has to understand or even maintain the code. You won’t have the benefit of being guided by the author, and important information is often left out of the code because the reviewer accepts what made sense when the review was written.
Patch traversal tends to be rather superficial, allowing little time to look for subtler issues within the code. A bug will be fixed when it’s caught in the traversal, but what other code depends on it? Will it cause any behavior problems within the code? These questions can best be answered in a single review.
There is a real lack of diversity in any code walkthrough with the author driving the process and others simply making it clear that what has been said matches what has been done. This also creates a lack of depth as it becomes a very basic confirmation process.
Meetings can be time consuming and difficult to manage when participants are separated by many time zones. It is also very easy to get sidetracked from these meetings, although a good moderator can mitigate this problem.
Despite the above disadvantages to review reviews, they have their advantages. Because the process is done as a team, it’s a great environment for new developers to learn and brainstorm with each other. There are also many instructive conversations that have the benefit of happening in person and that you don’t get in a single review.
It is also good to have multiple skills present in the room as this provides for broader learning and review benefits from multiple experience. So, to round it off, I would always recommend doing an individual code review as the default mode, but don’t forget to reach out and never turn down the walkthrough option, especially if there’s a member who could benefit from the experience.
