Continuous Code Review

Continuous code review is reviewing all the code, all the time.

That’s the theory. In real life, some questions come up:

How do we track which code has been reviewed?

All the code?

And when is all the time?

Question 1: How do we track which code has been reviewed?

Answer 1: One cannot, and need not, mark code as reviewed.

One cannot, because, for example, if one reviews a file when it has 100 lines of code, and then later it has 120 lines of code, one may have to re-read all 120 (probably more quickly since much is not new) in order to comment.

And code is not reviewed line by line, but idea by idea.

Use a code editor that maintains a symbol tree so that the reviewer can jump from use to definition and back.

One need not mark code as reviewed because all code should be reviewed.

Question 2: All the code?

Answer 2: Yes, all the code that has been included in continuous code review.

During start-up, one might mark components or modules as having been included in the continuous code review process.

In steady state, by definition, all code is reviewed.

Question 3: When is all the time? Pair programming? Or surely, before every check-in?

Answer 3: None of the above. Try once a week.

The idea is to direct a constant flow of intelligent, objective comments to the developer, as soon after coding as possible.

Code review is not testing, and it is not certification. It is a tool to help the developer fix (improve) the code s/he has just written, to improve the code s/he is about to write, and in general, for the developer to become better at detailed design and coding.

Pair programming is not code review because the “non-driver” is not objective—s/he is part of the pair.

And it does not matter whether code is ready for check-in or not.

All you need is enough newly-written code for a reviewer to understand what the developer is trying to accomplish.

Get started!