Code Walkthrough vs. Code Review

Question

How many of you use walkthroughs instead of reviews? Or in conjunction with Reviews? Or only use walkthroughs?

Are Walkthroughs beneficial and how have you all implemented code walkthroughs?

Answer 1

Any chance you could define a review vs. a walk-through? I tend to use them pretty interchangeably.

Answer 2

A walkthrough is a thorough type of code review where you actually go through the code line-by-line and try to understand what it's doing. They can be beneficial if the code isn't as well documented as it could be or if the code's ownership needs to be shared with another programmer. I usually only do walkthroughs for a specific feature rather than a whole project.

There are also higher-level types of code review where general coding style is checked for or certain structures are examined, like call graphs and class heirarchies.

Answer 3

I don't like walk-throughs; here's why.

Driven: Too often the author drives the meeting, explaining why she did this and that. Sometimes it's questioned, but often the participants are playing a matching game (i.e. "Yup, that's what she did") rather than thinking deeply about the code.

Shallow: To understand complex code takes thought. You have to look up related code in other files. You have to run through possibilities of error-handling and thread synchronization. When you're being walked through the code there's no time for finding the subtle problems -- exactly the ones that are hardest to find later.

No Context in Code: The next developer who has to understand or maintain the code won't have the benefit of the author walking him through it. Too often reviewers accept what is told them because it makes sense in the conversation, but the confusing/important comments don't make it into the code.

Time: Meetings take more time than lone reviews. It's also easy to get sidetracked on tangential discussions. A good moderator can mitigate this problem. It's hard to schedule when people are separated by many timezones.

Concessions: I agree that walkthroughs can be a better forum for teaching new developers and generally sharing and learning from each other. Instructive conversations happen that don't happen during lone reviews. Sometimes it's nice to have multiple people in the room, especially when there's a domain expert plus a language expert plus a product guru.

Therefore, I suggest defaulting with code reviews, but at the same time don't prevent people from doing walkthroughs when they find it useful.

Disclaimer: My company makes a peer code review tool

Answer 4

Sometimes code can be so complex a normal code review isn't sufficient to convince all the reviewers that some code is "correct", i.e. it will always work. If it can be coded in a clearer way, then that's fine, but sometimes you're really cool, really fast, optimisation is just too much for mere mortals, even with a comment block bigger than the code.

This is where the code walkthrough comes in. For most people always walking all of the code would be a waste of time, but walking through certain parts can be very beneficial.

My team has had some success with the following method: first do a normal code review - for us this means one or more reviewers go through the new code or change sets and prepares his comments and questions. Then we have a discussion, in person or via email, during which any reviewer can request a walkthrough, usually of a specific section of code or action. If it's a proper review meeting with multiple reviewers then we'll usually finish that first.

Later, we sit down in front of the same screen/projection, and fire up the program using gdb. We trigger the code in question and actually go through the running code line by line, forcing error conditions if necessary. Usually the reviewer is in control (at the keyboard), asking questions, checking variable values etc. It can be time consuming, but on the tricky bits it's usually worth it.

NB: Using VNC and the phone is almost as good too.

Only when the reviewer is happy with the code does he sign it off. That might mean a walkthough, additional comments, adding more unit tests, whatever.

Answer 5

A code walkthrough can be incredibly useful... even if nobody else is listening. This is because when you walk through your code and have to explain what you did out loud, you'll have a tendency to notice all sorts of dumb mistakes that you were able to overlook while coding but which jump out at you when you try to explain them.

I've had countless cases where I realize my mistake before the words ever leave my mouth--simply because the process of trying to explain the code revealed my error. In fact, I'd say this happens more often than cases where a code walkthrough resulted in someone else finding errors in my code, possibly for the reasons stated some of the other answers here.

Answer 6

Walk-Through can be tedius, Can be proved as wastage of time . There are some reasons, as I do feel as follows:- 1. Most of the time walk-through technique proved to be just matching the codes rather than taking care of codes, their objectives. 2. Walk-through can be highly complex, if the codebase is complex. In that situation Walk through technique seems to be a waste of time and efforts. 3. Dependency on the tester is there. Yes the maintenance engineer takes each word of tester seriously. 4. Some Managemental problems also lie, as to make reviews, one has to do meetings and doing meetings in organizations is not as easy as it seems to be. So some times these meetings may take longer time than the entire walk-through and reviews. But in some situations it works better like object oriented programs. In Theory it seems to be the most easy mechanism. So, as per as my thinking the usage of this mechanism could be done, but only in a few problems/situations. When the application becomes complex, I would not prefer doing Walk-Through

Answer 7

Reviewers can provide better feedback on the work product if the author presents to product. Otherwise some of the reviewers/leads/managers may not be fully aware of the product and might be not be able to give their full during the review session. It is always beneficial if the author calls for a meeting and presents the product. The reviewers, engineering leads/managers and other key stakeholders can be invited for the code walkthrough.

Code walkthroughs and reviews are 2 different techniques for static testing that helps in the early finding of defects (http://technologyandleadership.com/static-testing-early-finding-of-defects/)