Code review process
The most successful way that I currently perform code review is the following.
- Create a branch/fork of trunk and label it against your ticket number
- Have your developer check in all code against that branch
- When time to perform code review a senior developer or peer merges the branch against their current working copy of trunk and then performs a code review.
- If the review passes and the branch meets quality and the ticketed issue the changes are merged with trunk.
- Otherwise issues are flagged with the original developer in a 1 on 1 discussion and the ticket is either place back the list for rework and review or is dropped from the release if there is not enough time for rework.
Metrics don't work the way you think they do
Capturing "lines of code" type of metrics is a common Anti-Pattern, and should have no real place in the code review process.
There are great reasons why some kinds of metrics simply don't work. Joel Spolsky has written some great articles about metrics and metrics anti-patterns, and it really comes down to what outcome you wish to have from your metrics.
In regards to metrics, a great developer can write 1 line of code that performs faster and is more efficient than a mediocre developer who writes 20 lines of code to do the same thing.
Metrics you should be interested in other than evidence based scheduling is metrics regarding code quality. Packages such as NCover run over your daily build, and so these work quite well with the above code review process.