In my experience, most teams in the company review the code of team member with a small amount of code, always less than hundreds of lines. Is it appropriate to review large amount of code, for example a module, when the code is complete and ready to get reviewed once for all?
- Anybody can ask a question
- Anybody can answer
- The best answers are voted up and rise to the top
The reason for the small code reviews is to maximize effectiveness.
Studies involving the Personal Software Process have found that reviewers are most effective, with respect to maximizing defects identified in the review, when they review no more than 150-200 source lines of code per hour. Given that empirical data, it becomes a matter of determining how long people can stay attentive. I don't have any empirical data, but I know my mind begins to wander after about 1 hour of reading something. To me, that indicates that code reviews should review less than 150 lines of code at a time.
It's appropriate if it helps your team create a better product.
Some reasons that code reviews often focus on smaller chunks:
That said, if you find that reviewing more code is helpful, and if your team can stand it, then by all means give it a try. It'll help to make sure that there are some ground rules and someone acting as a facilitator to keep the meeting moving along. Also, consider having reviewers submit their comments beforehand so that you spend less time on nitpicky things like improper use of white space and more time discussing important and interesting issues.
If you review a large amount of code once it's already complete (and presumably functional), this is going to turn more into a session of "we should have done..." than "let's fix/change this to do..."
So, if the primary purpose of the activity is as a post-mortem learning exercise, then the large code review makes sense. If it's to try to catch defects, it probably won't work very well. Small defects are likely to be missed as everyone in the review gets bored and tired, and large, structural defects are likely to be skipped since, well, "too late now -- code's written and customer wants it yesterday."