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.